服务粒度是什么
服务粒度指一个服务应当覆盖多大的业务范围。它需要综合事务边界、团队边界、变更频率与数据耦合来判断，不能按代码行数或接口数量机械切分。粒度过粗会失去独立演进的价值，过细则产生大量跨服务调用与协调成本。
怎么判断
常用的入手点是变更耦合度：经常一起改的功能放进同一服务，改动互不相干的功能分开。其次是事务边界：需要强一致的多张表变更应当落在同一服务或同一聚合内，否则就要面对分布式事务。最后是团队边界：由不同团队独立负责、有独立发布节奏的部分，才值得真正拆出去。
判断信号
| 信号 | 倾向 |
|---|---|
| 经常一起变更 | 合并为同一服务 |
| 需要强事务保证 | 放进同一聚合或服务 |
| 由不同团队独立负责 | 拆分为独立服务 |
| 跨服务调用链超过三层 | 考虑合并或引入编排 |
| 读多写少且可缓存 | 可独立拆分以便单独扩容 |
典型使用场景
- 单体拆分：按业务子域而非技术分层切成候选服务
- 服务合并：发现两个服务总是一起发布，评估合回一个
- 跨服务事务治理：判断该引入编排还是该调整边界
- 团队划分：让服务边界与团队边界大致对齐
- 扩容评估：把读多写少的模块单独拆出以便独立扩容
粒度随业务与团队演进而调整，并非一次定终身。先粗后细通常比一开始就拆细更稳妥：合并不难，拆开需要先把边界欠债还清。
如果两个服务之间每次变更都要同步改对方、同步上线，那么它们事实上还是一个服务，拆分只增加了部署复杂度而没有带来自治。