翻新系统实践

基本情况

• freemark+jsp+java14的怪异组合
• 有部分内部接口采用feign
• 大部分接口采用nacos作为profile管理以及服务注册发现
• 前端部分仅使用了以jquery和easyui为主的插件，工程化程度不高

需求说明

来自于上线时候的苦恼，每次更新代码总会引发未在版本规划内的前端代码提交，且升级时间较长，失败回滚时候还有cache问题

问题分析

1. 交互代码和逻辑代码均由同一个开发人员完成，此时心智负担较大，在工期较为短的时候，非常容易造成误操作，且只有上线后才能发现
2. 系统经历了十年左右的开发，每个开发人员有不同的技术栈喜好，例如早期约定使用Spring Cloud的早期版本，而在五年后发现Spring Cloud很多功能又要二次开发，转向了nacos为主的国产。成员变换中不习惯，有部分接口就干脆采取域名+Nginx网关直连的形式
3. 除此之外业务系统的拧巴逻辑也是翻新的重大障碍

方案选择

经过和开发小组成员讨论，建议先从增量做起，避开旧有尚能完备运行的业务，其中最简单的是需要抽出一个专门的开发人力，进行前端框架的搭建。(目前使用vue2，开发人员易于招聘)

框架需要完成以下几个事项：

1. 要替换掉原来依靠服务器进行状态管理的现状，将状态管理放在前端
2. 要将功能路由管理放在前端框架进行管理
3. 要维护一个列表，标记哪些路由是用于直接走原来的逻辑，哪些路由是新增的有前端管理的逻辑
4. 需要后端软件新增接口用以维护新旧软件的状态（一次性开发成本）

在前端框架开发完成一个月后，选取更新频率最低的应用作为试点应用，避免与正在开发的任务同时进行

当前后端代码可以剥离完毕后，在考虑后端的技术栈提纯，不应将改造任务混杂

一些结局

1. 成功改造了从外包厂商回收的代码
2. 在重要业务中，成功替换了进门抬杆页面的代码
3. 为后续的业务不中断升级铺平道路

一些好玩的近况

最近出差多，不像在家里，小朋友睡觉了还要顾着点小朋友不能吵醒他。

静下心来最近好多传闻总能扰动心绪，写写文字大概能缓解下。

疫情

消息纷纷扰扰，总有人说要放开，各种奇怪的source，各种传言。虽然在物理上我们真的完全不具备条件去做这个事情，但是满天飞的传言确确实实影响了所有人的。

大概2022年的十月份看到了个对于网络空间信息污染及扭转认知的技术性文章，大概挺有意思的，也是最近这一段时间能反复相互印证的手段。

一旦有了技术性分析，事情本身可能对于我来说更多是高一个维度的观察。

主要的手段有：
1、启用冷藏多年的账号库
2、反复投放Unknown Source Speak
3、内容在普遍意义上符合一定的诉求
4、反复多账号打榜，人为攻击社交网络体系，使得本不值得讨论的问题成为了一个讨论的问题
5、一旦出现官方辟谣，一定会转为以傻子为节点的传谣

工作

加入现在的公司应该快满两年了。贡献给公司的代码是越来越少了，大部分让我还能使用编程能力都是为了我自己的服务器。反倒是真的像车库阶段的个人电脑使用方向。工具也是初创公司才会去使用。

怎么说呢，这样分裂的感觉，又使得我更好的观察了到底所谓的技术是什么。

这两年让我锻炼出的一个基本技能就是看使用的工具链能评价出具体一个开发团队会大概需要多少开发人员，凡是声称自己公司有特别强的自我研发能力，然后发现人数队伍不匹配，大概率也就是商业吹嘘了，不会有实质性的开发能力。

游戏

出差这么多天，发现我这个新买的超薄本，性能很牛逼啊，就是内存小了点，Intel的Iris Xe能打很多以前台式才能玩的游戏了，加上20w的满血CPU，而且是稳定释放。我竟然又开始静悄悄的玩一下小时后的游戏。可惜了，我已经记不起来以前玩过的好多游戏，只能支离破碎的记得一些画面。

