Monolith Migration

在现代软件工程中，遗留的单体应用程序是一个常见的挑战。随着时间的推移，一个成功的代码库变得如此庞大且相互关联，以至于简单的更改都会变得有风险，部署需要数小时，并且扩展单个功能几乎是不可能的。 当团队决定通过迁移到微服务来实现系统现代化时，他们面临一个高风险问题：我们如何在不破坏当前业务的情况下重写系统？ 一种选择是“大爆炸”重写——关起门来从头开始构建新系统，并在一天之内切换所有内容。然而，这是非常危险的，并且经常会导致失败。 幸运的是，有一个更安全、更可靠的替代方案：扼杀者无花果图案。在本指南中，我们将探讨 Strangler Fig 模式是什么、它为何有效，以及如何使用清晰的图表和实际代码逐步应用它。 现实世界的类比：绞杀者无花果植物 该图案以绞杀无花果命名，这是一种原产于热带雨林的植物。 绞杀无花果种子在现有“寄主”树的上部树枝上发芽。无花果不是从地面向上生长，而是向下生长： 它将根部沿着寄主树的树干向下延伸，直到到达森林地面并固定在土壤中。 随着时间的推移，更多的根会生长出来，包裹住宿主，并融合在一起。 无花果长出的叶子会阻挡光线到达寄主树。 最终，寄主树死亡并腐烂，留下一棵空心的绞杀无花果树坚强地矗立在它的位置上。 在软件架构中，传统的单体是主机树，新的微服务是绞杀者​​图。我们围绕整体系统的边缘构建新服务，逐渐将流量从遗留系统中转移出来，直到整体系统可以完全关闭。 为什么“大爆炸”重写失败 在深入探讨 Strangler Fig 模式的机制之前，让我们先了解为什么替代方案（完全重写）如此危险： 数月（或数年）没有价值：开发人员花费很长时间编写代码，但在整个项目完成之前，所有代码都不会上线。 范围蔓延：在两年重写期间，业务需求发生变化。目标发生了变化，新系统必须支持重写开始时不存在的功能。 缺少隐式行为：单体包含多年未记录的错误修复和边缘情况处理。彻底重写常常会忘记这些细节。 高部署风险：如果出现问题，关闭大型遗留系统并立即打开新系统会产生巨大的爆炸半径。 扼杀者无花果图案的工作原理 Strangler Fig 模式的核心思想是增量迁移。您无需迁移整个系统，而是一次迁移一个小功能或“片段”。 迁移过程分五个关键阶段执行： 1. 识别有界上下文 查看您的整体架构并确定易于提取的单一、独立的业务功能。好的候选人包括： 经常更改的功能（因此团队可以从独立部署中快速受益）。 用于测试迁移管道的简单、低风险功能（例如静态常见问题解答或用户首选项部分）。 具有清晰、定义明确的数据库边界的功能。 2. 实施新的微服务 将已确定的功能构建为全新的现代微服务。该服务拥有自己的数据库、自己的部署管道，并且是使用现代技术堆栈构建的。至关重要的是，单体应用中的旧功能目前仍然有效且没有变化。 3.引入拦截层 为了使迁移对用户透明，您可以在应用程序前面引入拦截层（例如 API 网关或反向代理）。现在所有客户端流量都会首先流向此网关。 最初，网关将 100% 的所有请求路由到遗留单体。 4. 增量过渡流量 一旦新的微服务经过全面测试并准备就绪，您就可以更新拦截层中的路由规则。网关不会将迁移功能（例如 /api/users）的请求路由到整体架构，而是将它们重定向到新的微服务。