记一次数据可视化系统开发总结

背景

公司需要建立一条新的业务线，对于开发而言这条业务线由四部分组成，除去现已有的项目，还需新建两个项目，其中一个就是关于数据可视化的系统。而已经上班的小伙伴应该都知道，这种新建项目的排期一般都不会很长，领导都是希望在较短的时间内可以看见成果，所以项目只能是一个版本一个版本的迭代，一步到位基本不太可能，而对于那些所谓的架构设计、工程设计这些几乎相当于没有，全靠开发的自觉。本文就是记录本次系统开发，为什么要进行版本迭代以及因为什么问题需要版本迭代。

项目需求

项目的具体需求无非就是大大小小的图表，没有什么好说的，但是本次项目在最开始的时候，就提出了几个问题：

1、系统可能会同时打开二十多个窗口，每个窗口的数据都需要实时刷新，所以需要保证公司电脑的配置可以稳定运行；
2、因为会打开多个窗口，所以希望这些窗口的位置，以及每个窗口中图表的配置信息等都可以实现保存，可以选择打开制定配置来实现打开所有的窗口；
3、项目涉及大量计算，产品经理会来现场进行说明，在此期间尽快完成一版需求，验证可行性；

V1版本

此版本主要是在产品出差的这段时间快速实现主要功能，简单点说就是赶时间。因此在技术栈的选择上当然还是公司最常用的vue2 + Element UI，对于可视化的需求，根据需求文档，选择Echarts即可满足需求。因此第一版就是传统的系统，左边菜单，右边图表进行展示，在短时间内完成MVP版本。

V2版本

因为系统需要在一个桌面上打开多个窗口，且每个窗口的图表都是可以配置的，所以页面的布局以及配置的表单就应该实现响应式的变化，并且在不影响功能的前提下，经可能的将表单做的小一些，基本上这一版本就是在调整样式，以满足一个桌面多窗口的需求。

V3版本

系统需要实现打开多窗口，且每个窗口的位置大小以及表单配置保存，这么来看的话，单纯的浏览器并不能很好的满足我们的需求，虽然使用window.open也可以让打开的窗口实现指定大小和指定位置，但是使用window.open打开同源的页面是跟主页面共用同一个渲染进程，这肯定会出现性能问题，其次这个方法实现当前需求并不是很好的选择，所以我们选择了使用Electron进行套壳，这样就可以实现窗口配置的保存，且每个窗口都会起一个独立的渲染进程，避免了卡顿问题。这样做是比较快，比较容易，但是问题也很明显，就是内存占用过高，而且经常会出现接口超时的问题，所以我们的V4版本来了。

V4版本

在这一版本中，主要解决的是性能问题，目前主要的性能问题有两个，一个是内存占用比较高；二是接口容易超时报错。

1、对于内存占用高的办法，当时是采用了两种策略，一是对渲染要求不高的页面使用window.open来打开新的窗口，这样就会共用渲染进程，节约内存消耗；二是增加电脑的内存，毕竟原本的电脑是16g的，就算再怎么优化，也顶不住快三十个窗口同时运行并且这些窗口的数据每秒刷新一次。

2、对于接口超时报错的问题，我们当时对报错进行了定位，发现随着时间变化，每次请求返回的数据越来越多，所以请求的响应时间就会变长，但是我们的请求是轮询的，每隔一秒就请求一次，所以当数据量大的时候，就会出现这次请求还没响应，下个请求已经发出了，而浏览器对同源并发请求有限制，最多是六个，所以超过六个的时候，就会阻塞后面的请求，阻塞时间过久之后就会报超时错误。

对于浏览器最大连接数的问题，在网上查了一下，发现不同浏览器的实现都不太一样，拿chromium来说，network是独立进程，创建连接在net目录的代码里。本身在socket方面是有全局同域连接和最大连接数限制的。挂代理和不挂代理也有同域连接数区别，挂代理全局同域TCP能到32，普通就6，最大同时好像为256。因此会出现随着时间变化，数据量变大，请求阻塞的问题。

找到了问题，那么解决起来也就快很多了，我们定位到经常出现问题的几个窗口，发现他们都是数据数据量比较大的窗口，我们根据这些数据的特点，做了不同的策略，比较历史趋势这个图表，主要展示的是历史数据，以日为单位，所以这种只需要请求一次就行；而其他以秒为单位的数据，我们只会在第一次渲染的时候请求全量数据，之后的每次请求，只会拿一秒包含的数据，而不是全部数据，这样响应的数据量就会大大减少，解决了接口超时报错的问题。

想从代码角度做性能优化，就必须一块一块的做，除了上面两个比较明显的问题之外，我们还针对数据量大，渲染卡顿的图表做了全量渲染改增量渲染、降采样等。

最后总结出来一句话，优化一年都不如换个新电脑（狗头保命~~哈哈哈）