浅析模块化单体会不会取代微服务架构-优快云博客

关于模块化单体的讨论很多。我们可以在许多趋势图中看到这一点。许多研发经理都在询问这是否是微服务或其他东西的替代品/替代品。

本文解释什么是模块化单体，为什么有些人认为它是微服务的替代品，以及我对使用不同架构模式的建议。

单体应用的缺点 = 微服务的优点单体架构模式有很多缺点。这些促使几乎每个人都转向微服务模式。话虽如此，微服务并非都是好的，它们也有挑战和弱点，我将在后面简要描述。单体应用的主要缺点和微服务优点是：

微服务

由微服务、容器、CI/CD 和 DevOps 组成的 Cloud Native 改变了游戏规则；它改变了我们构建和部署应用程序的方式。创建微服务作为基础是为了解决这些单体挑战。

简单来说，微服务是一种架构模式，它将应用程序分解成更小的、独立的组件，这些组件不依赖于特定的技术堆栈（编码语言、数据库等）。

这些小组件称为“服务”，通常部署到容器中。微服务“大小”的最佳实践是业务领域或业务实体中的一项功能，例如支付、检查库存、客户 CRUD、产品目录、产品定价、送货地址、送货管理等。微服务并不都是好的，它们也有自己的挑战，例如：

模块化单体

模块化单体应用并不新鲜。在大多数情况下尚未完全实施的理论最佳实践总是将系统分解为模块。以正确的方式将系统拆分为模块是一个模块化的单体。

模块化单体的常见替代名称是“宏服务”。宏服务将系统分解为功能（一个功能由多个业务域组成）。模块化单体/宏服务的高级技术特征：

与事实上的单体应用相比，使用模块具有许多优势：

现在我们了解了为什么从单体架构切换到模块化单体架构更好，我们将比较模块化单体架构和微服务。模块化优于微服务的优点是：

微服务相对于单体架构的优势与模块化单体架构的优势完全相同，因此直接得出的结论是，在从头开始构建系统时，模块化单体架构无法替代微服务。从两端握住大棒，一边是单体，另一边是微服务，都是微型服务。

普通保险示例

在过去，普通保险是一个巨大的系统，一个单体，就像养老金、长期储蓄、人寿、健康、航运等等。

有许多选项可以将单体分解为模块单体--纵向或横向的。纵向将基于一般的保险类型，如汽车、住宅、旅游等。横向将基于功能：客户、政策、索赔等。

将单体分解成微型服务将是纵向和横向的结合，将产生汽车保单（汽车保单与家庭、旅行和商业保单几乎没有共同之处）、汽车索赔、旅行保单、旅行索赔等。

将单体分解为微服务是每个迷你服务中的一个功能或业务实体，将产生：汽车客户、汽车保单、汽车保单保险、汽车保单账单、汽车保单付款、汽车保单文件、汽车供应商、汽车评估师、汽车索赔、汽车索赔法律、汽车索赔保险支付、汽车索赔赔偿等。

我们可以使用迷你服务和微服务的组合进行细分：

付款是一样的，不管是汽车保险、房屋保险等，所以我们有一个付款的微服务。
管理文件和档案是一样的，所以我们有一个文件微服务。
客户大多是一样的，所以我们有一个客户微服务（值得商榷。有些人倾向于拥有汽车客户微服务，因为有一些独特的属性，然后在一个外部系统或一个专门的微服务中管理客户360。我更倾向于拥有一个客户微服务，因为大多数属性是相同的，而且我们想集中查看一个客户的所有信息。在这种情况下，我们可以在汽车保单微服务、旅行保单微服务等中管理客户的独特信息。）
对于每个保险（汽车、旅游等），我将有一个专门的保单微服务（例如汽车保单、旅游保单等），它将包括保单、保险、核保、除外责任等。

总结

在现代化项目中，我们采用现有系统（可能是单体系统）并对其进行重建。重建的需要可能有很多原因：云迁移、技术债务、安全风险、拥有成本、交付业务需求的能力等等。在现代化项目中，必须做出的首要决定之一是我们是要迁移系统还是从头开始构建系统。

在某些情况下，即使从头开始构建系统的成本要高得多——这仍然是值得的，无论是因为技术债务的水平，还是因为新的和未来业务需求的数量。如果我们选择现代化路径，我更喜欢使用模块化单体架构模式，因为它降低了我们的风险和成本，支持增量迁移，并改善了当前的单体状况。

从头开始构建新系统时，我更喜欢结合使用微服务和迷你服务。模块化单体的缺点是如此之大，以至于在我看来，这不是一个可行的选择。有什么不同的见解欢迎提出。