Monoliths vs Microservices

Trade-off 快览

• Monolith：简单、部署快、上手容易，但扩展与迭代会变慢
• Microservices：更易 scale 与独立迭代，但 service 管理、数据一致性和通信成本更高

小型产品常以 monolith 起步，随着规模增长再拆成 microservices 以提升敏捷性与可扩展性。

Monoliths

Monolith 是一个自包含、独立的应用，作为单一单元构建与部署。它不仅负责某个局部任务，而是承担满足业务需求的完整流程。

Advantages

• 开发与 debug 简单
• 通信快速可靠
• 监控与测试容易
• 支持 ACID transactions

Disadvantages

• codebase 越大，维护越难
• 紧耦合，不易扩展
• 技术栈绑定
• 每次更新都要整体 redeploy
• 单点 bug 可能拖垮整个系统
• 难以 scale 或引入新技术

Modular Monoliths

Modular Monolith 是在保持单体部署的前提下，把代码按业务功能拆成独立模块。这能降低模块依赖，使单个模块可独立演进而不影响其他模块。做得好可以降低系统增长带来的复杂度。

Microservices

Microservices 架构由多个小型自治服务组成，每个服务自包含，负责单一业务能力（bounded context）。Bounded context 是业务逻辑的自然边界，边界内有自己的 domain model。

每个服务有独立 codebase，可由小团队维护。服务可独立部署，团队可以更新单个服务而无需重建整个系统。

服务负责自己的数据持久化（database per service），不同于传统模式里统一的数据层。

Characteristics

• Loosely coupled：服务解耦，独立部署与扩展，团队也更自主。
• Small but focused：重点是 scope 与职责，不是 size；服务只做一件事并把它做好。
• Built for businesses：围绕业务能力组织。
• Resilience & Fault tolerance：服务需具备容错能力。
• Highly maintainable：易维护、易测试。

Advantages

• 服务解耦
• 独立部署
• 多团队并行开发更敏捷
• 更好的 fault tolerance 与数据隔离
• 可独立扩展
• 不被单一技术栈长期绑定

Disadvantages

• 分布式系统复杂度高
• 测试更困难
• 维护成本高（多 server、多 database）
• 服务间通信复杂
• data integrity / consistency 挑战
• 网络拥塞与 latency

Best practices

• 以业务 domain 建模服务
• 保持低耦合、高内聚
• 隔离故障，避免 cascading failures
• 仅通过良好设计的 APIs 通信
• 数据存储归服务私有
• 避免共享 schema 与刚性协议
• 去中心化，团队自治
• 用 circuit breaker 实现 fail fast
• API 变更保持 backward compatibility

Pitfalls

• 服务边界不是业务驱动
• 低估分布式系统难度
• 共享数据库或公共依赖
• 缺少业务对齐
• 责任边界不清
• 缺乏 idempotency
• 盲目追求 ACID 而非 BASE
• 缺少 fault tolerance 设计导致连锁故障

Beware of the distributed monolith

Distributed Monolith 指表面上像 microservices，但内部依然紧耦合的系统。以下情况说明你可能只是构建了分布式单体：

• 需要低 latency 的紧密通信
• 服务无法独立 scale
• 服务之间强依赖
• 共享数据库等资源
• 系统高度耦合

Microservices 的核心价值是 scalability 与解耦。如果服务彼此强依赖，就会引入复杂度，失去 microservices 的好处。

Microservices vs SOA

Service-oriented architecture (SOA) 有时被拿来和 microservices 混用，但本质不同，差异在于 scope。

SOA 强调通过服务接口复用软件组件，使用统一通信标准，追求应用级复用；microservices 则更强调小而自治的服务单元，关注 team autonomy 与解耦。

为什么你可能不需要 microservices

Monolith 并不一定是坏选择。通常建议从 monolith 起步，因为 microservices 不是银弹，它主要解决组织与协作问题。

在决定迁移到 microservices 前，可以先问：

• "团队是否太大，无法在同一 codebase 高效协作？"
• "团队是否互相阻塞？"
• "microservices 是否带来明确的 business value？"
• "业务是否足够成熟需要 microservices？"
• "当前架构是否被沟通成本限制？"

如果你的应用不需要拆成 microservices，那就没必要引入它。

我们常被 Netflix 等公司案例影响，但忽略了规模与阶段差异。他们经历了大量迭代，microservices 对他们是为了解决特定问题。

所以关键是判断你的业务是否真的需要 microservices。Microservices 解决的是复杂组织问题，如果业务还不复杂，就别引入过度复杂度。