服务粒度设计原则：粗粒度与细粒度的权衡

服务粒度，说白了就是服务拆得有多细。我见过太多团队一上来就追求「微」，结果拆出几百个服务，每个就两三个接口，运维成本直接爆炸。也见过一些项目把所有逻辑塞进一个服务，美其名曰「粗粒度复用」，结果改一行代码要回归整个系统。

这里没有银弹。但有几个原则，能帮你找到那个「刚刚好」的平衡点。

粗粒度 vs 细粒度：什么时候该拆？

我个人习惯用「业务变更频率」和「数据一致性要求」这两个维度来判断。

维度	倾向粗粒度	倾向细粒度
业务变更频率	多个功能同时变更	单个功能独立迭代
数据一致性要求	强一致性（分布式事务代价高）	最终一致性可接受
调用链长度	调用链短，延迟敏感	异步或批量处理
团队规模	小团队（5人以下）	大团队（康威定律）

举个例子。我在一个电商项目中，一开始把「订单创建」拆成了：库存校验、价格计算、优惠券核销、支付预扣、物流分单……五个服务。结果一次下单要串行调5次，延迟从50ms飙到300ms。后来我把「订单创建」合并成一个粗粒度服务，内部用本地事务处理，对外只暴露一个接口。延迟降回80ms，业务方也满意了。

服务自治性：每个服务都是自己的「小王国」

服务自治性，说白了就是每个服务能独立开发、测试、部署、运行，不依赖其他服务的内部状态。我见过最糟糕的反模式：服务A直接读取服务B的数据库。嗯，这等于把分布式系统的所有坏处都吃了一遍，好处一个没捞着。

自治性有几个硬性指标：

• 独立数据库：每个服务拥有自己的数据存储，不允许跨服务直接访问数据库。
• 独立部署：修改一个服务不需要同时部署其他服务。
• 独立演进：服务内部可以重构、换语言、换数据库，只要接口不变。
• 独立故障：一个服务挂了，不影响其他服务的正常运行。

无状态设计：让服务可以「随便杀」

无状态设计，是微服务能弹性伸缩的前提。你想想看，如果一个服务把用户会话存在本地内存里，那这个服务实例挂了，用户就得重新登录。这还怎么搞弹性伸缩？

无状态的核心就一句话：服务实例不存储任何与请求相关的状态。状态要么交给客户端（比如JWT），要么交给外部存储（比如Redis、数据库）。

我习惯用这个清单来检查服务是否「无状态」：

1. 服务启动后，不需要加载任何本地持久化数据？
2. 同一个请求发到任意实例，结果都一样？
3. 服务实例可以随时销毁，不会丢失数据？
4. 水平扩展时，不需要做任何数据迁移？

如果以上答案都是「是」，那你的服务就是无状态的。否则，你就要考虑把状态抽出去。

服务复用与组合的黄金法则

服务复用，不是把代码抽成公共库就完事了。SOA里的复用，是通过服务组合来实现业务能力。说白了，就是搭积木。

我总结了几条黄金法则：

• 法则一：接口稳定优先于接口丰富。一个服务提供10个稳定的接口，比提供50个经常变动的接口更有价值。接口变动一次，所有调用方都要跟着改，成本极高。
• 法则二：组合优于继承。不要试图让一个服务「继承」另一个服务的功能。用编排（Orchestration）或 choreography（ choreography）来组合服务，而不是修改服务本身。
• 法则三：复用粒度要对齐业务场景。比如「用户信息查询」这个服务，在「订单详情页」和「客服工作台」两个场景下，需要的字段可能完全不同。不要试图用一个万能接口满足所有场景，而是提供多个专用接口，或者用GraphQL做聚合。
• 法则四：避免循环依赖。服务A调服务B，服务B又调服务A，这是最典型的反模式。一旦出现，说明服务拆分有问题，需要重新审视边界。

下面这张图展示了服务组合的两种典型模式：

实战中的权衡决策

说了这么多理论，落地时到底怎么选？我分享一个真实案例。

之前做一个保险核心系统，有个「保单批改」功能。一开始我们拆了三个服务：批改申请、批改审核、批改生效。每个服务都很「微」，但问题来了——批改申请提交后，需要等审核通过才能生效，中间状态要跨服务维护。分布式事务、补偿机制、状态同步……搞得团队焦头烂额。

后来我们重新审视业务：批改这个场景，本质上是一个原子操作。用户提交批改，系统校验、审核、生效一气呵成，中间不应该有「等待」状态。于是我们把三个服务合并成一个「保单批改服务」，内部用本地事务+工作流引擎处理。代码量少了40%，线上故障也少了。

最后，记住一句话：服务粒度是动态的。今天合理的拆分，半年后可能就不合理了。别怕重构，也别为了「微」而微。服务设计是为业务服务的，不是为技术理想服务的。