微服务拆分应以有界上下文为边界，通过事件风暴识别业务语义差异，用事件驱动替代同步调用，抽离编排逻辑至轻量协调层，并接受最终一致性。
避免分布式带来的复杂度，核心不是“怎么处理问题”，而是“怎么不制造问题”。微服务演进中真正的陷阱，往往出现在架构决策初期——比如过早拆分、忽视边界、强求实时一致、把协调逻辑写死在业务服务里。
先从业务边界开始，而不是从技术拆分开始
服务拆分不是按数据库表或功能模块切分，而是围绕“有界上下文”（Bounded Context）展开。例如电商系统中，“订单”和“库存”看似紧密，但实际业务语义不同：订单关注履约流程与用户契约，库存关注物理商品可用性与仓配协同。强行合并或强同步，反而引入耦合。
建议做法：
- 用事件风暴（Event Storming）工作坊梳理核心业务流程，识别聚合根与领域事件（如 OrderPlaced、InventoryReserved）
- 每个服务只拥有自己聚合内的数据，禁止跨服务直接读写对方数据库
- 拆分后验证：一个服务能否独立部署、测试、扩缩容，且不依赖其他服务的代码或运行时？
用事件驱动替代同步调用，天然规避分布式事务
90% 的“分布式事务需求”，其实源于设计上把本该异步协作的流程写成了同步链路。比如用户下单后扣库存+发券+通知物流，不需要全部成功才返回“下单成功”，而应以订单创建为起点，后续动作通过事件触发。
立即学习“Java免费学习笔记（深入）”；
关键实践：
- 对外暴露的 API 只做本地事务（如持久化订单主表 + 发送 OrderCreatedEvent），不等待下游结果
- 用 Kafka/RocketMQ 做事件总线，各服务订阅自己关心的事件，自行决定执行时机与重试策略
- 所有事件携带完整上下文（如 orderId、userId、version），避免下游反复查库
把编排逻辑抽离出来，不塞进任何一个业务服务
当多个服务需要按序协作（如履约流程涉及订单→仓储→配送→签收），别让订单服务硬编码调用仓储接口、再调用配送接口——这会形成隐式依赖，一改全崩。
更轻量的做法是引入“编排层”（Orchestrator），它不是新服务，而是一个职责明确的协调模块：
- 只负责接收事件、触发命令、记录状态、发起补偿，不处理业务规则（如不判断是否超时、不生成运单号）
- 用 Spring Cloud Function 或 AWS Step Functions 实现，逻辑控制在 200 行以内
- 所有调用走事件通道（如 DispatchOrderCommand），而非直连 HTTP 接口
接受最终一致性，放弃对“强一致”的执念
微服务不是不能做一致性，而是要区分场景：用户余额变更必须强一致，但“订单已发货”状态同步到搜索服务延迟几秒完全可接受。CAP 定理下，分区容错（P）不可妥协，只能在 C 和 A 之间权衡。
落地建议：
- 对强一致场景（如支付扣款），优先使用 TCC 模式（Try-Confirm-Cancel），由业务定义资源预留与确认逻辑，比 2PC 更轻量
- 对非关键状态（如统计类、展示类数据），用 CQRS 架构分离读写模型，写端发事件，读端异步构建视图
- 所有跨服务状态变更，都配套幂等接口与去重机制（如基于 eventId + serviceId 做唯一索引）
