自从微服务的概念和应用流行起来之后，受“微”的影响，有些人认为微服务越小越好，这显然是极端的想法。任何架构设计都有优缺点，在合适的场景才能发挥更大的作用。明确粒度设计的上下限，是用好微服务的第一步。

1.微服务设计的特点

微服务的核心思想是“分治”，可以类比活字印刷术。每个字都有独立的印刷效果。坏掉的字可以被迅速替换，不影响其他字。

微服务的三个特点：

• 独立

微服务之间彼此隔离，通过轻量级的通讯方式进行交互。基于一致的通讯协议，可以采用异构语言开发微服务。每个微服务拥有单独的代码仓库和运行环境，可以独立的部署、测试、发布。

• 内聚

将庞大的单体应用拆分为多个微服务，让每个服务专注于自己的业务，实现高内聚低耦合。强关联的功能和数据，都集中在一个服务中处理，确保数据一致性。

• 完备

一个微服务包含至少一项业务或领域的实体操作。提高团队协作的效率，降低研发人员管理微服务的心智负担。

2.微服务粒度的下限

如果微服务的粒度太小，会出现什么问题？

• 性能损耗

一次服务间的方法调用，步骤依次是网络传输、参数序列化、结果反序列化。网络传输是非常重的操作，即便在局域网里，网络延迟、超时也是家常便饭。而进程内的方法调用，系统级的耗时可以忽略不计。

• 数据一致性

如果微服务都有自己的数据源，当它们协同工作时，实现数据一致性的成本会很高。行业内也有两阶段提交（2PC）、三阶段提交（3PC）、TCC（Try、Confirm、Cancel）等分布式事务的解决方案，但是性能远不及数据库的本地事务。如果非要把关联性强的业务拆成多个微服务，要考虑设计冗余表，避免跨数据库的事务问题。

• 服务可用性

微服务之间并不清楚对方是否健康，遇到突发性的网络故障、服务宕机，只能通过重复调用来试探对方。微服务数量越多，不稳定性也会提高，管理成本也越高。

微服务粒度的下限，是能够至少操作一项业务实体，聚合强关联的功能与数据操作，并且独立测试、独立发布、独立运行。

3.微服务粒度的上限

编一个真实的故事，某老板想做一个APP，项目经理评估人力成本，2个程序员要20天才能完成。老板说，20天太慢了，找10个程序员，1天做完。

做软件不是搬砖，沟通成本与人数成正比，10个人不可能在1天内完成。软件工程经典书籍《人月神话》中提到：“为进度给项目增加人力，如同用水去为油锅灭火”，关于沟通成本，作者的结论是：

软件项目中的沟通成本= n×(n-1)/2，n 为参与项目的人数

从技术上看，只要微服务满足了独立、内聚、完备这三个特点，就可以良好的运行。从沟通成本上看，微服务粒度的上限是人与人之间的协作效率。

1992年，人类学家Robin Dunbar提出了人类的社交上线数量：不超过 5 个知己好友，15 个可信任的伙伴，35 个普通朋友，150 个说得上话的人。这几个数字被广泛认可，并被称为“邓巴数”。

依据邓巴的理论，如果软件团队规模超过了15人，沟通成本急剧攀升。微服务粒度的上限就是15个人能够胜任的最大程序规模。在人员数量不变的前提下，一个需求允许迭代的周期越长，这个团队的程序规模上限也会更大。

每个团队的开发能力不同，人员的数量不是定数，15也不是标准答案，我们可以称之为小型团队。微服务粒度的上限，是一个小型团队在一个研发周期内可以完成的全部需求。

4.微服务设计实例

我们用电商的需求《优惠券管理平台》进行微服务粒度设计的实战演练。

需求标题：优惠券管理平台
需求背景：
用户下单结算不支持优惠折扣活动，运营人员无法采用优惠活动进行用户留存和获客。
需求内容：
1.建设优惠券管理平台，运营人员申请营销预算，批量生成优惠券，按需赠送优惠券给不同画像的用户。后台管理增加两个模块：(1)营销预算管理。(2)优惠券管理：配置优惠券模版、生成优惠券、赠送优惠券。
2.购物车支持用户下单时使用优惠券。

这个需求新增了两个实体：优惠券和营销预算。营销预算与优惠券不是强关联的，发放优惠券只是营销手段的一种，未来有可能增加新的营销方式，微服务设计图如下所示：

1. 发送优惠券在领域层，应用层只需要查询优惠券服务。
2. 领域层增加优惠券服务和营销预算服务。
3. 后台管理服务调用领域层的服务完成配置功能。
4. 应用层的订单服务调用领域层的优惠券服务，扣减订单金额。

本文链接：https://www.codingbrick.com/archives/885.html
特别声明：除特别标注，本站文章均为原创，转载请注明作者和出处倾城架构，请勿用于任何商业用途。