正确实施微服务架构相较于单体应用具有许多优势。很多组织都希望将他们的单体应用代码迁移到微服务架构。然而，迁移到微服务并非易事，因此我们需要认真思考是否真的需要微服务。许多单体应用存在的问题可以通过模块化的单体架构轻松解决。一旦确定确实需要微服务，就需要制定一套转换单体应用为微服务的计划。本文将介绍一些模式，以帮助您创建所需的计划。

在深入讨论这些拆分单体的模式之前，我们必须先强调不应该采取的做法。

不要做大爆炸重写

在软件开发领域，"大爆炸重写"是一种术语，指的是将原本作为单一实体的应用程序代码，拆分并重构成一系列微服务，然后一次性将它们部署到生产环境的过程。正如Martin Fowler所言，大爆炸重写通常只能确保一件事 - 风险。

大爆炸重写是一项具有潜在风险的任务。它需要耗费大量的开发时间，因为必须重新编写原有单体应用程序的各个组成部分，将其转化为微服务。此外，在进行微服务架构的开发过程中，必须冻结对原单体应用的新开发工作，因为单体应用的任何更改都必须同时在微服务中进行。对于许多公司来说，冻结应用程序开发工作可能带来潜在风险，因为他们需要根据业务环境的变化随时对软件进行调整。

渐进式转变相对较安全。它允许我们在开发过程中逐渐重构和迁移单体应用的不同部分，而不需要完全停止单体应用的开发工作。这样可以减少风险，并且能够根据业务需求灵活调整软件。

以下是一些可用的设计模式，可以帮助组织逐步从单体架构向微服务架构转变：

扼杀者（Strangler Fig）

扼杀者模式是由著名软件工程师Martin Fowler提出的一种设计模式，灵感源自于自然界的无花果。无花果以其独特的方式生长，它从寄生的树冠分枝开始发展，根慢慢延伸至地面。这些根逐渐生长并最终触及地面，甚至在这个过程中会逐渐消亡寄主树。在软件世界中，我们可以借用这一生态启示，以扼杀者模式的方式构建微服务架构。

在扼杀者模式中，我们以现有单体应用程序为基础，逐步在其边缘创建新的服务。这里，“边缘”指的是现有单体系统的外围功能或模块。让我们通过一个具体的例子来深入了解这个概念。

当前单体应用程序结构（图 1）

在图 1 中，我们可以看到单体应用程序的结构。产品库存、订单管理和计费管理模块位于应用程序的边缘，而通知管理接收多个来自应用程序内的入站调用。由于入站调用来源多样，我们无法将它们都直接重定向到通知管理。因此，我们需要另一种模式来将通知管理迁移到微服务，这将在稍后讨论。

现在，假设我们想将订单管理模块迁移到微服务架构。我们可以按照以下步骤进行操作：

步骤 1: 插入代理

部署 HTTP 代理：首先，我们需要引入一个 HTTP 代理，除非您已经拥有一个。这个代理将用于将所有调用直接重定向到单体应用程序。引入 HTTP 代理后，您还可以监测网络上是否存在可能影响 API 调用性能的延迟。如果延迟问题严重，您可能需要在继续迁移之前先解决网络问题。

步骤 2: 部署微服务

部署微服务：在第二步中，您将在生产环境中部署订单管理微服务。请注意，在此阶段，微服务不会处理任何实时流量，仅用于测试微服务的正常运行。

步骤 3: 重定向流量

重定向流量：在第三步，我们将实际流量从 HTTP 代理重定向到新部署的订单管理微服务。如果在这个阶段出现问题，我们可以轻松更改 HTTP 代理的定向设置，以便快速回滚到单体应用程序。

整个迁移过程如下图所示：

迁移流程（图 2）

抽象分支

在软件开发中，当需要提取一个模块以满足其他模块的依赖时，抽象分支模式可以派上用场。以前的示例中，假设我们要将通知管理功能转换为微服务，那么在这种情况下，使用抽象分支模式是明智之举。下面是执行此操作的步骤：

1.创建抽象：首先，需要创建一个抽象，它是要替换的模块的代表。这个抽象应该提供相同的接口和功能，以便旧代码可以无缝地切换到新的实现上。

2.更改现有功能的客户端：接下来，必须对旧代码进行重构，以便它使用在步骤1中创建的抽象。这意味着修改依赖这个模块的代码，以便它们与新抽象进行交互。

3.创建新的实现：然后，需要为功能创建一个全新的微服务实现。这个新实现应该基于抽象接口，同时还需要进行充分的测试以确保其功能正确性。

