Neohope的网络笔记

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

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

解决：
更换了一根光纤

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

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

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

2023年12月：谷歌云新加坡区域故障
事件经过：因网络配置错误，导致谷歌云新加坡区域服务中断超3小时，影响大量企业客户。
事故原因：内部网络配置失误。
造成损失：客户业务中断，谷歌云赔付客户，市场竞争力受影响。

2023年11月：阿里云全线产品故障
事件经过：11月12日下午，阿里产品全线崩溃，波及全球多个地域全部云用户，持续事件达3.5小时。
事故原因：具说是鉴权服务出了问题。
造成损失：凸显云计算集中化部署风险，影响全球多地客户业务。
小插曲：两周后，在2023年11月27日，阿里云再次遭遇了近两小时的中断，影响到中国和美国的客户。然后当天晚上，滴滴就来了个大的。

2023年11月：滴滴崩溃
事件经过：11月27日晚间，滴滴崩溃，致APP地图无法加载、无法叫车，持续约12小时，影响多地用户。
事故原因：底层系统软件故障。
造成损失：订单流失，品牌形象和用户信任度下降。

2023年10月：新加坡Equinix数据中心制冷故障
事件经过：新加坡Equinix数据中心承包商误关闭冷冻水阀门，导致制冷系统误操作，造成2.5万笔银行交易失败、8.1万次登录失败。
事故原因：承包商操作失误，误关冷冻水阀门。
造成损失：金融交易及用户登录受严重影响，暴露运维管理漏洞。

2023年10月：语雀重大服务故障
事件经过：10月23日14时左右，语雀发生重大服务中断，在线文档和官网无法访问，当晚22时完全恢复，持续近8小时。
事故原因：内部运维工具缺陷，新上线升级工具bug导致华东生产环境存储服务器误下线，造成大面积服务中断。
造成损失：定性为P0级重大事故，影响数千万用户工作与知识管理，引发对运维自动化工具安全性的反思。

2023年6月：中国电信广东网络故障
事件经过：6月8日中国电信广东区域遭遇大规模网络服务中断，用户普遍无信号、无法通话上网，故障约4小时后恢复。
事故原因：网络设备故障。
造成损失：影响广东省内商务活动和民众生活，具体损失数据未公布。

2023年5月：苹果iCloud全球服务中断
事件经过：5月11日，苹果全球服务遭遇“史诗级”宕机，持续约55分钟。大量用户的Apple ID突然登出，无法访问iCloud照片、文件和备忘录等关键数据。
事故原因：数据中心严重故障。虽然苹果未详细披露，但此类核心服务中断通常源于数据中心底层存储或认证服务的配置错误或硬件集群故障。
造成损失：数千万苹果用户数据访问受阻，打破了苹果生态“稳定可靠”的神话，引发了对苹果云服务能力的广泛质疑。

2023年5月：微软Azure故障
事件经过：5月24日，微软Azure DevOps在巴西的一处scale-unit发生故障，导致宕机约10.5个小时。
事故原因：导致该中断的原因为一个简单的拼写错误，最终导致17个生产级数据库被删除。
造成损失：大量用户无法使用云服务。

2023年4月：中信证券APP交易阻塞
事件经过：4月期间，中信证券APP出现严重的交易阻塞现象，客户无法正常下单或撤单。
事故原因：系统软件缺陷与容量规划不足。在市场交易活跃期，系统未能有效处理高并发请求，暴露出软件逻辑缺陷和灾备能力的不足。
造成损失：直接影响客户交易，导致客户资金错失交易时机，引发大量客户投诉，对券商的声誉造成了直接的负面影响。

2023年3月：推特全球大规模宕机
事件经过：平台代码更新错误，导致全球用户无法登录或使用推特功能，持续超5小时。
事故原因：内部代码更新失误。
造成损失：用户体验差，广告收入受损，平台声誉下滑。

2023年3月：广州某电信机房制冷故障
事件经过：广州某电信机房水冷系统破裂引发制冷故障，微信、QQ及政务云系统瘫痪，机房被迫采用冰块临时降温。
事故原因：水冷系统破裂，制冷功能失效。
造成损失：国民级应用及政务服务中断，影响范围广、社会影响大。

2023年3月：腾讯云机房事故
事件经过：23年3月29日凌晨，腾讯云广州五区部分云服务异常，导致微信、QQ、支付等核心功能受到影响，故障在当天中午基本恢复。
事故原因：官方反馈为“本次事故由广州电信机房冷却系统故障导致”。
造成损失：核心应用不可用。

