在将单体迁移到微服务之前需要了解的模式 - Abhishek

21-07-02 banq

正确实施时,微服务比单体应用具有很多优势。许多组织希望将其单体应用程序代码更改为微服务代码。事实证明,迁移到微服务并不容易。您应该问的第一个问题是,您真的需要微服务吗?单体的许多问题可以通过使用模块化单体架构轻松解决。一旦确定需要微服务,就必须制定将单体应用转换为微服务的计划。有一些模式可以帮助您创建所需的计划。

在我们进入实际的模式来划分单体之前,让我们谈谈不应该做的事情。

 

不要做大爆炸重写

Big Bang Rewrite,顾名思义,我们必须在微服务中重写整个单体应用的代码,并一次性将其部署到生产中。有一次马丁福勒正确地说:

Big Bang 重写唯一能保证的就是 Big Bang!

大爆炸重写总是危险的。Big bang 重写需要大量时间来开发,因为您必须对单体应用程序中的所有内容进行编码。此外,在微服务架构的开发过程中,您必须冻结单体应用中的进一步开发,因为单体应用中所做的每个更改也必须在微服务中进行。对于大多数公司来说,冻结应用程序开发可能是危险的,因为他们必须根据业务环境的变化进行调整。

对于一个组织来说,从单体架构逐渐转向微服务总是更好的。一些可用的设计模式可以帮助您逐步从单体架构转向微服务架构。

 

扼杀者模式

Strangler fig 是 Martin Fowler 设计的一种模式。在 Strangler Fig 中,我们围绕现有单体的边缘创建了新服务。

(banq注:这是一种理想型模式,整体单体架构之所以需要切换到微服务,是因为是糨糊一团,耦合在一起,边缘和核心都耦合在一起,如何拆?如何开始?动一迁百)

 

抽象分支

当您必须提取其他模块所依赖的模块时,按抽象模式分支可能会很有用。假设在前面的示例中,我们想将通知管理转换为微服务。在这种情况下,我们将使用抽象分支。我们需要执行以下步骤来提取模块。

  1. 创建抽象。您需要围绕要替换的模块创建抽象。
  2. 将现有功能的客户端更改为使用新抽象:您需要重构旧代码,以便旧实现实现在步骤 1 中创建的抽象。
  3. 创建新的实现。您需要为功能创建一个新的微服务实现,并将其部署到生产中并运行一些测试。
  4. 开关实现。一旦您运行了一些测试并且您有一定的信心,那么您就可以切换到新代码。
  5. 清理。一旦您的微服务启动并运行,最好清理旧代码库并删除旧模块。如果需要,您也可以删除抽象。在许多情况下,您之前创建的抽象只会改进您的代码库,在这些情况下,保留它完全没问题。

 

并行运行

无论您测试多少,仍然存在错误的可能性。当您迁移一个关键系统时,您不能为运气留下任何东西。在这种情况下,并行运行模式可能会有所帮助。在这种模式中,我们将在生产中部署我们新开发的微服务和单体应用。我们将让数据从两个系统流出。Monolith 系统最初将是唯一的真相来源。我们将新开发的微服务的结果与单体的结果进行比较。如果我们发现任何不匹配,我们将在我们的微服务应用程序中修复它。一段时间后,当我们对我们的新微服务系统有足够的信心时,我们就可以从整体中停用功能,并使微服务成为唯一的事实来源。

 

装饰器模式

这个模式的灵感来自我们已经知道和喜爱的模式之一,装饰者模式。在这种情况下,就像扼杀者模式一样,我们必须引入代理。我们将让调用通过一个代理传递给单体应用,并且基于单体应用的响应,代理将调用我们新创建的微服务。

 

更改数据捕获模式

在这种模式中,我们将对数据库中发生的变化做出反应。

 

banq注:迁移最重要的是切分单体,最有用方式是:事件风暴分解单体设计微服务 - capital

重写比重构好,而且微服务本身特点就是能够重写一个微服务,如果一个微服务不能轻松重写,就不是微服务。

 

1
猜你喜欢