单体应用在项目初期开发快、部署简单。但当你的团队超过 10 人、代码量超过 10 万行时，单体的缺点开始暴露——部署阻塞、代码冲突、无法独立扩缩容。微服务不是万能药，但在正确的场景下它是正确的答案。

什么时候需要微服务

不是每个项目都需要微服务。以下信号表明你该考虑拆分了：不同模块有不同的扩缩容需求、不同模块由不同团队独立负责、不同模块需要不同的技术栈、单个模块的修改频繁阻塞整个系统的发布。

如果你的应用只有几千日活用户、团队不超过 5 人——保持单体。架构演进是按需的，不是冲动的。

DDD 限界上下文：拆分依据

如何决定拆分的边界？答案在领域驱动设计（DDD）的限界上下文中。每个限界上下文对应一个微服务：用户（User Context）、订单（Order Context）、支付（Payment Context）、库存（Inventory Context）。彼此之间通过 API 或消息队列通信。

拆分原则：高内聚（一个上下文内的逻辑紧密相关）、低耦合（上下文间的依赖最小化）、数据独立（每个微服务拥有自己的数据库，不共享表）。

服务间通信

模式 适用场景 特点
REST/gRPC（同步） 实时查询、命令 简单直接，但形成调用链
消息队列（异步） 事件通知、数据同步 解耦，最终一致性
Event Sourcing 审计要求高 完整事件日志，可回溯
CQRS 读写负载差异大 读写分离，独立优化

核心原则：命令用同步（我需要立刻知道结果），事件用异步（发生了这件事，相关方自行处理）。

SAGA：分布式事务

微服务中你不能用数据库的 ACID 跨服务做事务。SAGA 通过一系列本地事务 + 补偿操作来实现最终一致性：每个步骤成功后触发下一步，任一步骤失败则反向执行补偿操作。

两种 SAGA 模式：编排式（一个协调器指挥各服务执行）和事件驱动式（各服务监听事件自行决定下一步）。编排式清晰但中心化，事件驱动式解耦但复杂。

API Gateway / BFF

微服务多了以后，前端面临 N 个不同端点的问题。API Gateway 提供统一入口——路由、聚合、认证、限流都在网关层完成。BFF（Backend For Frontend）更进一步——为每种客户端（Web/iOS/Android）定制专属网关。

容错设计

分布式系统必然会有部分服务故障。三个核心容错模式：

  • 超时（不要无限等待——给每个远程调用设超时）
  • 重试（超时后重试，但要幂等+退避）
  • 熔断（连续失败后暂时停止调用，避免级联故障）

总结

微服务解决的是组织规模化问题，不是技术炫技。DDD 帮你找到正确的拆分边界，SAGA 解决分布式事务，API Gateway 统一入口。但记住第一条原则——如果能用单体搞定，先用单体。微服务是结果，不是目标。