一点观察

关于业务调查

首先需要明确，我们调研的是什么业务。
其次应该要调研目前较为频繁的操作，必须要区分主次而不是把曾经的流程死缠烂打。边缘策略不需要太关注
最后应调研的是，不同角色的不同吐槽，然后汇总

关于会议

一个有效的会议组织，应该事前分发好资料，事中做好记录，事后做好跟踪
对于傻逼议题能有效的中断。
会议必须要有时限。

一些近况

关于技术

一般的小公司，没必要纠结上各种高大上的分布式。耗费的成本远超当初划分的成本，老老实实用单体应用做好代码切割才是正途
另一方面，觉得这里没有技术，或者说什么叫技术：最后变成了我回归了数学。即便依旧学不懂数学。

关于管理

大部分时候我们需要下属的目标与管理者的目标要一致。目标一致那么，制定计划的时候才能群策群力。
但是现在大部分时候都是，目标不那么一致，事情大概率是推动不下去的。想了很多缩减整改的方案，最终还是放弃了，费时费力还不讨好，不一定有成效。有成效也不能提升部门绩效。

关于生活

大头可爱了，也闹腾了。

证券、信息聚合系统框架与搭建

问题

1. 现有的所有的渲染都放在客户端，服务端只有数据
2. 客户端为了新增图表都需要更新客户端
3. 目标用户更新客户端意图不强烈

扩大视角范围

不再只关注渲染层的事项，关注整个富客户端的架构

参考

参考后台开发组件化的趋势，做一个大而完整的软件平台

考虑到是软件平台，必须要解耦所有组件之间的直接调用关系

基础组件构成

• 组件注册中心
• 组件间通信工具（消息队列、消息总线）
• 本地数据库
• 渲染容器
• 与行情交易柜台对接的各容器适配器

软件组件划分

高频变动数据，低变更

原生程序开发

低频数据

使用Chromium做Web开发，降低开发成本，同时因为Web软件的天然容易更新的属性，能够在变更时候不需要客户端更新基础组件

组件Example

证券，信息聚合前端框架设计与搭建（二）

技术选型

现有的React可能比较符合需求，但react的diff&patch是O(n^3)级别的算法，这里可能会限制我们单页Component数量

UI界面的话，可以任意选用各个大厂的UI，例如ant.design（PC）ele.me（手机H5）

另外可以自然的引入React Native

但不应该绑死在React技术栈上，防止其授权失效直接导致业务下线

实现路径

早期验证业务阶段可以自行封装Component，系统内部采用封装后的Component来进行代码的编写（Wrap）

等开发中常见的工具类，常见的Class均稳定后，替换Component的内部实现，可以考虑重新通过开源的virtual dom库来实现

设立低时延展示组件

完全避开react的渲染逻辑

手动Bind数据，手动确认渲染时刻并将其渲染时机封装在Component下，避免当高频数据到来时CPU全部分配至JS引擎来处理差分数据合并而Render线程被阻塞

逐步封装Table，List等组件

证券，信息聚合前端框架设计与搭建

主旨

工程上

• 减少前端文件的大小
• 方便更新版本
• 最好是单页面应用，减少sso成本
• 代码混淆

通信性能要求

对于高频信息，应以websocket为主，主要需要解决的问题是从服务器到达客户端的延时抖动，以及TCP的延时断线问题

对于中频信息，应以定时任务刷新即可满足

若是采用差分数据方法，可以减少网络IO消耗

高频信息（ms级别）

• L2交易数据
• L1行情更新

中频信息（分钟级别）

• IM
• 公司公告

渲染性能要求

优先级高的，高频信息，应尽可能快的渲染（60FPS）(16.67ms)内合并vDom事件然后渲染

中频信息按需渲染

应给调用者refresh接口，方便业务可以直接触发更新界面事件