2023年3月：B站双重崩溃
事件经过：2023年B站经历了两次较为严重的全站级宕机。一次是3月5日，用户无法访问视频详情页、收藏夹；另一次是8月4日，视频封面无法加载、视频缓冲失败。
事故原因：底层服务依赖故障与机房电力问题。虽然具体细节未完全公开，但此类大型视频平台的崩溃通常源于核心微服务依赖失效或机房电力/网络架构的单点故障。
造成损失：数亿用户无法正常观看视频，严重影响用户体验和社区活跃度，尤其在流量高峰期的崩溃对品牌形象损害较大。

2023年3月：唯品会P0级宕机事故
事件经过：3月29日凌晨00:14至中午12:01，唯品会南沙IDC冷冻系统故障，机房温度骤升导致大规模宕机，线上商城停服12小时。
事故原因：制冷设备故障。
造成损失：影响800万人次客户，直接业绩损失超亿元，定性为最高级别P0级故障。
小插曲：事故后，对基础平台部负责人予以免职。

2023年2月：甲骨文多日长故障
事件经过：2月13日至15日，甲骨文云基础设施（OCI）遭遇持续长达数天的服务中断，这是OCI历史上罕见的长时间故障。同时，其子公司NetSuite也因关联故障停摆。
事故原因：DNS后端基础设施性能问题。支持OCI公共域名系统的后端API基础设施出现性能瓶颈，导致无法处理传入的服务请求；此外，NetSuite的故障还叠加了合作伙伴数据中心（Cyxtera）的物理电力故障。
造成损失：客户业务连续数天无法使用云资源，甲骨文“永不宕机”的宣传口号受挫，大量依赖其数据库服务的企业陷入停滞。

2023年1月：美国民航系统瘫痪
事件经过：1月11日美国联邦航空管理局飞行任务通知系统因关键文件损坏瘫痪，备份系统也检测到相同损坏，重启系统导致全美航班禁飞。
事故原因：系统文件损坏。
造成损失：超4000架次航班延误，698架次取消，数十万旅客受阻，经济损失巨大，暴露单点故障风险。

咱们做技术的人，都喜欢起名字：信息化、数字化、数字平台、数字化转型、数智平台等，让很多人一开始觉得好高大上，然后又开始发懵，这些词之间有什么区别呢？试着通俗解释一下：

1、信息化
把组织线下业务流程，放到线上的过程。
比如，咱们学校上线了考勤系统、选课系统，这就是一个信息化的过程

2、数字化赋能阶段一：数字报表
在信息化的过程中，产生了部分的数据，对这部分数据进行挖掘提炼，得到一些报表，对组织经营起到了一定的提升作用。
比如，大家经常能看到的各类系统报表，通过经营分析报表，指导管理经营行为。

3、数字化赋能阶段二：数字平台
信息化建设后，各个系统之间是割裂的，各系统之间数据是互不相通的。
如何将数据打通，让组织运营者，可以对企业状况一览无余。
比如各类数据平台项目、数字平台项目，一般都会为运营者提供各类“驾驶舱”或Dashboard。
其实就是为管理者开了天眼，有了全局视角。

4、数字化赋能阶段三：自动化平台
当企业数字化建设到一定程度的时候，很多管理规则可以抽象并固化为系统规则，不需要人干预即可处理事情。
比如自动化制造、自动化质控、自动化风控、甚至量化交易等等。

5、数字化赋能阶段四：智能数字化平台，或数智平台
在3的基础上，引入了一些物联网技术、智能终端技术等，一方面让运营者可以快速感知一线情况，一方面可以快速决策反馈。
比如电商平台发现交易异常的时候，会触发智能平台的规则，自动止血；或者一些智能可穿戴设备，实时监控患者病情，及时进行干预。

6、数字化转型
但组织到了一定的发展阶段，传统的运营方式，已经无法支撑组织进一步的快速发展。
需要自上而下的去调整思路，用数字化运营的方式，重塑组织的运营方式，这其中数字化技术只是一个手段。
以华为为例，他们建立了基础IT架构（华为云），打造了统一的数据底座，提供了统一的数字服务，使用了大数据、AI、IoT等技术，最终通过数字化重构了业务运营方式，包括数字化作业、数字化交易、数字化运营、数字化办公等，从而造就了了华为近10年的飞速发展。
对于咱们老年人慢病管理，我们同样需要技术架构，同样需要统一的数据底座，同样需要封装统一的数字服务，同样可以使用大数据、AI、IoT等技术，但最终要重构哪些业务的运营方式，要重构成什么样子，就是咱们课题组要考虑的了。
比如，我们通过数据分析，可以主动为各类患者提供各类服务（比如糖尿病患者），比如：量身定制适合各自的治疗及追踪方式，量身匹配到不同的家庭医生，提前把患者需要的药帮患者准备好，提前把社区医院的耗材准备好等等等等。

