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



「InfoQ」放弃微服务,改用宏服务,Uber 这波什么操作?
本文插图
作者丨田晓旭
Uber 支付体验平台放弃了微服务 , 转而使用了宏服务 , 这一消息在网友中引起了热议 。 一向是微服务积极分子的 Uber 为什么突然改用宏服务了?以“简单”著称的微服务为什么又变得难以维护了呢?
1 Uber 支付团队放弃微服务 , 转用宏服务
4 月 6 日 , Uber 支付体验平台的工程经理 Gergely Orosz 发布推文表示其团队的架构方向已经发生了变化 , 放弃微服务 , 转而使用宏服务 。

「InfoQ」放弃微服务,改用宏服务,Uber 这波什么操作?
本文插图
为什么会做出这样的选择呢?Gergely Orosz 表示:“最早 , Uber 通过构建微服务来完成很小的需求或功能 , 以至于出现了很多由一个人构建维护的微服务 。 这些微服务的存在给我们带来了新的复杂性和挑战 , 例如监控、测试、持续集成 / 持续交付(CI/CD)、服务级别协议(SLA)、跨所有微服务的库版本(安全和时区问题)等等 。 ”
因此 , 在创建新平台的时候 , Uber 支付体验团队对新服务进行了更加深思熟虑的规划:不再只是完成一件事 , 而是使其服务于一项业务功能 , 由 5-10 个工程师负责维护 。 Gergely Orosz 把这样的服务规划称之为宏服务 。
为什么一向以简单著称的微服务 , 在 Uber 的实践中突然就变得难以维护了呢?我们先来看一下微服务到底“微”的是什么呢?
2 微服务到底“微”的是什么?
微服务是什么?百度百科给出的解释是:“微服务是一个新兴的软件架构 , 就是把一个大型的单个应用程序和服务拆分为数十个的支持微服务 。 ”其中 , 最关键的部分是开发者要能够对服务中的某些部分进行衡量 , 并将其对应价值控制在最低水平 。
那么 , 微服务到底“微”的是什么?
微团队微服务首先“微”的就是服务开发团队的规模 , 而且它有一个很特别的衡量单位——“披萨” 。 亚马逊 CEO Jeff Bezos 提出了著名的两个披萨原则 , 即每一个内部团队的规模必须足够小 , 小到两个披萨饼就可以喂饱整个团队 。
两个披萨团队真的有效吗?有人认可 , 但也有人质疑 , 有网友曾吐槽:“这种说法一看就很假 , 我手下有不少只需要一个披萨的团队 , 但他们做出来的东西仍然是一团乱麻 。 ”
微代码库
微服务 , “微”的也可能是代码库 , 有人甚至会将“微代码库”这个概念发挥到极致 , 限制某项服务中所包含的代码行数 。
代码库小当然有好处 , 代码库越小 , 对应的业务范围就越小 , 越易于理解、实施和开发 , 同时引发大失误的概率低 , 而且出现失误时 , 重构的难度也更低 。
但是大家真的认可代码库这种硬性指标吗?如果认可的话 , 那么我们把范围缩小到每行代码包含多少个字符 , 岂不是更好?
我们可以通过很多种方式来定义服务边界 , 代码库大小绝对是其中最低效的一种 。 —— Nick Tune
“微系统”
事实上 , 微团队和微代码库都是“微服务”的理想化产物 , 大家似乎忘记了系统才是最关键的部分 , 系统是服务的容身之所 。
【「InfoQ」放弃微服务,改用宏服务,Uber 这波什么操作?】我们真正需要构建的是系统 , 而不是一组服务 。 我们使用微服务的目的在于优化系统设计 , 而不是单纯设计一个个独立服务 。 事实上 , 我们很难使用真正独立的组件建立起庞大的系统 , 因为这在本质上违背了“系统”的核心定义:
一组相互联系的事物或设备 , 它们能够共同运作;
一组共同用于特定目标的计算机设备及程序;
彼此交互的服务才能建立起系统 , 如果只优化系统中的服务 , 而忽略服务间的交互 , 就会出现下图的情况: 分页标题

「InfoQ」放弃微服务,改用宏服务,Uber 这波什么操作?
本文插图
“微服务”本身可能非常简单 , 但是交互建立起的系统将成为新的复杂性瓶颈 。
3 从系统的角度来看服务的复杂性
系统复杂性并不是现在才有的问题 , 四十年前 , 没有云计算 , 没有全球规模需求 , 也不需要 11.7 秒部署一次系统 , 但是工程师们仍然是需要克服系统中的复杂性挑战 , 现在我们使用的工具虽然不同 , 但是面对的挑战仍然存在 。
Glenford J. Myers 写过一本名为《复合 / 结构化设计(Composite/Structured Design)》的书 , 来讲述如何构建面向过程代码以降低系统复杂性 。
除了尝试直接降低系统中各个部分的局部复杂性之外 , 我们还可以通过多种方式来解决复杂性难题 。 复杂性中最重要的是全局复杂性 , 即系统整体结构的复杂性 , 程序主要部分之间的关联或相互依赖程度 。
通常 , 我们可以把局部复杂性理解为单一微服务的复杂性 , 由服务实现方式决定 , 而全局复杂性指的是系统整体复杂性 , 由服务间的交互和依赖关系决定 。
一定程度上 , 这两种复杂性是“互斥”的 。 如果想要使全局复杂性最低 , 那么消除系统组件间的一切交互 , 在同一单体服务内实现所有功能即可 , 但是这会使得整个系统都特别拧巴 , 甚至可能会使得局部复杂性变得无法管理 。 而如果只优化局部复杂性 , 那么这些代码又会构成一个个新的复杂“单体” 。 所以 , 大规模分布式系统中 , 必须在全局和局部复杂性之间找到平衡 。

「InfoQ」放弃微服务,改用宏服务,Uber 这波什么操作?
本文插图
4 宏服务是解决服务复杂性的“特效药”吗?
到底什么是宏服务呢?相信国内开发者对这个概念会比较陌生 , 笔者在翻阅中文资料时 , 几乎没有见到关于宏服务的介绍文章 , 因此我们去咨询了多位领域内的技术专家 , 有专家表示之前没有听过“宏服务”这个概念 , 有两位专家表示:“宏服务应该是单体和微服务的折衷 , 关键区别是拆分粒度” 。 不过 , 也有专家吐槽:“宏服务这个概念没啥亮点 , 毕竟没人规定微服务应该拆多细 。 ”
而在翻阅的英文资料中 , 有人是这么描述宏服务的:
宏服务应该定义为运行 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/
InfoQ 读者交流群上线啦!各位小伙伴可以扫描下方二维码 , 添加 InfoQ 小助手 , 回复关键字“ 进群 ”申请入群 。 大家可以和 InfoQ 读者一起畅所欲言 , 和编辑们零距离接触 , 超值的技术礼包等你领取, 还有超值活动等你参加 , 快来加入我们吧!分页标题
点个在看少个 bug