微服务模式

问题从哪来

单体在团队与发布节奏上还能撑住时，很少有人主动拆服务；一旦边界模糊、模块互相拖库表、一次发布牵动全站，讨论就会落到「怎么拆」和「拆完怎么不更糟」。分布式数据一致性、跨服务事务、故障传播与可观测性缺口，往往比「用不用 Spring Cloud」更早卡住设计。

技能怎么推进设计

本技能把微服务架构当成一组可复用的模式来用，而不是堆技术栈清单。它会引导你：

• 划定领域边界与所有权：每个服务负责什么数据、谁对外暴露契约。
• 定义契约与通信方式：同步 API、异步消息、事件驱动等选型与边界。
• 规划弹性与可观测性：超时、重试、熔断、链路追踪与部署策略如何与模式对齐。
• 给出迁移与运维防护栏：从单体切分的步骤，以及上线后需要守住的约束（例如避免共享数据库写路径）。

更细的模式说明与示例在 resources/implementation-playbook.md 中，适合在设计评审或迁移方案起草时对照。

适用边界

若系统规模仍适合模块化单体、需要快速原型且不想承担分布式运维成本，或团队尚缺服务发现、配置、监控与发布流水线等基础能力，强行套用微服务模式通常只会放大复杂度。先确认运维与组织能否支撑多服务生命周期，再按本技能的步骤收紧边界与契约。