7、数字化赋能与数字化转型的区别
7.1、数字化赋能
业务V1.0+数字技术=》业务A V1.1
7.2、数字化转型
业务 V1.0+自上而下的数字化运营体系+技术体系支持=》业务 V2.0

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

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、批量操作要用特殊处理方式，没事别刷库

2022年12月：阿里云香港Region大规模宕机
事件经过：12月18日，阿里云香港Region可用区C发生大规模服务中断，持续数小时，为其运营十多年来最长大规模故障，新购ECS等管控操作全部失败，整个处置过程超过15小时。
事故原因：机房冷却系统失效，现场包间温度逐渐升高，导致一机房包间温度达到临界值触发消防系统喷淋，电源柜和多列机柜进水，部分机器硬件损坏。
造成损失：严重影响香港及澳门客户业务，品牌信誉受损，事后发布事故说明及改进措施。
小插曲：事故后，阿里云总裁、CTO都被更换。

2022年12月：达美航空（Delta）行李系统故障
事件经过：12月28日，达美航空的行李处理系统突发严重故障，导致全球多个主要机场的行李传送带停摆，大量行李无法被正确分拣和装载。
事故原因：硬件维护不当与软件集成失效。由于行李处理系统的物理传感器和分拣机械臂出现故障，且后台管理系统未能及时切换至备用模式，导致系统“死锁”。
造成损失：数千名旅客的行李丢失或延误，圣诞节假期返程高峰受阻，达美航空被迫手动处理行李，运营陷入混乱。

2022年12月：腾讯云北京地域部分服务器故障
事件经过：因网络设备故障，导致北京地域部分云服务器、数据库等服务访问异常，持续约3小时。
事故原因：网络设备故障引发的运维事故。
造成损失：部分企业业务中断，腾讯云紧急修复并赔付客户。

2022年8月：谷歌爱荷华州数据中心电气爆炸
事件经过：谷歌美国爱荷华州数据中心发生电气爆炸，造成3名电工严重烧伤，全球1338台服务器中断，谷歌地图、搜索服务宕机。
事故原因：电弧闪光引发爆炸。
造成损失：人员受伤，设施损毁，核心服务中断影响全球用户。

2022年7月：Twitter全球大规模宕机
事件经过：7月14日上午8:10左右开始，Twitter突发全球性大规模服务中断，持续约1小时。
事故原因：内部系统配置与软件故障，引发了连锁反应。
造成损失：全球数万用户受影响。
小插曲：正值Twitter起诉马斯克违约的敏感时期，加剧了外界对其内部管理混乱的猜测。

2022年7月：B站713事故
事件经过：2022年7月13日，B站崩了5个小时。
事故原因：根据B站的事故分析报告，是SLB故障导致。本次SLB故障，是OpenResty中，计算gcd的lua代码传入了0值，被lua判定为nan，陷入了死循环。这段lua代码已经稳定运行了一段事件，但一个新发布模式，却触发了这个bug。
造成损失：B站核心业务中断。

2022年7月：Oracle Cloud（甲骨文）核心故障
事件经过：7月19日，甲骨文云服务（Oracle Cloud Infrastructure, OCI）发生严重故障，导致其核心金融、ERP等SaaS服务在全球范围内无法访问。
事故原因：关键配置错误。运维人员在对核心网络基础设施进行配置更新时，引入了错误的路由策略，导致控制平面（Control Plane）瘫痪，客户无法管理或访问其云端资源。
造成损失：依赖甲骨文系统的大型企业财务和运营流程中断，凸显了传统企业级云服务在运维操作上的风险。

2022年3月~5月：招商证券交易系统连环崩溃
事件经过：3月14日开盘后系统突发故障，用户无法成交、撤单；5月16日系统再次崩溃，电脑端、手机端均无法登录。
事故原因：交易系统技术缺陷。
造成损失：严重扰乱交易秩序，引发投资者不满和监管关注，母公司对相关负责人问责，质疑券商IT系统稳定性。

2022年3月：富途证券（Futu）全球大宕机
事件经过：3月14日，互联网券商富途证券（牛牛APP）发生全球范围内的服务中断。用户无论是通过网页端还是手机APP，都无法登录交易系统，也无法查看持仓和进行交易，故障持续了数小时。
事故原因：底层架构扩容引发的连锁故障。在进行系统扩容升级时，运维团队对流量预估不足，且核心网关组件未能正确处理扩容带来的配置变更，导致负载均衡失效，流量无法分发至后端服务器。
造成损失：正值美股交易时段，大量投资者无法操作，引发用户强烈不满和投诉，对券商口碑造成负面影响。

