第3章服务粒度设计

3. 服务粒度设计：细粒度服务与粗粒度服务的权衡、服务拆分策略

服务粒度这个问题，我几乎在每一个SOA项目里都会被问到。说白了，就是你的服务到底要拆多细？拆太细了，系统像一盘散沙，调用链长得吓人；拆太粗了，又回到了单体应用的老路，服务之间耦合严重。嗯，这里面的门道，我今天跟你好好聊聊。

先说说细粒度服务。我习惯把细粒度服务理解为「原子操作」。每个服务只做一件事，比如「查询用户基本信息」、「更新用户邮箱」、「获取订单金额」。这种服务接口非常小，职责单一，复用性极高。

但问题也很明显。我在一个电商项目中遇到过，团队把「下单」这个业务拆成了十几个细粒度服务：校验库存、锁定库存、计算价格、生成订单、扣减积分……结果一个下单请求要串行调用十几个接口，响应时间从200ms飙到了2秒多。你想想看，用户能忍吗？

粗粒度服务正好相反。它把多个业务步骤打包成一个接口，比如「提交订单」这个服务，内部包含了校验、计算、生成、通知等一系列操作。对外暴露的接口少，调用方省心，网络开销也小。

但粗粒度也有坑。我曾经接手过一个遗留系统，一个「用户管理」服务包含了注册、登录、修改密码、查询资料、甚至还有发邮件功能。你想改个密码逻辑，得把整个服务重新部署一遍。这就是典型的「大泥球」。

核心权衡点：

服务到底怎么拆？我总结了一套自己的方法，不一定适合所有场景，但至少能帮你少走弯路。

这是最直观的方式。把业务领域拆成一个个独立的「能力单元」。比如电商系统，可以拆成：用户服务、商品服务、订单服务、支付服务、库存服务。每个服务对应一个完整的业务域。

我在做金融系统时，就按「账户」、「交易」、「风控」、「清算」来拆。每个服务内部可以再细拆，但对外暴露的粒度要适中。说白了，就是让一个服务能独立完成一个「业务闭环」。

这个思路很有意思。你想想看，有些业务逻辑天天变，比如促销规则、价格计算；有些业务几年不变，比如用户注册、登录验证。把它们混在一起，每次改促销规则都要重新部署整个服务，太蠢了。

我建议把「高频变化」和「低频变化」的逻辑拆成不同服务。这样，你改促销规则时，只需要重新部署促销服务，用户服务完全不受影响。我曾经在一个项目中，把「价格计算」单独拆成一个服务，结果每次大促改价，只需要改这一个服务，爽得不行。

服务拆分到最后，你会发现数据才是最难搞的。两个服务如果共享同一个数据库，那它们本质上还是一个服务。所以，我习惯先画数据模型，看哪些数据是「强关联」的，哪些是「弱关联」的。

举个例子：订单数据和支付数据是强关联的，一个订单对应一个支付记录。但订单数据和用户画像数据就是弱关联的，只需要通过用户ID关联即可。所以，订单服务和支付服务可以拆开，但订单服务和用户画像服务必须拆开。

我的小技巧：

刚开始拆服务时，别追求一步到位。我习惯先拆成「粗粒度」的服务，运行一段时间后，再根据调用频率、变更频率、性能瓶颈，逐步拆成更细的服务。这叫「演进式拆分」，比一开始就追求完美要靠谱得多。

有没有一个标准答案？说实话，没有。但我可以给你几个判断标准：

我个人习惯遵循一个原则：一个服务应该能独立完成一个「业务用例」。什么叫业务用例？就是用户能感知到的、完整的业务操作。比如「用户下单」是一个用例，「查询订单状态」是另一个用例。每个用例对应一个服务接口，内部可以调用其他服务，但对外暴露的粒度就是用例级别。

避坑指南：

我曾经犯过一个错误：为了追求「完美」的细粒度，把「用户注册」拆成了「校验手机号」、「发送验证码」、「创建用户」、「初始化积分」四个服务。结果每次注册都要调用四次，而且还要处理分布式事务。后来我改成了一个「用户注册」服务，内部串行调用这些逻辑，对外只暴露一个接口。调用方爽了，我也爽了。

所以，别为了「微」而「微」。服务粒度不是越细越好，而是越「合适」越好。

服务粒度设计，说白了就是一场「权衡」游戏。细粒度让你灵活，但增加了复杂度；粗粒度让你简单，但牺牲了灵活性。我的建议是：

嗯，这一章就聊到这里。下一章我会讲讲服务接口的版本管理，这可是个容易踩坑的地方，到时候再跟你细说。