从300万行到50万行代码,遗留系统的微服务改造(2)

2. 绞杀者模式

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


从300万行到50万行代码,遗留系统的微服务改造(2)


图6-2  抽象分支

—

组件解耦:在需要被替换的组件与组件消费者之间创建一个抽象层,这一层只根据需要声明抽象的接口或协议,具体的实现仍存留于待替换组件中。这样就通过引入抽象层实现了待替换组件与组件消费者之间的解耦。


  • 新旧组件共存:开发新组件实现同一套抽象层接口,并与待替换组件同时在系统中工作,但开始时只将少部分功能在新组件中实现,或者只有少部分生产环境流量导入到新组件上。
  • 逐步替换:随着功能逐渐完备和技术逐渐成熟,新组件承担越来越多的生产环境流量。经过全面考验后,新组件可以完全替代旧组件之时,旧组件就可以正式下线了。此时如果有需要也可以移除抽象层。


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

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


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


从300万行到50万行代码,遗留系统的微服务改造(2)


图6-3  绞杀者模式


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


  • 考虑新系统和遗留系统之间的数据共享或者同步方式。
  • 确保绞杀者门面服务不会出现单点故障或成为性能“瓶颈”。
上一篇:PostgreSQL 主机性能测试方法 - 单机多实例


下一篇:JSP内置对象(引)