在我们经历的各种遗留系统改造之旅中，使用**绞杀者模式**来改造一个巨大的单体服务，是一种被广泛采用且验证行之有效的手段，在应用传统的绞杀者模式时，通常采用逐步替换的方式，将遗留系统中某一独立的部分抽取出来进行改造，最后通过反向代理等方式，将流量倒入到新的服务中。
但是在我们的案例中，被改造的领域服务是客户的核心业务，客户强烈希望在整个改造过程中，不要对现有正在运行的系统造成影响，所以仅仅采用绞杀者模式是不够的，我们还需要采用新老并行模式来完成整个迁移改造。
当使用并行运行时，我们不是调用新旧实现的其中之一，而是同时调用二者，以允许我们比较其结果以确保它们是等效的。尽管调用了两种实现，但在任何给定的时间内，只有一个实现的结果是正确的。一般而言，在不断校验并相信我们的新实现之前，我们认为旧实现的结果是正确的。
「《Monolith To Microservices》」
通过新老并行模式，原有的系统不会受到影响，可以继续提供服务，待新的服务完成迁移并通过验证之后，再将流量迁移到新的系统。采用新老并行模式可以以增量的模式进行迁移改造，并且在出现问题的时候能够轻松回滚，确保核心业务的安全。具体介绍可以参考zalando 的工程实践。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lrrhI0dx-1668589409380)(https://insights.thoughtworks.cn/wp-content/uploads/2022/11/change-data-capture-legacy-system-1.png)]
在新老并行模式运行过程中，为了达到使新服务能够完全平行替代旧服务，需要将旧服务里新产生的变化，及时同步到新服务里来（对于遗留数据只需要一次性的迁移即可）。在各种因素以及客户业务需求的影响下，我们选择了 Event Sourcing 作为基本架构来构建我们新领域服务。Event Sourcing 是一种通过记录一系列的领域事件来完成对系统状态的持久化，对于 Event Sourcing 更加详细的介绍可以参看之前的这篇《如何正确使用Event Sourcing》。
鉴于新服务中持久化的都是一系列的领域事件，所以很难将遗留系统中产生的变化直接持久化到新服务中，最好的方式是通过调用新服务提供的 API&#x
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lrrhI0dx-1668589409380)(https://insights.thoughtworks.cn/wp-content/uploads/2022/11/change-data-capture-legacy-system-1.png)]](https://insights.thoughtworks.cn/wp-content/uploads/2022/11/change-data-capture-legacy-system-1.png){kind=link}