系统迁移模式与策略解析
路由方法与Strangler Fig模式
随着消费者类型的增加，路由方法可能会更具意义，但要警惕之前提到的潜在缺点，特别是陷入“智能管道”问题。在异步请求 - 响应式通信中，使用此解决方案或基于内容的路由时，需要确保能将请求路由回客户端，且最好不让客户端察觉变化。
对于消息驱动系统中的调用路由，还有其他选择，这些选择有助于实现Strangler Fig模式迁移。Strangler Fig模式在逐步重新平台化现有系统时非常有用，其应用不限于微服务架构的团队。在过去，很多项目都使用过该模式，比如交易公司的交易记录系统、航空公司预订应用、铁路票务系统和分类广告门户等。
在迁移功能时，如果想要改变或丰富正在迁移的系统行为，会出现一些问题。例如，使用Strangler Fig模式将现有薪资功能从单体应用中迁移出来，如果在迁移过程中改变了薪资功能的行为，而这些改变没有同步到单体应用中，那么回滚操作可能会导致问题重现，甚至需要为客户移除新功能。因此，在迁移功能时，应尽量避免改变迁移中的行为，将新功能或错误修复推迟到迁移完成后进行。
UI组合模式
前面提到的技术主要将增量迁移的工作推向服务器端，而用户界面为拼接来自现有单体应用或新微服务架构的功能提供了一些有用的机会。以下是几种常见的UI组合模式： 1. 页面组合 - 《卫报》在将在线内容管理系统迁移到新的基于Java的平台时，采用了按垂直领域逐步迁移的页面组合方式。例如，先将旅游板块迁移上线，同时确保旧页面链接能重定向到新位置。后来，《卫报》再次迁移技术时，利用Fastly内容分发网络（CDN）实现新的路由规则。