數據可視化項目，從第一個探索版到現在的比較成熟穩定的實現架構 ，我將在這篇文章詳細地說明一下現階段我實現的基本原理和數據通信方式。
後臺定時器觸發演變
在進行第一個電子看板項目的研發過程中，我的實現思路比較簡單，當時選用的只是一個WebSocket連接，連接建立完成之後將前端所有頁面的頁面數據一次性的經過後臺推送給前端，定時器採用的是Java 的Timer來實現的，定時器對象在WebSocket的OnOpen()方法中觸發。年後領導又讓開發新的電子看板類的項目，這次我詳細地分析了第一個版本的核心問題，從項目的健壯和可擴展性來講，在實現原理上有這樣的不足：1、單一的WebSocket連接，數據一次性把項目涉及全部頁面的數據推送給前端，簡單粗暴，並且如果是頁面數據量巨大的前端，可能會有性能瓶頸，此外由於數據耦合嚴重，會使得客戶端數據篩選和渲染邏輯變的複雜。2、前端單頁面，所有的頁面邏輯值全部寫在了一個HTML頁面，這樣會使得頁面邏輯實現繁瑣，代碼冗長複雜，不利於後續的維護。3、數據推送的觸發選在了WebSocket建立連接的時刻，二者強關聯，且每次觸發都會重新創建一個Timer類。
而現在穩定版則從根本上避免了老版本的問題，主要的優化體現如下：1、前端組件化。2、WebSocket動態規範管理。3、消息推送的解耦優化。
前端組件化
在新的項目架構以及技術選型上，這次我採用了前後端分離的架構，其中前端運用了Vue.js+ElementUI來實現，在頁面結構上則採用了組件化思路，且不同的組件有自己單獨對應的後端WebSocket服務，通過組件化使得我的頁面代碼量合理地進行了分配，每一個組件有單獨屬於自己的頁面實現邏輯，並且從實現了從WebPage到WebApp的跨越，這樣的設計更利於項目後續的版本迭代和功能擴展。
WebSocket動態規範管理
WebSocket服務的管理是比較難的一點，在第一個版本中爲了儘快實現效果，採用了最爲簡單直接的方法，在最新版本的代碼實現方案中，我將WebSocket做了如下兩類區分，首先是針對頁面類型，再是針對客戶端數量。針對頁面類型在後端分別創建與該頁面對應的WebSocket服務類（類似於Servelet的創建），新增一個頁面那麼後端就會新建一個與之對應的WebSocket服務類，而對於每一個頁面的WebSocket服務類，針對客戶端頁面的打開數量則採用了定義靜態ConcurrentHashMap的方法，在OnOpen()方法中每次打開頁面將當前的WebSocket服務器添加到ConcurrentHashMap中，爲了實現每次請求對應的userID不同我在前端wurl的末端加入了new Date()進行區分，這樣每次請求便唯一性地保存到了Map當中，另外爲了避免首頁白屏，在第一次調用OnOpen的時候我會單獨地從後臺獲取數據。
消息推送解耦優化
在第一個版本中，消息推送的定時器在OnOpen中定義實現，後臺消息的判斷和推送必須建立在有用戶打開頁面纔行，也就是後臺數據的推送機制建立在用戶觸發連接的前提之下，這是不合理的。新版本摒棄了Timer，通過Springboot定義了 @Scheduled(fixedRate = 10000)方法，這樣數據的獲取就與用戶是否打開頁面毫無關係了，無論客戶端是否與服務端連接，後臺數據的獲取，邏輯判斷都會根據設置的時間間隔進行，只要滿足條件則獲取WebSocket服務類中的靜態Map集合，調用並完成消息的推送。