分布式单体与模块化单体架构差异、优势及微服务对比等技术问询

1. 分布式单体（distributed monolith）与模块化单体（modular monolith）架构之间存在哪些差异？ #

核心差异体现在部署形态、耦合逻辑和复杂度上：

• 部署方式：模块化单体是单个可执行文件/进程部署，所有模块运行在同一 runtime 环境中；分布式单体拆分为多个独立部署的服务进程，但服务间依然紧耦合，比如互相直接调用内部逻辑、硬编码依赖地址。
• 耦合程度：模块化单体通过清晰的模块边界实现逻辑解耦，模块间仅通过约定接口交互；分布式单体看似拆分了服务，实则还是单体思维，服务间依赖无明确边界，随意调用内部实现。
• 故障影响范围：模块化单体故障会波及整个应用，但排查、恢复相对简单；分布式单体的单个服务故障可能牵连大量依赖服务，排查复杂度远高于前者。
• 运维复杂度：模块化单体只需维护一套部署、监控体系；分布式单体要维护多套服务的部署、监控和网络通信，却无法享受微服务的真正优势。

2. 二者是否本质上共享单一数据库？ #

不一定，但多数场景下表现不同：

• 分布式单体：多数会共享单一数据库，因为拆分时未做数据边界划分，服务间仍需直接访问彼此的表；少数拆分了数据库的情况，也因服务紧耦合难以实现真正的数据隔离。
• 模块化单体：通常共享单一数据库，但会通过严格规则限制数据访问——每个模块仅操作自身业务域的表，禁止直接读写其他模块的表，跨模块数据交互必须通过目标模块的业务接口完成。

3. 模块化单体为何是一种可行的架构选项？ #

它平衡了单体的简单性与模块化的灵活性，适配多数中小团队或业务初期场景：

• 低复杂度：无需处理分布式架构的网络延迟、分布式事务、服务发现等问题，部署、运维、调试成本极低。
• 开发效率高：团队在同一代码库协作，模块间调用直接同步，无需额外跨服务通信逻辑。
• 可演进性：清晰的模块边界为未来业务扩张铺路，可平滑将独立模块拆分为微服务，避免从混乱单体直接拆微服务的痛苦。
• 一致性保障：共享数据库天然支持强一致性，无需额外分布式事务方案，适合对数据一致性要求高的业务。

4. 该架构与微服务（microservices）模式相比表现如何？ #

二者各有优劣，适用场景不同：

• 部署与运维：模块化单体只需发布一个包，运维成本低；微服务需部署多个服务，涉及服务发现、负载均衡等，运维复杂度高。
• 扩展性：微服务可针对单个服务独立扩容，适配流量不均衡场景；模块化单体只能整体扩容，资源利用率较低。
• 故障隔离：设计合理的微服务单个故障不会直接影响其他服务；模块化单体故障会波及整个应用。
• 开发协作：模块化单体适合小团队，代码库统一，沟通成本低；微服务适合大团队，各团队负责独立服务，减少代码冲突，但跨服务协作成本高。
• 一致性：模块化单体天然支持强一致性；微服务需通过分布式事务、最终一致性等方案解决，复杂度高。

5. 模块化单体架构中的边界是如何实施的？ #

主要通过代码规范、工具约束和流程保障落地：

• 代码结构划分：按业务域划分独立包/模块，比如order、payment、user，每个模块包含自身业务逻辑、数据访问层和对外接口。
• 依赖控制：模块间只能通过公开接口（如Service层公共方法）交互，禁止直接访问其他模块的内部类、私有方法或数据模型。
• 数据访问边界：每个模块仅操作自身对应的数据库表，禁止跨模块直接执行SQL或调用其他模块的DAO层；跨模块数据需求必须通过目标模块的业务接口获取。
• 架构守护工具：使用ArchUnit等静态代码分析工具，自动检查模块间依赖关系，拦截非法跨模块调用。
• 流程保障：代码评审环节严格检查边界规则执行情况，确保所有团队成员遵守架构约定。

内容的提问来源于stack exchange，提问作者Linkx_lair