微服务设计

服务拆到第几层才算微服务

当单体应用的功能堆叠到几十个模块、一次发布要协调多个团队时，微服务改造就从「技术选型」变成了「架构负债」。但拆服务本身不会自动带来敏捷：服务边界画错、调用链路过长、故障缺少隔离，往往会把单体问题原样搬进分布式系统，还额外引入网络延迟和一致性难题。这个技能面向正在做服务拆分、或已经拆完但运行吃力的工程团队，提供一套可直接对照的设计准则。

核心设计原则

• 围绕业务能力划分边界。 每个服务对应一个明确的业务能力，独占自己的数据存储，只通过清晰的 API 契约对外暴露能力，而不是按技术层（Controller / Service / DAO）切分。
• 事件驱动通信。 异步流程通过事件流转，事件处理器必须使用 eventId 幂等键安全地处理重复投递，保证 at-least-once 投递下结果依然正确。
• Saga 模式管理分布式事务。 跨服务的多步操作采用编排式 Saga，每一步附带补偿逻辑，而不是用分布式事务锁住资源。
• API 网关与健康检查。 网关统一处理路由、限流与认证；健康检查端点如实上报依赖状态，配合熔断器阻断级联故障。

明确列出的反模式

技能文档直接点名了几类典型错误：服务间共享数据库造成紧耦合；跨服务同步 HTTP 调用链引发级联失败；构建无法独立部署的「分布式单体」；服务间调用缺少熔断器；事件处理器不实现幂等；用分布式事务替代 Saga。

适用边界

这套准则默认团队已具备容器化部署、服务发现和可观测性等基础设施，它解决的是架构设计决策，不能替代 CI/CD 流水线或监控体系建设。对业务边界尚未稳定的早期小团队，先把单体跑顺可能更务实。