由于历史原因，我们有两套技术架构：
基于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、数据中台的小伙伴，因形势所迫，直接抛弃了原有技术栈和工具，拥抱了新技术栈，最后技术债务居然是最小的。
任务已排期，各团队都表示坚决支持。但你以为这样就能顺利推进吗？我感觉比较难哦。
过半年，再续写一下，推进情况究竟如何，敬请期待。