4.切换实现：在完成足够多的测试并获得信心后，可以切换到新的代码实现上。这通常意味着将新的微服务部署到生产环境，并确保它可以胜任原有功能。

5.清理：一旦新的微服务已经启动并在生产环境中运行，建议清理旧的代码库和删除旧的模块。如果抽象不再需要，也可以考虑将其删除。然而，在很多情况下，保留抽象是有益的，因为它可以提高代码库的质量和可维护性。

为了更好地理解整个过程，请参考下图。

抽象分支（图3）

抽象分支模式可以在许多场景中使用。我们建议尽可能使用"Strangler Fig"模式，而不是抽象分支。如果你确定无法使用"Strangler Fig"模式将单体应用的某些部分替换为微服务，那么你可以考虑使用抽象分支。

并行运行

无论你经过多少次测试，错误的可能性仍然存在。当你迁移关键系统时，运气不能成为你唯一依赖的因素。在这种情况下，并行运行模式可以提供帮助。在这一模式下，我们会在生产环境同时部署新开发的微服务和旧的单体应用。数据将流经这两个系统。一开始，单体应用将是唯一的数据来源。我们将比较新微服务的输出与单体应用的结果，如果发现不匹配，就会在微服务中修复问题。随着时间的推移，当我们对新的微服务系统充满信心时，可以停用单体应用的相关功能，使微服务成为唯一的数据源。

举个例子，假设我们想将计费管理从单体应用迁移到微服务。在这种模式下，我们会开发一个新的微服务，并将相同的流量引导到新的微服务上。每天结束时，我们可以使用批处理作业来比较旧系统和新系统生成的账单是否相同。一旦我们对新系统有足够的信心，就可以停用单体应用中的计费管理功能。此外，还有一些开源库，如GitHub的Scientist库，可以帮助你更好地实现这种模式。

并行运行模式（图 4）

这种模式特别适用于将功能从单体应用中迁移到微服务时。例如，如果你需要添加新功能，比如在每次成功交易后向用户发送电子邮件折扣券，只需在单体应用的订单模块中添加新代码以调用新的折扣微服务即可。但如果你没有可用的代码呢？如果你正在使用其他供应商的解决方案或某些SaaS服务，也可以实现这一目标。接下来的两种模式专门针对这种情况进行了定制。

装饰协作者（Decorating Collaborator）

这种模式的灵感源自于我们熟悉且喜爱的装饰者模式。与装饰者模式类似，这里我们需要引入一个代理。我们让调用通过代理传递到单体应用，然后根据单体应用的响应，代理将调用我们新创建的微服务。

装饰协作者（图5）

图 5展示了装饰协作者模式的机制。这种模式仅在所有微服务所需的数据都已存在于请求或响应中时才应该使用。如果数据不存在，那么我们新创建的微服务必须连接到单体数据库上。换句话说，我们的新微服务需要与单体数据库耦合，这显然不是一个好主意。

更改数据捕获模式

在这种方案中，我们将实时响应数据库的更改。举个例子，假设我们希望为系统中新创建的每个客户生成一张会员卡。为了实现这一目标，我们可以监测客户表的变动。一旦检测到有新客户记录被插入客户表中，我们就可以调用Loyalty微服务。该微服务负责发放会员卡并向客户发送包含详细信息的电子邮件。为了监听数据库的变化，我们可以采用多种方法。其中一种方式是使用触发器，通过在客户表上设置触发器来捕获插入事件。另一种方式是利用数据库的事务日志，通过读取日志文件来获取最新的更改信息。此外，我们还可以编写一个定期触发的流程，用来检查数据库中发生的更改，并及时做出相应的处理。

结语

正确实施微服务架构可带来许多优势。将单体应用程序转变为微服务并非一蹴而就的过程。我们需要意识到，这是一项漫长的马拉松，而非一场短时竞赛。成功完成这个转变需要耐心，并且必须做出明智的架构决策。

本文我们探讨了一些可供选择的模式。通常情况下，需要应用多种模式才能完全将单体应用程序转换为微服务。最后，我强烈建议在迁移到微服务之前花时间深入了解你计划使用的策略。这样的准备工作终将会带来回报。推荐各位软件设计师和技术人员了解中培IT学院的微服务及高并发、高可用架构设计与最佳实践培训班，本课程涵盖微服务架构设计方法、单体应用向微服务架构迁移的实践经验、微服务架构相关的解决方案、微服务治理相关技术等内容，通过学习本课程，将促进从业者、企业在微服务领域的发展产生深远影响。

[1]