谈谈微服务的粒度

谈谈微服务的粒度

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

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. 应用层的订单服务调用领域层的优惠券服务,扣减订单金额。

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注