数据可视化项目，从第一个探索版到现在的比较成熟稳定的实现架构 ，我将在这篇文章详细地说明一下现阶段我实现的基本原理和数据通信方式。
后台定时器触发演变
在进行第一个电子看板项目的研发过程中，我的实现思路比较简单，当时选用的只是一个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集合，调用并完成消息的推送。