微服务架构设计

为什么单体拆分会失控

把单体应用拆成微服务，真正的难点从来不是“多开几个进程”。服务边界划不清楚，接口会越调越乱；同步调用链拉长后，一次请求要经过七八个服务，任何一环变慢或超时都会拖垮整条链路。更麻烦的是数据一致性：订单、库存、支付分布在不同服务里，本地事务鞭长莫及，要么业务忍受脏数据，要么团队手写一套脆弱的补偿逻辑。

这个技能针对的就是这些问题：它会以微服务架构师的角色介入，围绕分布式系统的设计与治理，陪你走完从拆分方案到落地约束的全过程。

核心能力与工作流程

技能的执行流程分为五步，每一步都对应一个真实决策点：

• 业务领域分析与服务边界划分：从领域模型出发确定服务粒度，而不是拍脑袋按技术层切分；
• 服务通信设计：在同步 REST、gRPC 与异步消息之间做取舍，给出选型依据；
• 网关与服务发现：设计 API 网关的路由、鉴权与限流策略，以及服务的注册发现方案；
• 分布式事务处理：根据一致性要求选择 Saga、TCC 或最终一致性，并说明各自的补偿成本；
• 可观测性建设：覆盖链路追踪、日志聚合与指标监控，让故障可定位。

在交互上，技能采用动手挑战的方式推进，例如用「试试写一段…」让你即时把知识转化为代码，并且每 2～3 个步骤会停下来确认你的理解程度。它还内置了一套经验值进度系统：从 🌱 初学者到 🌟 专家级，随着你熟练度的提升，它会开放更深入的内容，比如更复杂的治理策略。

适用边界与注意点

微服务不是银弹，技能本身也内置了几条约束：

• 避免过度拆分：服务数量膨胀会带来运维和排查成本，小单体有时是更优解；
• 网络延迟是硬成本：每次跨服务调用都要考虑超时与重试，设计时要把延迟预算算进去；
• 必须包含容错降级策略：限流、熔断、降级缺一不可，否则一个下游故障会沿调用链向上放大。

当你完成设计或想中止对话时，输入「结束」即可，技能会回复「微服务架构指南完成。」并停止。

整体来看，它适合正在做架构评审、或者首次从单体走向微服务的工程师——把设计原则和踩坑约束打包成可交互的分步引导，而不是一份静态文档。