Neohope's Blog

在各项目组努力下，终于达成了几个目标：
1、springboot升级到2.x
2、干掉了老技术中台，全部系统对接到新技术中台，实现了技术中台统一
3、填了一波史前巨坑

今年希望达到几个目标
1、科技降本600万
2、升级k8s到1.20
3、如果时间来得及，实现动态扩缩容
4、日常，继续填历史的技术坑

1、redis调优
数据流：
数据库查询结果-》缓存到redis-》缓存使用者
表现：
bigkey一大堆，单个key存放数据3M多（你咋不把整个JVM塞到redis里去呢），redis服务器所需内存、带宽都特别高
原因：
分析后发现，之前架构确定的技术方案有问题
解决：
a、改变序列化方式，从jvm序列化，调整为protobuff，调整后，带宽瞬间大幅下降
b、减少序列化的数据内容，只保存真正需要的，调整后，redis内存大幅下架，带宽大幅下降
c、对redis进行拆分，将一个大redis，按领域拆分为多个小redis，性能提升明显
d、对于热数据不明显的低频访问场景，不缓存到redis，大家慢慢优化去吧

2、网关调优
数据流：
外网请求-》外网网关-》外网鉴权-》内网转发-》内网网关-》内网鉴权
表现：
外网网关和内网网关功能一样，而且逻辑超级复杂，性能垃圾的一塌糊涂
原因：
分析后发现，之前架构确定的技术方案有问题
解决：
a、干掉外网网关鉴权内容
b、增加外网网关黑名单过滤、访问频率限制等功能
c、外网网关性能大幅提升

3、数据流优化
数据流（大幅简化后）：
C系统-》数据中台-》逻辑加工-》H系统
Y系统-》数据中台-》逻辑加工-》H系统
H系统-》数据中台-》逻辑加工-》C系统
C系统-》数据中台-》逻辑加工-》H系统
H系统-》F系统
表现：
业务逻辑分散到各业务系统，数据来回传递多次，多个系统加工同一批数据，一旦出问题，要多个系统联查，花费很长时间才能定位到问题
原因：
分析后发现，之前架构确定的技术方案有问题
解决：
C系统-》Y系统-》H系统-》逻辑加工-》F系统
C系统-》数据中台
Y系统-》数据中台
H系统-》数据中台
在哪个环节出了问题十分清晰，用户自己都能初步定位到问题

4、数据修改请求超级多
数据流：
问题1、问题2、、、问题X-》老子就要修改数据-》提工单
表现：
数据质量差，任务都给到了IT，管理方没有管理动力，数据质量持续差，修改量逐年上升
原因：
分析后发现，各业务条线管控要求很多，不放权，与各地执行机构有轻度脱节
数据生产者，不承担数据质量差的职责，没有提升数据质量动力
总部管理部门，不承担数据质量差的职责，不清楚数据质量哪里差，没有工作重点
解决：
a、分析数据修改工单，归纳前几类修改请求
b、与业务方沟通，对分支机构可以修改的数据，将功能开放给各分支结构，定期公示修改量、业务影响程度等数据，作为总部管理部门的管理抓手
c、对于分支结构不可以修改的，开放数据修改功能给总部管理部门，进行统一管控，定期公示修改量、业务影响程度等数据，作为总部管理部门的管理抓手
d、数据质量与考核挂钩
e、数据质量快速提升，工单量大幅下降

5、降本
数据流：
应集团要求，降本压力巨大，科技承接了600万降本指标
表现：
科技方压力山大
原因：
一开始几年，没有这么大的压力，大家手都比较松，各条线都存在较大浪费，科技也是如此
最近几年，都是在之前资源上，不断的挤压资源，来满足每年业务快速增长的需要
今年，一方面业务继续快速增加，另一方面要大幅降本，压力山大
解决：
a、第一轮，运维小伙伴拉流量，无流量服务应关尽关，应下尽下，应合尽合
b、第二轮，运维小伙伴拉各类峰值，先统一砍一刀（网络、数据库、主机）
c、第三轮，运维小伙伴看账单，按账单大头，如网络、数据库、主机等逐条应用降本方案
d、第四轮，运维小伙伴看账单，对于不合理的条目逐条检视，逐个逐个扣
e、第五轮，各项目组，结合业务实际情况，各自制定降本方案，限时落地
f、第六轮，技术委员会，对于20%的关键业务进行性能优化，逐步降本
g、第七轮，在运维小伙伴推动下，实现自动扩缩容，继续降本

1、更换服务器后，出现网络风暴
表现：
老服务器下架，新服务器上线后，出现网络风暴

原因：
逐步排查网口，猜测一根光纤出现问题

解决：
更换了一根光纤

2、老服务器下架后，新服务器重启后，VM集群无法启动
表现：
三台ESXI主机组了VSAN，重启后，网络互通，但服务器2被独立，无法加入1、3集群
VCSA也在VSAN上，同样无法启动。

原因：
故障时，只知道出现了脑裂，三台主机无法

