正确实施时，微服务比单体应用具有很多优势。许多组织希望将其单体应用程序代码更改为微服务代码。事实证明，迁移到微服务并不容易。您应该问的第一个问题是，您真的需要微服务吗？单体的许多问题可以通过使用模块化单体架构轻松解决。一旦确定需要微服务，就必须制定将单体应用转换为微服务的计划。有一些模式可以帮助您创建所需的计划。
在我们进入实际的模式来划分单体之前，让我们谈谈不应该做的事情。
不要做大爆炸重写
Big Bang Rewrite，顾名思义，我们必须在微服务中重写整个单体应用的代码，并一次性将其部署到生产中。有一次马丁福勒正确地说：
Big Bang 重写唯一能保证的就是 Big Bang！
大爆炸重写总是危险的。Big bang 重写需要大量时间来开发，因为您必须对单体应用程序中的所有内容进行编码。此外，在微服务架构的开发过程中，您必须冻结单体应用中的进一步开发，因为单体应用中所做的每个更改也必须在微服务中进行。对于大多数公司来说，冻结应用程序开发可能是危险的，因为他们必须根据业务环境的变化进行调整。
对于一个组织来说，从单体架构逐渐转向微服务总是更好的。一些可用的设计模式可以帮助您逐步从单体架构转向微服务架构。
扼杀者模式
Strangler fig 是 Martin Fowler 设计的一种模式。在 Strangler Fig 中，我们围绕现有单体的边缘创建了新服务。
（banq注：这是一种理想型模式，整体单体架构之所以需要切换到微服务，是因为是糨糊一团，耦合在一起，边缘和核心都耦合在一起，如何拆？如何开始？动一迁百）
抽象分支
当您必须提取其他模块所依赖的模块时，按抽象模式分支可能会很有用。假设在前面的示例中，我们想将通知管理转换为微服务。在这种情况下，我们将使用抽象分支。我们需要执行以下步骤来提取模块。
- 创建抽象。您需要围绕要替换的模块创建抽象。
- 将现有功能的客户端更改为使用新抽象：您需要重构旧代码，以便旧实现实现在步骤 1 中创建的抽象。
- 创建新的实现。您需要为功能创建一个新的微服务实现，并将其部署到生产中并运行一些测试。
- 开关实现。一旦您运行了一些测试并且您有一定的信心，那么您就可以切换到新代码。
- 清理。一旦您的微服务启动并运行，最好清理旧代码库并删除旧模块。如果需要，您也可以删除抽象。在许多情况下，您之前创建的抽象只会改进您的代码库，在这些情况下，保留它完全没问题。
并行运行
无论您测试多少，仍然存在错误的可能性。当您迁移一个关键系统时，您不能为运气留下任何东西。在这种情况下，并行运行模式可能会有所帮助。在这种模式中，我们将在生产中部署我们新开发的微服务和单体应用。我们将让数据从两个系统流出。Monolith 系统最初将是唯一的真相来源。我们将新开发的微服务的结果与单体的结果进行比较。如果我们发现任何不匹配，我们将在我们的微服务应用程序中修复它。一段时间后，当我们对我们的新微服务系统有足够的信心时，我们就可以从整体中停用功能，并使微服务成为唯一的事实来源。
装饰器模式
这个模式的灵感来自我们已经知道和喜爱的模式之一，装饰者模式。在这种情况下，就像扼杀者模式一样，我们必须引入代理。我们将让调用通过一个代理传递给单体应用，并且基于单体应用的响应，代理将调用我们新创建的微服务。
更改数据捕获模式
在这种模式中，我们将对数据库中发生的变化做出反应。
banq注：迁移最重要的是切分单体，最有用方式是：用事件风暴分解单体设计微服务 - capital
重写比重构好，而且微服务本身特点就是能够重写一个微服务，如果一个微服务不能轻松重写，就不是微服务。