strangler模式是由martin fowler首次描述的一种软件架构模式，它描述了一种逐步而非一次性进行系统迁移的优雅方法。它以strangler fig（榕树）命名，这是一种慢慢爬上树并最终取而代之的藤蔓。类似地，在软件环境中，strangler模式涉及在旧系统的边界周围构建一个新系统，允许您逐步用新系统的组件替换旧系统的部分。
许多软件工程师在其职业生涯中都会面临系统迁移的问题；技术发展速度很快，人们需要时间来适应和维护他们的系统，有时甚至在完成之前系统就变得陈旧了。Strangler模式是一种允许迁移而无需进行一次性大规模改变的方法，这对团队来说可能非常有压力，并且往往注定失败。在大型系统的背景下，这种模式非常有效，因为它允许人们在迁移能力上获得信心，提供了许多更难以在一次性迁移中实现的小的成功。
一般的方法是识别可以替换的旧系统的区域，然后逐渐将新的请求或功能路由到新系统。同时，旧系统仍然处理旧功能。随着新系统变得更加稳健和功能完善，越来越多的功能被转移到新系统上，直到旧系统可以安全地被淘汰。
好处
渐进式迁移：与高风险的全面发布相比，您可以逐步迁移到新系统，确保新组件在继续之前正常工作。
降低风险：通过将迁移分解为较小的、可管理的块，降低与重大变更相关的风险。
保持业务连续性：在迁移过程中，业务可以继续使用现有系统，确保没有功能损失或停机时间。
促进现代化：这种模式在从单块架构过渡到微服务时特别有用，因为您可以逐步用微服务替换单块组件。
灵活性：由于迁移是逐步进行的，团队可以根据早期迁移阶段的反馈进行调整和改进。它也适用于现代软件开发方法，如敏捷迭代方法。
并行开发：在开发新系统的同时，如果需要，仍然可以对旧系统进行更改。
利益相关者的信任：对于IT团队来说，迁移通常是一件大事，特别是因为它们代表了一项投入巨大、难以衡量回报的投资。如果被接受，小的功能失调迹象可能会让每个人都感到担忧，因为从他们的角度来看，这是一种高风险情况。在一种奇特的模式中，通过较小的块，压力可能更加局部化到特定的块或一组块。这对于管理高层压力非常有帮助。
专注于业务价值：通过仅迁移小部分，您可以专注于最重要的部分或从迁移中获益最多的部分。通过迁移单块系统的小部分，您可以为公司开启全新的业务、简化一些关键点等。
权衡
复杂性：同时管理两个系统可能很复杂。确保兼容性、路由请求和维护两者之间的状态可能具有挑战性。
注：考虑一个旧系统与可执行文件和多个本地数据库一起存在的现代集中式Web应用程序的情况。协调和版本控制数据库将非常具有挑战性。
资源密集型：旧系统和新系统可能需要同时运行，需要额外的基础设施和维护资源。
可能存在飘移：随着开发的进行，新系统可能在功能或功能方面与旧系统存在飘移的风险，特别是如果对传统系统继续进行更改。
持续时间：过渡可能需要很长时间，特别是对于大型、深度集成的系统。这种长时间的过渡期可能导致迁移的成本和资源分配增加。
团队协作：为确保成功实施奇特模式，团队需要在目标、对传统系统的理解以及迁移策略方面达成一致。
结论
在一个变化是唯一恒定的世界中，Strangler模式成为管理软件系统演进的一种引人注目的方法。通过允许逐步替换遗留系统的组件，该模式为组织在技术进步的复杂性中导航提供了战略路线图。
模式的渐进性与当代敏捷实践相吻合，使团队能够在迁移过程中适应、检查和调整。这不仅可以保持业务连续性，还可以通过展示持续进展和减少与大规模系统改造相关的焦虑来培养利益相关者的信任。
然而，Strangler模式并非没有挑战。在两个系统之间运行和逐步过渡的复杂性不容小觑。它需要纪律性的协调方法、全面的测试以及保持必要功能平衡的敏锐眼光。
成功实施Strangler模式的关键在于细致的规划、清的沟通以及优先考虑业务价值的部署阶段方法。这是一种平衡的练习——在旧和新、速度和稳定性以及投资和回报之间。
作为软件工程师，Strangler模式为我们提供了一个务实的框架，确保我们的系统能够在不中断其提供的重要服务的情况下演变。在软件的生命周期中，Strangler模式不仅仅是一种系统迁移的方法，它还是技术本身进化性质的体现。它的目的是确保随着我们的软件成熟，它能够继续支持不断变化的业务需求，在变革面前保持强大、相关和有弹性。
