您现在的位置是：首页 >技术教程 >如何设计微服务的粒度？网站首页技术教程

微服务有个永恒的话题，就是微服务的粒度到底该怎么定。一个人应该分到几个微服务，还是几个人一起维护一个微服务呢？

对于这个问题，你肯定听到过各式各样的答案。有讲 3 个人维护一个的，也有说应该两个人维护一个的，还有说一个人维护一个的。

划分微服务的粒度不仅需要考虑研发的人性，还要考虑服务本身的原子性、团队大小、团队人员的稳定性、服务的高可靠性要求等等。不过单从人性角度思考，如果你独立负责一个核心微服务的话，那么你的安全感和自尊都是最大化的。

这是从研发 ROI 的角度来思考微服务粒度的问题，我们还可以从微服务本身的设计出发来思考。微服务的核心价值在于以下几点：

1. 粒度小，单个服务可以紧贴业务快速迭代；
2. 去中心化组织和部署结构，减少不必要的协同；
3. 数据和商业逻辑受同一个服务控制，从而在商业逻辑快速变更的同时，保障数据模型的一致性；
4. 数据和状态独立封装，保障一个业务快速演变的同时，还不污染其他业务；
5. 服务本身的独立部署能力使得容错和容量弹性最大化；
6. 细粒度服务发布回滚和故障响应能够有效隔离，出了问题可以迅速降级或回滚。

其中第 1、2、3 项是人越少越高效的，最高效的状态就是一个人。想想看，你自己对业务有深度理解，能够和业务同频率迭代。你什么时候想改代码就改代码，不需要协同，改好了就上线。你自己一个人改自己的商业逻辑和数据模型，根本不需要担心其他人祸害。

在这种状态下，你的速度绝对是最快的。而且就你个人的能力为极限，也是协同越少，你能产出代码的质量越高。所以从这个角度来说，让多名研发维护一个微服务的配置是不合理的。

唯一能够支持多名研发维护同一个服务的理由，就是服务本身对公司的价值太大，它上面承载的业务量，对稳定性的要求，对服务连续性的要求，大到可以忽略研发资源的成本的时候；或者是从性能角度来看，服务无法拆分，它得复杂度大到可以支持多个研发维护的时候。在这种情况下，多个研发维护同一个服务的布局才是合理的。

当然，有些人认为一个服务上只有一名研发会有稳定性风险，这个理由不成立。微服务的隔离性和有分布式架构带来的稳定性，是能抗住个别同学离职的压力的。而且服务粒度越小，这种承受能力越大。

做微服务就像农民耕耘自己的土地一样。无论是古罗马，还是中国封建社会的历朝历代，再或是美国，开国之初都有过开荒屯田的政策，每个农民都可以分到一块属于自己的土地，国家也因此得到了飞速的发展。

此文章为6月Day5学习笔记，内容来源于极客时间《郭东白的架构课》，推荐该课程。