06 | 以增量演进为手段：为什么历时一年的改造到头来是一场空？
2022-04-22 姚琪琳
《遗留系统现代化实战》
课程介绍
讲述：姚琪琳
时长:大小9.42M
你好，我是姚琪琳。
今天我们来聊聊遗留系统现代化中的 HOW，也就是第三个原则，以增量演进为手段。
很多团队在一阵大张旗鼓的遗留系统改造后，终于迎来了最终的“梭哈”时刻。尽管事先可能在各种测试环境测过无数遍了，但上线生产环境仍然如履薄冰。
和遗留系统项目“相爱相杀”十几年，我可以肯定地告诉你，这种一次性交付的大规模遗留系统改造，几乎不可能一上线就成功，必然会有各种或大或小的问题，甚至导致不得不全量回滚，交付日期一拖再拖。哪怕你的“战前准备”历时一年，甚至更久，到头还是一地鸡毛。
你可能会有疑问，你见过很多大厂的案例，都是一次性上线的。没错，的确是这样，但大厂之所以有勇气这么做，是因为他们有很强的人力、物力支撑，客观条件允许这么做。对于资源有限的小公司、小项目，还是应该衡量一下改造的难度和运维的能力，以控制风险为主。
怎么控制风险呢？我的答案是增量演进。这节课，我带你把这个概念搞通透，顺便演示下代码和架构的增量演进怎么做。
什么是增量演进？
什么是增量？什么又是演进呢？这要从演进式架构开始说起。...
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
精选留言
刘大明2022-04-22试着回答一下第二个问题。 在无测试的情况下重构，我首先想到的第一步，就是通过ide的快捷键直接调用重构的一些操作。在不济，就参考<重构>一书里面的一些操作手法，也可以保障重构的有效性。 上家公司每次重构或者上线一个新功能都喜欢加开关，来手动的去做开关导流，但是确有个坏毛病，旧的代码也不清理，这样就导致，代码里面充斥着各种开关判断。 问题1.关于开关的管理，老师有什么好的经验吗？或者好用的开源软件来去管理，每次开关多达几十个，可能到了后面，很多开关都不知道是什么意思。 问题2.关于导流，老师有什么好的经验吗？上家公司都是我早上上班之后，手动的开启开关，当客户反馈新功能报错或者不好用的时候，在手动的关闭开关，有没有什么好办法，只切部分流量到新功能这种。展开作者回复: 感谢分享。 对于作业第二题，其实我想问的是，除了课中给出的方案外，还有没有其他方案，你可以再思考一下。 对于你的问题，你其实缺少的是一个特性开关管理和A/B测试工具，很多开源工具其实是两者结合的。我推荐几个，你可以调研一下看哪个适合。包括： - ConfigCat（configcat.com/） - Flagger（flagger.app） - Flagr（github.com/checkr/flagr）
1
aoe2022-04-22目前正在做一个关于分布式事务最终一致性的重构，开始前的方案有两个： 1、业务开始前生成一个 traceId，将它保存在所有步骤中（工作量太大，放弃） 2、优先解决出问题最多的服务，提升事务的可靠性 - 可行，采用；就按老师说的来：建立开关、增量迁移、并行运行、代码清理 - 因为刚在02课学习了遗留系统现代化的三个原则—2. 以价值驱动为指引 - 完成这个功能带来的收益最大展开作者回复: 感谢分享。 不知道你说的第1个方案是不是指给请求加correlation id，如果是的话，可以考虑开发一个库，从切面层在request head里加，后续的转发请求也都在head里加上同样的id，方便跟踪。
共 2 条评论
killer2022-04-22细粒度的每个功能点一个开关，有可能是一个mq的监听方法，或者某个方法级别的，我们要自己开发这种开关工具吗？有没有现成的解决方案作者回复: 开关工具其实很简单，读配置或数据库就可以了，完全可以自己写。现成的工具也是有的，ConfigCat、Flagr、Flagger等，但并不一定适配你的场景了。
公号-技术夜未眠2022-04-22干货满满，看得出来老师实战经验很丰富1