一、从经济角度
1、付款能力
互联网大厂，大家看下财报，年营收上万亿，人均营收在400万以上。
而医院呢，除去顶尖几家，很好的医院一年营收也就几十亿、十几亿，人均营收几十万。随着疫情，很多医院营收更加困难。

2、付款意愿
互联网大厂中，研发费用投入占比远远高于医院在软件方向投入，大家去看下财报就懂了。

3、产品价格
从经济学角度观察，医疗信息化行业，长期低价值竞争，已经把行业利润搞到快养不起现在的开发了。
大厂进入，势必要引入更多更贵的开发资源入场，一定是个亏本买卖。
行业的强监管导致了没有什么新的花样可以搞，大厂不可能干亏本且没其他收益的买卖。

4、运维成本
大厂2C的高并发架构，在医院
1）是用不到
医院系统一天登录用户最多几千人
2）是成本太高
无论是硬件还是运维成本，医院都接不住：一台服务器能跑起来的项目，不要部署在五台服务器的K8S集群上。
如果服务器挂了，可以重启。但K8S挂了，很多医院自己都重启不了。
不要打炮打蚊子，没有最好的架构，只有在限定经济情况下，局部最优的架构。

经济学角度出发，这个事情就不成立。
所以现状大厂的做法是，赚云的钱，但利润低、受苦受累的医院信息化，是直接做集成的。

二、从技术和产品的角度
大厂对比医院，更像是2C对2B，2B和2C软件逻辑差异很大：

（一）技术困难点不一样
1、互联网大厂技术难度高的多，以并发量来说，医院一天门诊量1万多，住院几千张床，登录用户最多几千人，和双11没法比

2、医院信息化系统，以HIS为例，难度在于，业务需求的复杂度高，如果一位开发同学即对接过微信支付，又对接过医保支付，应该很能理解，微信支付的对接就和玩一样，因为医保支付会从根本上要求医院重构
举个例子：12306初期请了不少大厂专家，解决并发问题，但购票逻辑比网络购物复杂的多，这么多高手，也没有能快速拿下，崩了两年。不是这些专家能力差，而是需求复杂度更高。

（二）需求掌控能力
1、互联网大厂，是有强大的产品和运营的，他们有很清晰的目标，服务和讨好客户，把客户就在平台，并创业更高的商业价值。产品好不好，客户也就是最终用户有一票否决权

2、多数医院没有专职运营，能把业务流程，服务流程，系统流程说清楚的，全医院就没几个人。产品最终用户，医生护士，对于流程没有话语权，只能提出点状要求

3、更可怕的是，外行指导内行的情况，在2B领域更加可怕，很难拒绝一些不靠谱的需求
举个例子：当年IE特别慢，微软有团队准备从一个飞快的开源浏览器改一版替代IE。但当这个团队把一堆IE需求加上去之后，反而比IE还慢，项目就结束了。

三、从组织架构
1、执行力
互联网大厂组织结构更优化，目标十分清晰，执行力强的可怕
医院更偏事业单位风格，需要强大政策导向，才能爆发真正的执行力

2、变革意愿
互联网大厂，从开始就在不停的变革，大家对于失败容忍度较高
医院要抽取资源，做个什么新的项目，太难了：成功不一定有功，失败一定是过

四、为何越升级越难用
1、从经济学角度观察
很大的一个原因是，买单方和使用方不是同一波人，且使用方没有话语权。
买单方花钱升级系统为的是搞管理搞成绩，从来不是为了使用方体验更好。
搞管理，管的越来越多，越来越细，被管理的使用方自然越来越难受，就会憎恶这个带来苦恼的系统。
搞成绩，就要多做事，使用方工作就更多，同样会憎恶这个带来更多工作的系统。
工作多，管得细，发挥空间自然就少了，创新就更难了。
举个例子：钉钉打卡功能其实产品层面并不差，但被管理的人不爽，有人会说钉钉好用吗？

2、什么样的考核，带来什么样的结果，铸就什么样的团队。
系统升级，以管理为导向，时间短任务重，最终用户承担了越来越多的工作，会有人说你好吗？

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

当前数据库连接已经加密了，只需要对数据加密。有两种代价较小的方式：
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、数据中台的小伙伴，因形势所迫，直接抛弃了原有技术栈和工具，拥抱了新技术栈，最后技术债务居然是最小的。

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