遗留系统改造策略

对遗留系统的改造，既要不影响业务，实现平滑、安全的过渡，又要保证能够高效、稳步地推进，这对于软件开发者来说是个不小的挑战。

结合笔者的经验，在遗留系统改造过程中可以采取以下思路：

• 遵循“演进式改造流程”，优先改造最具价值的部分，并保证改造过程中的风险可控。
• 采用“绞杀者模式”，通过逐步替换而非一次性替换的方式，来保证新旧系统的平滑过渡。
• 采用“挎斗模式”，将不容易改造的遗留系统接入微服务环境中。

6.2.1 演进式改造流程

演进式改造流程是一种以逐步演进的方式对遗留系统进行改造的流程，其过程如图6-1所示。

图6-1 对遗留系统的演进式改造流程

构建服务路标图

动手进行改造之前，首先需要构造出一个服务路标图，来粗粒度地展示在理想情况下所期望的各个服务及相互之间的依赖关系。以该图作为路标，指导我们着手进行服务化改造。当然，服务路标图可以不必苛求完整，可以随着开发过程的演进而不断完善。构建路标图的过程可由架构师、业务分析师及技术负责人共同参与，构建路标图的方法可以参考本书 3.1.1小节的“服务拆分策略”。服务路标图构建好之后应在团队中共享并接受来自各个方面人员的反馈。

服务选择

有了服务路标图之后，也许会发现改造过程千头万绪，不知如何选择合适的部分优先进行改造。此时不妨遵循价值最大化的原则，从多种角度去制定优先拆分策略，比如：

• 优先拆分相对独立的部分，独立业务与旧系统之间的耦合相对较小，比较容易实施。
• 优先拆分频繁变更的部分，可以通过拆分为新的服务实现独立部署与快速上线，对于提高团队总体交付效率价值较大。
• 优先拆分有特殊资源占用需求的部分，比如将计算密集型任务拆分为新服务，并恰当地利用云基础设施的弹性伸缩能力对新服务实例进行扩缩容，有助于提高系统总体性能并降低成本。

服务改造

选好优先需要改造的部分后，着手将这部分业务功能迁移到微服务架构下实现。改造过程中，通常需要解决这样的问题：

• 新旧系统可能需要不同的数据源，或具有不同的数据库结构，怎样解决数据之间的同步和依赖问题？
• 单体的旧系统需要拆分为多个服务时，怎样实现安全的渐进式拆分？

根据改造需求的不同以及数据依赖关系，具体可以分为三种不同的改造场景，每种场景下的技术实现各有不同。

业务验证

业务功能迁移到微服务架构下实现后，需要验证新的服务是否满足业务需求。在新服务上线投入使用并稳定后，可以从遗留系统中移除原有的代码模块，如有需要时，一并移除数据同步任务。

迭代优化

至此已经对一部分遗留系统的业务完成了微服务改造，对于剩余的部分，可以按照类似的方法迭代进行，重新审视服务路标图，选出下一个需要改造的业务，继续进行优化，直到完成既定的微服务改造目标。

6.2.2 绞杀者模式

在微服务架构还未流行起来之前，对于增量式的大规模软件改造，常用的是名为“抽象分支”的方法，如图6-2所示。

图6-2 抽象分支

• 组件解耦：在需要被替换的组件与组件消费者之间创建一个抽象层，这一层只根据需要声明抽象的接口或协议，具体的实现仍存留于待替换组件中。这样就通过引入抽象层实现了待替换组件与组件消费者之间的解耦。
• 新旧组件共存：开发新组件实现同一套抽象层接口，并与待替换组件同时在系统中工作，但开始时只将少部分功能在新组件中实现，或者只有少部分生产环境流量导入到新组件上。
• 逐步替换：随着功能逐渐完备和技术逐渐成熟，新组件承担越来越多的生产环境流量。经过全面考验后，新组件可以完全替代旧组件之时，旧组件就可以正式下线了。此时如果有需要也可以移除抽象层。

对遗留系统的微服务改造策略，也可以借鉴“抽象分支”的思路，只不过在微服务架构下，抽象层是由一个独立的门面（Facade）服务实现，该服务将请求转发到新系统或者旧系统，起到路由作用。

在改造过程中，新旧系统会同时存在，共同协作对外提供价值。随着改造过程的推进，新系统提供的功能和价值越来越多，逐步地取代原有遗留系统的功能，用户流量也会越来越多地导入到新系统上，最后原有遗留系统不再被使用时，就可以安全地下线了，此时门面服务也可以安全地移除。

这种平滑的过渡方法通常被称为“绞杀者模式”。遗留系统被逐步“绞杀”的过程，如图6-3所示。

图6-3 绞杀者模式

绞杀者模式特别适合用于对复杂度较高的大型遗留系统进行逐步改造，但在迁移过程中也需要注意以下问题：

• 考虑新系统和遗留系统之间的数据共享或者同步方式。
• 确保绞杀者门面服务不会出现单点故障或成为性能“瓶颈”。

6.2.3 挎斗模式

传统企业中存在大量的遗留系统，如果要对这些遗留系统全部进行微服务化改造，成本会很高，并不现实，而且有些遗留系统甚至是无法完全改造的。对于这些系统，我们的选择并不一定是将其进行微服务化改造，而是将其接入到微服务环境中，与其他服务共同协作来实现业务需求。

然而将各种形态各异的遗留系统接入到微服务环境中并不容易，存在以下常见问题：

• 需要对原有代码进行一定修改，但遗留系统有时本身已经难于修改，而且如果原系统是由多种语言构成的，就要为每种语言考虑解决方案。
• 接入代码如果是和原系统运行在同一进程中，就意味着没有很好地隔离，可能会因为接入代码的一点小问题造成原系统无法工作。

那么是否存在低成本的方法，将遗留系统接入到微服务环境中呢？一种方法是使用挎斗模式，如图6-4所示。“挎斗”一词来源于带挎斗的摩托车。

图6-4 挎斗模式

如图6-4所示，具体到遗留系统接入场景下，挎斗模式就是将接入功能代码集中在一起，作为一个独立的进程或服务，为不同语言的遗留系统提供一个同构的接入接口。在部署结构上，挎斗服务与原遗留系统紧密相关，原遗留系统在哪里它就在哪里。对于原遗留系统应用程序的每个实例，旁边都部署和托管了一个挎斗实例。挎斗是支持与原应用一起部署的进程或服务。

使用挎斗模式的好处有以下几个：

• 挎斗服务是独立运行的进程或服务，与原遗留系统的实现语言无关，不需要为每种语言各开发一种挎斗。
• 由于是非侵入式的接入方法，通常不需要改写原遗留系统的代码，可以实现零修改成本的接入。
• 挎斗服务与原遗留系统相邻部署，可以访问与原系统相同的资源，有时可以拿来作为监控服务的接入代理。
• 虽然增加了一些通信成本，但是由于挎斗与原系统相邻部署，增加的通信成本往往很少，延迟很低。

在使用挎斗模式时，也需要注意以下问题：

• 注意与原系统相邻部署，降低通信时延。
• 注意进程间采用与语言无关的通信机制，如REST。
• 考虑使用容器化的部署方式，比如将跨斗服务和遗留系统部署在同一个 Pod中。
• 考虑放入挎斗的功能，是作为单独的服务或是传统的守护进程运行方式。

Service Mesh 就是采用了挎斗模式的思路，在每个服务近端部署一个代理，帮助遗留系统接入 Service Mesh，享受服务治理带来的好处。