如何使用 Strangler 模式突破旧有的单体架构

诚然，“Strangler 模式”这个术语听起来不太好。但它确实是一种在各种用例中都非常有用的模式。

绞杀模式的核心是逐步迁移应用程序或服务，每次迁移一部分。其理念相当简单，我们逐步在旧系统的边缘构建新的系统或架构。我们避免为了新系统而添加额外的功能，并随着时间的推移将遗留的部分升级到新系统中。

想象一下，我们有一个庞大的单体应用程序，它目前运行在一些较旧的技术上。也许是旧版本的.NET，也许是不受支持的Java版本，又或者只是一个需要拆分的庞大代码库。

无论如何，现在是时候将这个应用程序或服务带入 21 世纪了。

无论哪种情况，您的选择实际上都可以归结为三个选项。

如果仍然需要，你可以决定从头开始重建。这可行，但可能需要很长时间，而且是一项耗时巨大的工程。这意味着，当它完工后，我们只能打开灯，祈祷一切顺利。
你决定一次性迁移、升级或重构这个庞然大物。这其中可能出什么问题呢？这可能非常艰巨，而且会耗费大量时间。重构业务逻辑可能会带来更多不稳定性。升级如果出现问题，可能会导致停机。
最后一种选择是逐步改善现状。无论是升级还是数据中心迁移，逐步推进都比任何大规模操作更可取。为什么？因为我们可以限制任何宕机事件的影响范围。此外，我们还可以限制任何故障的影响，因为我们可以根据需要逐步回滚故障。

在大多数情况下，方案三是最合理的。当然，它并非放之四海而皆准，有时其他两种方案也最合理。但在本文中，我们将重点讨论方案三。

绞杀者模式允许我们在旧系统的边缘建立一个新系统，并随着事情的进展逐步将流量转移到新系统。

考虑到这一点，我们可以想象我们当前的整体生活在一个盒子里。

这个方框涵盖了构成我们遗留应用程序或服务的所有内容。我们看到，我们有几个不同的逻辑部分，例如 X 服务、B 服务等等，它们构成了我们当前的单体应用。我们还看到其中一些服务相互调用，在我们开始构建新系统时，记住这一点非常重要。

要开始使用 Strangler 模式，我们需要在盒子的入口处放置一个“保镖”。它通常被称为“门面”、“路由器”或“代理”，但“保镖”听起来更有趣，所以请继续听我说。

使用绞杀者模式的第一步是在我们的单体应用前面添加一个保镖。现在，所有发送到我们单体应用的请求都必须经过这个门面层。目前，它只是将请求直接中继回单体应用。

一旦有了门卫，我们就可以开始思考如何逐步分解我们的单体应用。为了简单起见，我们假设单体应用中的每个服务都是一个可以独立提取的微服务。

那么应该先从单体架构中迁移哪个服务呢？说实话，这个选择比较随意，但还是有一些事情需要考虑。

这两种选择都是可行的，并且各有优缺点。在选择迁移的第一个服务时，我建议你考虑一下该服务的边界是否清晰。如果边界非常清晰，就选择它。如果边界比较模糊，可以稍微往后推一点。因为边界不清晰的服务通常会与单体应用纠缠在一起，这意味着迁移的复杂性可能会大幅增加。

但是，我们也不必从现有服务开始。记住，我们说过，我们希望保持在旧系统的边缘，所以我们应该避免在旧系统中添加新的东西。这意味着任何新的东西都不应该进入我们的单体应用，而应该进入我们新的边界。

够简单吧？对于任何新事物，我们都可以创建一个新的微服务，或者在可行的情况下将其与现有的微服务合并。我们使用路由器将请求定向到我们的单体应用或新服务。

现在，我们来看看如何迁移一个现有的服务。毕竟，这个模式的目的是逐步削减单体应用，以便最终将其移除。我将从E 服务开始，因为它只被单体应用内部的另一个服务 G 调用。

现在我们看到一些有趣的东西了，对吧？

我们将 E 服务抽离到它自己的微服务中。流量通过门口的保镖路由到 E 服务，但 G 服务如何与它通信呢？请注意，它不是直接调用 E 服务，而是像任何正常请求一样调用它。

G 直接调用 E 服务有什么问题吗？不一定，但它确实会产生耦合，而这种耦合可能是你想要避免的。通过我们的 Bouncer 路由流量，我们可以让 E 独立开发，并且 G 不需要知道 E 的任何实现细节。

如果我们继续沿着这条路走下去，我们可以逐步地将单体应用中的每个组件迁移到各自的服务中。如果服务边界合理，或许可以将其中一些服务合并成一个。在迁移服务的过程中，我们或许会意识到其中一两个并不需要，这完全没问题，只要确保这些组件当前处理的逻辑在必要时能够反映到其他地方即可。

绞杀模式的目标是逐步将旧系统改造成一个崭新的系统。随着时间的推移，我们会升级、替换和删除服务，直到达到可以完全关闭单体应用的程度。

这会一夜之间发生吗？不会。
这会在一周内发生吗？很可能不会。

好的，但是什么时候完成呢？这完全取决于你现有的应用程序和架构。这就是该模式的魅力所在，你可以决定增量升级的速度。

在本文中，我们重点探讨了“绞杀者模式”的核心原则，即在旧系统的边缘逐步构建新系统。通过在旧服务的边界构建新服务，我们能够逐步切断旧系统，或者说扼杀它。这是一个非常有用的模式，在处理一定数量的技术债务时，请牢记在心。

也许你只需要替换应用程序中不再需要的旧服务？这个模式可以帮助你。或者，也许你需要替换整个单体应用，正如我们之前讨论的那样，是的，它也能帮到你。

通过逐步弃用旧系统，我们给自己留出了构建新系统的时间来。我们也避免了“大刀阔斧”地将所有用户迁移到新系统的局面。通过逐步执行这些流程，我们可以在用户不知情的情况下逐步迁移各个部分。

以下是其他人关于 Strangler 模式主题的一些帖子，您可能会觉得有帮助。

如果您正计划开启您的 AWS 之旅，但不知从何入手，不妨看看我的课程。我们专注于在 AWS 上托管、保护和部署静态网站。这将使我们能够在使用过程中学习超过 6 种不同的 AWS 服务。在您掌握基础知识后，我们将深入学习两个附加章节，涵盖更高级的主题，例如“基础设施即代码”和“持续部署”。