浅析模块化单体会不会取代微服务架构

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

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

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

• 依赖项——内部代码和数据库依赖项

• 隔离——每个功能都会影响其他功能（性能、安全等）

• 可重用性——对象的有限重用

• 代码复杂性 - 大量带有内部引用的代码

• 性能——不可能仅在需要的功能中调整和解决性能问题，而且成本巨大

• 可维护性

• 可扩展性——无法仅扩展特定功能，要么全有，要么全无

• 弹性——没有选择仅在需要时以具有成本效益的方式实施弹性

• 测试周期时间——每次更改，即使是很小的更改，都需要完整的系统测试

• 使用多种技术（适合每个业务需求的技术）

• 并行工程

• 敏捷 SDLC

• CI/CD

微服务

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

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

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

• 工作成本——许多管道、安全规则等。

• 基础设施成本——许多容器/pod

• 解决方案复杂性——许多组件

• 数据共享——应用级别和业务领域级别的表/实体

• 代码共享（除非使用 MonoRepo）

• 数据所有权——多个服务拥有的特定表/实体

• 缓存

• 业务领域报告和仪表板

• 跨微服务特性

• GUI（如果实现了微前端架构）

• 端到端测试

• 日志记录和问题根本原因分析

模块化单体

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

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

• 在模块化单体中，就像微服务一样，每个模块通过 API 与另一个模块通信，最好是松散耦合的异步通信。

• 在像单体一样的模块化单体中，系统有一个数据库模式，而不是微服务，每个微服务都应该有自己的模式。

• 通常，模块化单体中的所有模块都在同一个 VM 上运行。或者每个模块在特定的专用 VM 上运行。模块太大而无法放入容器中。

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

• 更简单的管理

• 更多隔离

• 更少的依赖

• 降低企业责任风险

• 提高可重用性

• 更好的可维护性

• 更简单的测试

• 更好的安全性

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

• 更简单的操作和支持

• 更少的 API 带来更好的性能

• 降低基础设施成本

• 本机数据共享、报告和仪表板

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

普通保险示例

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

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

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

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

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

• 付款是一样的，不管是汽车保险、房屋保险等，所以我们有一个付款的微服务。

• 管理文件和档案是一样的，所以我们有一个文件微服务。

• 客户大多是一样的，所以我们有一个客户微服务（值得商榷。有些人倾向于拥有汽车客户微服务，因为有一些独特的属性，然后在一个外部系统或一个专门的微服务中管理客户360。我更倾向于拥有一个客户微服务，因为大多数属性是相同的，而且我们想集中查看一个客户的所有信息。在这种情况下，我们可以在汽车保单微服务、旅行保单微服务等中管理客户的独特信息。）

• 对于每个保险（汽车、旅游等），我将有一个专门的保单微服务（例如汽车保单、旅游保单等），它将包括保单、保险、核保、除外责任等。

总结

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

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

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