Categories
程式開發

放弃微服务,改用宏服务,Uber这波什么操作?


Uber 支付体验平台放弃了微服务,转而使用了宏服务,这一消息在网友中引起了热议。一向是微服务积极分子的 Uber 为什么突然改用宏服务了?以“简单”著称的微服务为什么又变得难以维护了呢?

Uber 支付团队放弃微服务,转用宏服务

4 月 6 日,Uber 支付体验平台的工程经理 Gergely Orosz 发布推文表示其团队的架构方向已经发生了变化,放弃微服务,转而使用宏服务。

放弃微服务,改用宏服务,Uber这波什么操作? 1

为什么会做出这样的选择呢?Gergely Orosz 表示:“最早,Uber 通过构建微服务来完成很小的需求或功能,以至于出现了很多由一个人构建维护的微服务。这些微服务的存在给我们带来了新的复杂性和挑战,例如监控、测试、持续集成 / 持续交付(CI/CD)、服务级别协议(SLA)、跨所有微服务的库版本(安全和时区问题)等等。”

因此,在创建新平台的时候,Uber 支付体验团队对新服务进行了更加深思熟虑的规划:不再只是完成一件事,而是使其服务于一项业务功能,由 5-10 个工程师负责维护。Gergely Orosz 把这样的服务规划称之为宏服务。

为什么一向以简单著称的微服务,在 Uber 的实践中突然就变得难以维护了呢?我们先来看一下微服务到底“微”的是什么呢?

微服务到底“微”的是什么?

微服务是什么?百度百科给出的解释是:“微服务是一个新兴的软件架构,就是把一个大型的单个应用程序和服务拆分为数十个的支持微服务。”其中,最关键的部分是开发者要能够对服务中的某些部分进行衡量,并将其对应价值控制在最低水平。

那么,微服务到底“微”的是什么?

微团队

微服务首先“微”的就是服务开发团队的规模,而且它有一个很特别的衡量单位——“披萨”。亚马逊 CEO Jeff Bezos 提出了著名的两个披萨原则,即每一个内部团队的规模必须足够小,小到两个披萨饼就可以喂饱整个团队。

两个披萨团队真的有效吗?有人认可,但也有人质疑,有网友曾吐槽:“这种说法一看就很假,我手下有不少只需要一个披萨的团队,但他们做出来的东西仍然是一团乱麻。”

微代码库

微服务,“微”的也可能是代码库,有人甚至会将“微代码库”这个概念发挥到极致,限制某项服务中所包含的代码行数。

代码库小当然有好处,代码库越小,对应的业务范围就越小,越易于理解、实施和开发,同时引发大失误的概率低,而且出现失误时,重构的难度也更低。

但是大家真的认可代码库这种硬性指标吗?如果认可的话,那么我们把范围缩小到每行代码包含多少个字符,岂不是更好?

我们可以通过很多种方式来定义服务边界,代码库大小绝对是其中最低效的一种。—— Nick Tune

“微系统”

事实上,微团队和微代码库都是“微服务”的理想化产物,大家似乎忘记了系统才是最关键的部分,系统是服务的容身之所。

我们真正需要构建的是系统,而不是一组服务。我们使用微服务的目的在于优化系统设计,而不是单纯设计一个个独立服务。事实上,我们很难使用真正独立的组件建立起庞大的系统,因为这在本质上违背了“系统”的核心定义:

一组相互联系的事物或设备,它们能够共同运作;

一组共同用于特定目标的计算机设备及程序;

彼此交互的服务才能建立起系统,如果只优化系统中的服务,而忽略服务间的交互,就会出现下图的情况:

放弃微服务,改用宏服务,Uber这波什么操作? 2

“微服务”本身可能非常简单,但是交互建立起的系统将成为新的复杂性瓶颈。

从系统的角度来看服务的复杂性

系统复杂性并不是现在才有的问题,四十年前,没有云计算,没有全球规模需求,也不需要 11.7 秒部署一次系统,但是工程师们仍然是需要克服系统中的复杂性挑战,现在我们使用的工具虽然不同,但是面对的挑战仍然存在。

Glenford J. Myers 写过一本名为《复合 / 结构化设计(Composite/Structured Design)》的书,来讲述如何构建面向过程代码以降低系统复杂性。

除了尝试直接降低系统中各个部分的局部复杂性之外,我们还可以通过多种方式来解决复杂性难题。复杂性中最重要的是全局复杂性,即系统整体结构的复杂性,程序主要部分之间的关联或相互依赖程度。

通常,我们可以把局部复杂性理解为单一微服务的复杂性,由服务实现方式决定,而全局复杂性指的是系统整体复杂性,由服务间的交互和依赖关系决定。

一定程度上,这两种复杂性是“互斥”的。如果想要使全局复杂性最低,那么消除系统组件间的一切交互,在同一单体服务内实现所有功能即可,但是这会使得整个系统都特别拧巴,甚至可能会使得局部复杂性变得无法管理。而如果只优化局部复杂性,那么这些代码又会构成一个个新的复杂“单体”。所以,大规模分布式系统中,必须在全局和局部复杂性之间找到平衡。

放弃微服务,改用宏服务,Uber这波什么操作? 3

宏服务是解决服务复杂性的“特效药”吗?

到底什么是宏服务呢?相信国内开发者对这个概念会比较陌生,笔者在翻阅中文资料时,几乎没有见到关于宏服务的介绍文章,因此我们去咨询了多位领域内的技术专家,有专家表示之前没有听过“宏服务”这个概念,有两位专家表示:“宏服务应该是单体和微服务的折衷,关键区别是拆分粒度”。不过,也有专家吐槽:“宏服务这个概念没啥亮点,毕竟没人规定微服务应该拆多细。”

而在翻阅的英文资料中,有人是这么描述宏服务的:

宏服务应该定义为运行 2-20 个单独服务的应用程序体系结构,每个服务代表一个中等大小的代码库,可处理业务中定义明确的部分。宏服务的关键是拆分服务,最大程度地从拆分中获得收益,同时最大程度地降低运行多个服务的开销。

从概念描述中,宏服务似乎是在全局和局部复杂性之间找到了平衡,但理想丰满、现实骨感,实际应用中,宏服务的实现也并非易事,大多数企业也都在尝试阶段。以 Uber 为例,目前企业内的微服务数量超过 4000,且数量还在不断增加,而在实践宏服务的只有一个技术团队。

事实上,宏服务并非是比微服务更优的架构,只是架构演进中的不同选择。如果想要解决复杂性问题,无论是微服务,还是宏服务,都应该思考以下几个问题:

  • 特定服务当中,面向业务与面向集成的端点各占多大比例?

  • 在服务当中,是否存在与业务不相关的端点?能否在不引入面向集成端点的前提下,将其拆分为两项或者更多服务?

  • 合并某两项服务,是否能够消除之前用于集成二者而添加的端点?

相关链接:

https://vladikk.com/2020/04/09/untangling-microservices/

http://highscalability.com/blog/2020/4/8/one-team-at-uber-is-moving-from-microservices-to-macroservic.html

https://mattsencenbaugh.com/macroservices-pragmatic-approach/