纳米服务是什么
纳米服务是服务拆分过细导致的反模式：一次业务请求需要跨越十几个甚至几十个服务调用，调用风暴、跨服务事务与部署对象数量急剧上升，运维与调试复杂度超过细粒度带来的收益。它的成因通常不是刻意追求细粒度，而是按数据表或按方法机械拆分，或者把团队组织结构直接映射成服务边界。
怎么校准粒度
粒度应与事务边界和团队边界匹配：需要同版本发布的两个服务在部署意义上仍属同一单元，应当合并或先解除耦合；单个用例跨越五个以上服务说明边界可能切错；跨服务强事务频繁意味着事务边界被切碎，应把强一致逻辑收回到一处。页面加载需要数十次请求则说明缺少聚合层，可引入组合服务或面向前端的聚合层来收敛调用次数。
基本信息
| 识别信号 | 单个用例跨越大量服务；一次页面加载发起数十次远程调用 |
|---|---|
| 主要代价 | 网络开销、故障放大、分布式事务与调试成本 |
| 常见成因 | 按数据表或方法拆分；组织边界被直接映射成服务边界 |
| 应对手段 | 合并高耦合服务、引入聚合层、收回强事务逻辑 |
| 判断基准 | 事务边界与团队边界是否与服务边界对齐 |
粒度校准信号
| 信号 | 含义 | 动作 |
|---|---|---|
| 一次用例调用五个以上服务 | 粒度可能过细 | 评估合并或引入聚合服务 |
| 两个服务必须同步发布 | 部署上尚未解耦 | 合并或先解除依赖 |
| 跨服务强事务频繁 | 事务边界被拆碎 | 把强一致逻辑收回一处 |
| 页面加载需要数十次请求 | 缺少聚合层 | 引入组合服务或聚合层 |
典型使用场景
- 微服务拆分评审时判断边界是否过细，避免上线后无法收敛
- 接手现有服务地图时识别高耦合的集群，规划合并顺序
- 排查延迟问题时区分是网络跳数过多还是单个服务本身慢
- 评估是否引入聚合层以降低客户端的调用次数
服务粒度应与事务边界和团队边界匹配，而不是按方法或数据表拆分；判断粒度最终要回到一次业务变更会牵动多少服务。
为减少调用而层层叠加聚合服务，聚合层很快会变成新的单体，反而把变更阻塞在一处，失去拆分原本的意义。