解决：
重启了VPXA、重启了ESXI，没有解决问题
重建VSAN，然后把三个节点加入，问题就修复了
后续发现，其实时服务器1和服务器3出现了问题，自己组成了一个新的集群

近期遇到一些技术问题，记录如下：

1、kafka并发处理量上不去
数据流：
数据生产服务-》kafka-》数据消费服务
表现：
数据消费服务加了很多个实例，但总感觉多数实例不工作
原因：
分析后发现，原来开发小伙伴把所有消息都扔到了同一个topic中，而分区只有3，消费者再多这并发量也上不去啊
解决：
按不同业务，拆分topic，同时增加分区数
同时，建议把一堆操作拆分为多个步骤进行，不要都放到一个方法里全部做掉，宁可多流转几次各司其职

2、数据上报并发处理量上不去
数据流：
DB-》轮询-》HTTP提交数据到数据上报网站【ZF】
表现：
要求4小时上传60W，实际1小时上传5K
原因：
问题很多，主要有两个，一是每次只上传一条数据，二是没有做并发
解决：
一开始准备做很大的调整，但后面项目组怕把开并发把数据上报网站压挂，最后没敢使用
最后，只是改造为批量上传数据，轮询时根据id做了一下简单的并发
数据上报网站，各地接口及要求各不一样，也是各种不容易吧

3、莫名奇妙的403
数据流：
浏览器-》网关-》鉴权服务
表现：
网关偶尔返回403
原因：
一开始日志输出太少，都没有定位到哪里的问题，只能临时在网关补充了一些日志【建议加了开关，定位问题后关闭】
加日志后，发现是一段上古代码，使用信号量进行了并发控制，超出了并发就获取不到用户权限。
而这个Bug暴漏出来，据反馈，居然是升级组件导致的。
遗留系统都是坑啊。
解决：
优化鉴权服务，定位到问题，问题也就解决了

4、无法提升的微服务性能
数据流：
浏览器-》网关-》N个服务来回调用
表现：
服务性能差，有时要几十秒才返回，一堆告警邮件
原因：
微服务拆分粒度太细，形成环状调用链路
开发同学无脑调用微服务，能调用一次的，居然会循环调用N次
解决：
重构，按业务领域合并微服务，微服务数量少了60%，同时干掉环状调用链
评审，找到不合理的循环调用，抓典型，整改

5、批量导出
数据流：
浏览器-》网关-》导出服务-》DB
表现：
批量查询、批量导出性能很差，要按分钟返回的，一堆告警邮件
原因：
数据量太大，DB拉取速度慢，数据回传也慢
解决：
根据业务情况，部分批量查询功能改到只读库查询，大批量导出功能迁移到了数据中台

6、数据批量下发
数据流：
数据中台-》kafka-》数据下发接收服务
表现：
数据中台下发数据，无法更新到下游业务系统
原因：
因安全需求，上游业务系统批量刷新数据库，导致数据中台下发大量数据，数据下发服务处理不及时，积累了大量数据待处理
下游业务系统把一堆业务逻辑放到了接收服务中，处理单条业务数据要按秒计算，数据越积越多
你没想错，kafka并发上不去，和之前原因一样一样的
解决：
接收服务简化，拆分不必要的业务逻辑，服务性能提高了几百倍
优化kafka配置
制定了批量刷新数据库的相关流程，都是泪
历史数据咋处理？和上游系统沟通后，99.9%的数据不必处理，于是忽略了历史积累数据，晚上将0.1%的数据进行了重推，解决了问题

7、Kafka卡顿
数据流：
系统A-》kafka-》系统B
表现：
kafka在半夜性能下降明显，从日志上看，就是工作2分钟，卡5分钟
原因：
kafka的消费者每次取了太多消息去消费，半夜为业务高峰期，部分消费者获取消息无法及时处理完毕，导致kafka会出发rebalance，你懂的
解决：
每次少取一些数据

8、HTTPS通讯失败
数据流：
前置系统A-》云-》云上系统B
表现：
有两家用户的数据无法连通云服务，HTTPS通讯失败
原因：
前置服务的服务器器时间错误，数据包被云的安全策略直接丢弃，被当成重放攻击了
解决：
开启前置服务自动时间同步服务

9、组件升级导致服务性能下降
表现：
系统组件升级后，系统整体服务性能下降，会有部分请求阻塞5S以上
CPU、内存、IO看起来都比较正常
生产环境才有问题，测试环境下无法复现
原因：
通过打印线程信息，发现存在大量网络IO阻塞
后定位到了一个可疑的点，日志同时输出到log文件和命令行时，命令行也发送到了log文件，会有阻塞
解决：
只输出到命令行，有待观察

整体经验：
1、微服务粒度不能太细，也不能一个服务啥都干，最好按业务领域进行拆分。业务量小的领域可以适当合并，业务逻辑复杂的考虑拆分。
2、微服务也应该分层次，不要出现环状调用链路
3、日志要足够判断问题所在，太多影响性能，太少没啥用
4、中间件不能熟练配置，不要随便上生产
5、批量操作要用特殊处理方式，没事别刷库

