问对于老旧过时架构，边开飞机边换引擎，需要注意哪些？

确实是个比较困难的问题。个人建议是串行进行，一次只干一件事，这就要看重构升级的选择时机。找一个合适的时机进行重构升级，先暂停新需求，可监控、可灰度、可回滚，等完成升级后再接新需求。

不然在升级过程中接新需求，新旧两边都要兼容，而且也容易出错。

个人观点，欢迎讨论。

一边系统架构升级，一边系统需求迭代，在实践中，见过两种处理方式。

一种是：当前系统开发团队针对架构升级目标，将架构升级方案拆解成若干个子任务，架构师根据需求迭代计划，将子任务和需求计划结合起来跟随需求实现一起开发上线，随着每次需求开发上线，架构升级子任务逐渐完成，最后完成整体架构升级。具体可以参考我写的这篇文章《网约车系统重构：如何用 DDD 重构网约车系统设计？》。但是这种方案对架构设计要求比较高：架构师必须要对老系统非常熟悉，同时新架构升级目标也要非常明确，架构升级过程可以拆分，团队成员对架构升级重构方法掌握比较好，架构师的技术掌控能力和团队协作能力也比较强。同时，新老系统架构需要具有一定兼容性，不能变化太大，比如把一个Java开发的系统重构成Go开发的系统，这种升级方法就不是很适合。

另一种是：直接拉一个新团队，按照新的架构设计方案重新开发设计一个新的系统，这个新的系统实现了旧系统的功能，同时也参与迭代实现了新功能，这个时候，可以在新旧两个系统之前，加一个流量分单系统，将请求逐渐从老系统分到新系统。如下图

分单网关根据规则将外部请求按比例分配给新老系统

这个过程，新老系统同时运行，新系统出现任何问题，都可以将流量切回老系统。直到新系统完全稳定运行，将流量全部切到新系统，老系统关闭下线。这种方案具有较大的灵活性，新系统可以完全抛弃老系统的束缚，彻底为了新的组织目标进行设计。但是，这样的升级重构，不但是对系统的重构，也是对组织和人的重构。因为当老系统下线的时候，开发维护老系统的技术团队也将失去工作目标，团队需要拆解或者分配新的工作任务。

这个问题，我刚刚看到另一个小伙伴也问了，已经回答过了，所以复制过来了，我觉得这个问题我们用一辆新旧车打比方最合适了，假如你有一辆旧车（老旧架构）。 如果边造轮子边优化呢，就像是你这辆车有些零件坏了或者不太好使，你就一个一个地去换更好的零件来让车能接着好好开。这样做的好处是车子（系统）一直能跑，不会一下子就瘫在那儿，业务不会受到太大的影响。而且你在换零件（优化）的过程中，还能慢慢了解这辆车（架构）到底是咋回事，不至于手忙脚乱。不过呢，这也有个麻烦的地方，就是你换来换去，可能最后发现这些新零件和旧零件拼在一起，还是有点小毛病，而且可能因为一直修修补补，有些地方还是挺乱的。 要是直接重构，就像是你不要这辆旧车了，重新造一辆新车。这样做如果成功了，那车（系统）就会非常棒，很符合现在的需求，而且也很整齐干净。但是风险也大啊，你在造车（重构）的时候，车肯定是开不了的（系统可能得停摆一段时间），这对业务影响就很大。而且造车的时候你要是有个小失误，说不定整辆车都报废了（重构失败）。 所以到底是边造轮子边优化还是直接重构，得看这辆车（老旧架构）现在有多破。要是还能开，业务也还能勉强维持，那可以先边造轮子边优化；要是这辆车已经破得不行，老是出大问题，业务都快进行不下去了，那可能就得咬咬牙直接重构了。