一边系统架构升级，一边系统需求迭代，在实践中，见过两种处理方式。 一种是：当前系统开发团队针对架构升级目标，将架构升级方案拆解成若干个子任务，架构师根据需求迭代计划，将子任务和需求计划结合起来跟随需求实现一起开发上线，随着每次需求开发上线，架构升级子任务逐渐完成，最后完成整体架构升级。具体可以参考我写的这篇文章《网约车系统重构：如何用 DDD 重构网约车系统设计？》。但是这种方案对架构设计要求比较高：架构师必须要对老系统非常熟悉，同时新架构升级目标也要非常明确，架构升级过程可以拆分，团队成员对架构升级重构方法掌握比较好，架构师的技术掌控能力和团队协作能力也比较强。同时，新老系统架构需要具有一定兼容性，不能变化太大，比如把一个Java开发的系统重构成Go开发的系统，这种升级方法就不是很适合。 另一种是：直接拉一个新团队，按照新的架构设计方案重新开发设计一个新的系统，这个新的系统实现了旧系统的功能，同时也参与迭代实现了新功能，这个时候，可以在新旧两个系统之前，加一个流量分单系统，将请求逐渐从老系统分到新系统。如下图 这个过程，新老系统同时运行，新系统出现任何问题，都可以将流量切回老系统。直到新系统完全稳定运行，将流量全部切到新系统，老系统关闭下线。这种方案具有较大的灵活性，新系统可以完全抛弃老系统的束缚，彻底为了新的组织目标进行设计。但是，这样的升级重构，不但是对系统的重构，也是对组织和人的重构。因为当老系统下线的时候，开发维护老系统的技术团队也将失去工作目标，团队需要拆解或者分配新的工作任务。... 展开详请