今年个保法发布了，根据安全团队要求，需要对数据库的敏感字段进行加密处理。

当前数据库连接已经加密了，只需要对数据加密。有两种代价较小的方式：
1、在数据库存储引擎层面加密，这样对全部业务系统是无感的。
2、退而求其次，可以在数据库中间件或在驱动层面做加密，这样全部业务系统修改量也是比较小的。
但由于种种原因，这两种方式都没有能推行。

最后采用的方式是，安全团队提供加解密SDK，各业务系统对接。
业务系统启动，通过加解密SDK从密钥分发服务器获取密钥-》写入数据库前加密、读取数据后解密
加密算法都是国密算法，包括对称加密及摘要算法。
这样全部业务系统都需要改造，而且批量操作效率也比较低。
优点是，即使别人攻破数据库，也拿不到明文数据。

改造过程也很痛苦：
1、注册APP ID，申请密钥
2、研发刷库工具
3、在数据库表中增加加密字段，通过刷库工具，将历史敏感数据进行加密，存放到加密字段
4、基于加解密SDK，研发适用于个团队的切面SDK
5、使用切面SDK，对服务进行改造，读明文，写明文+密文（可跳过）
6、使用切面SDK，对服务进行改造，读密文，写明文+密文（可跳过）
7、使用切面SDK，对服务进行改造，读密文，写密文（可跳过）
8、删除明文字段
整个过程十分痛苦。

稳定性保障：
整个密钥下发服务器，是全局的一个大故障点，必须保障可用性。
密钥分发服务器，用到了密码机，提供了同城容灾及异地容灾环境。
支持DC单独部署，也支持云访问。

对应用系统影响：
1、改造量大，且无直接业务收益，资源投入受限
2、性能下降，尤其是批量加解密时，性能下降较多
3、模糊查询受影响较大，只能通过提前计算的摘要信息进行查询了
4、遗留系统、外购系统，改造难度太大，成本太高，无法承受

对数据中台的冲击：
所有依赖于数据库日志的系统，都会受到影响，尤其是数据中台
有两种方式，一是不使用，二是用同样的key

由于历史原因，我们有两套技术架构：
基于SpringBoot1.X的老框架、老技术中台、老数据中台。
基于SpringBoot2.X的新框架、新技术中台、新数据中台。

老技术中台研发的时候，整个生产环境都是我们自己搭建的，很多功能需要自研。
到了新技术中台时，已经迁移到了集团的云上，之前设计的很多功能也就用不到了。
而且，随着时间的推移，老中台人员都去参与了其他项目，长期处于支持维护状态，无论研发、运维还是安全同事，都感到压力山大。
由于云端环境时不时会做调整，运维同学都不敢轻易重启老中台服务，怕一重启，就再也起不来了。
安全扫描策略也不断升级，扫描出来的问题一次比一次多，很快就千疮百孔了，但大家也只能缝缝补补。

之前由于业务压力异常巨大，大家一直在忙着做各种新的业务功能，虽然一直想升级，但一直没有狠下心来。
到了今年四季度，遇到了几次生产事故后，大家痛定思痛，决定还是干吧，把老中台下掉。

整体步骤大体如下：
1、找了两位对老技术中台比较熟悉的同事，对全部服务进行了梳理
2、各技术团队，也对老中台的依赖关系重新进行了梳理
3、大家坐下来，对服务进行了分类
A、对于网关类服务，按领域拆分
B、对于调用中转类服务，已经不符合当前要求，改为K8S的微服务直连
C、先看调用量小的服务；没有调用量的服务及接口，尽早下线
D、其余调用量很少的服务，与业务方沟通，能下线下线，不能下线合并等待下线
E、新老技术中台都有的服务，新中台进行适配，下线老中台服务
F、老中台有，新中台没有的中台类服务，功能迁移，下线老中台服务
G、非中台类服务，拆分到业务系统，下线老中台服务
H、其余服务，一事一议
4、对新老平台都保持的数据，进行数据治理，统一数据标准
5、在服务迁移改造的过程中，要求按新框架规范，将服务升级到SpringBoot2
6、由于没有业务上的直接收益，所以整个改造周期排了很久，各团队根据实际情况，在每次迭代中把工作量消化掉
7、及时与测试同学沟通，确保每次测试覆盖到
8、与运维同学沟通，服务全部升级完成后，切换nacos到最新版本（之前受限于SpringBoot1，无法升级nacos）
9、这样框架、技术中台就升级完毕了，后面每半年升级一次框架就可以了
10、数据中台的小伙伴，因形势所迫，直接抛弃了原有技术栈和工具，拥抱了新技术栈，最后技术债务居然是最小的。

任务已排期，各团队都表示坚决支持。但你以为这样就能顺利推进吗？我感觉比较难哦。
过半年，再续写一下，推进情况究竟如何，敬请期待。