作者丨田晓旭
Uber 支付体验平台放弃了微服务，转而使用了宏服务，这一消息在网友中引起了热议。一向是微服务积极分子的 Uber 为什么突然改用宏服务了？以“简单”著称的微服务为什么又变得难以维护了呢？
1 Uber 支付团队放弃微服务，转用宏服务
4 月 6 日，Uber 支付体验平台的工程经理 Gergely Orosz 发布推文表示其团队的架构方向已经发生了变化，放弃微服务，转而使用宏服务。
为什么会做出这样的选择呢？Gergely Orosz 表示：“最早，Uber 通过构建微服务来完成很小的需求或功能，以至于出现了很多由一个人构建维护的微服务。这些微服务的存在给我们带来了新的复杂性和挑战，例如监控、测试、持续集成 / 持续交付（CI/CD）、服务级别协议（SLA）、跨所有微服务的库版本（安全和时区问题）等等。”
因此，在创建新平台的时候，Uber 支付体验团队对新服务进行了更加深思熟虑的规划：不再只是完成一件事，而是使其服务于一项业务功能，由 5-10 个工程师负责维护。Gergely Orosz 把这样的服务规划称之为宏服务。
为什么一向以简单著称的微服务，在 Uber 的实践中突然就变得难以维护了呢？我们先来看一下微服务到底“微”的是什么呢？
2 微服务到底“微”的是什么？
微服务是什么？百度百科给出的解释是：“微服务是一个新兴的软件架构，就是把一个大型的单个应用程序和服务拆分为数十个的支持微服务。”其中，最关键的部分是开发者要能够对服务中的某些部分进行衡量，并将其对应价值控制在最低水平。
那么，微服务到底“微”的是什么？
微团队微服务首先“微”的就是服务开发团队的规模，而且它有一个很特别的衡量单位——“披萨”。亚马逊 CEO Jeff Bezos 提出了著名的两个披萨原则，即每一个内部团队的规模必须足够小，小到两个披萨饼就可以喂饱整个团队。
两个披萨团队真的有效吗？有人认可，但也有人质疑，有网友曾吐槽：“这种说法一看就很假，我手下有不少只需要一个披萨的团队，但他们做出来的东西仍然是一团乱麻。”
微代码库
微服务，“微”的也可能是代码库，有人甚至会将“微代码库”这个概念发挥到极致，限制某项服务中所包含的代码行数。
代码库小当然有好处，代码库越小，对应的业务范围就越小，越易于理解、实施和开发，同时引发大失误的概率低，而且出现失误时，重构的难度也更低。
但是大家真的认可代码库这种硬性指标吗？如果认可的话，那么我们把范围缩小到每行代码包含多少个字符，岂不是更好？
我们可以通过很多种方式来定义服务边界，代码库大小绝对是其中最低效的一种。—— Nick Tune
“微系统”
事实上，微团队和微代码库都是“微服务”的理想化产物，大家似乎忘记了系统才是最关键的部分，系统是服务的容身之所。
我们真正需要构建的是系统，而不是一组服务。我们使用微服务的目的在于优化系统设计，而不是单纯设计一个个独立服务。事实上，我们很难使用真正独立的组件建立起庞大的系统，因为这在本质上违背了“系统”的核心定义：
一组相互联系的事物或设备，它们能够共同运作；
一组共同用于特定目标的计算机设备及程序；
彼此交互的服务才能建立起系统，如果只优化系统中的服务，而忽略服务间的交互，就会出现下图的情况：
“微服务”本身可能非常简单，但是交互建立起的系统将成为新的复杂性瓶颈。
3 从系统的角度来看服务的复杂性
系统复杂性并不是现在才有的问题，四十年前，没有云计算，没有全球规模需求，也不需要 11.7 秒部署一次系统，但是工程师们仍然是需要克服系统中的复杂性挑战，现在我们使用的工具虽然不同，但是面对的挑战仍然存在。
Glenford J. Myers 写过一本名为《复合 / 结构化设计（Composite/Structured Design）》的书，来讲述如何构建面向过程代码以降低系统复杂性。
除了尝试直接降低系统中各个部分的局部复杂性之外，我们还可以通过多种方式来解决复杂性难题。复杂性中最重要的是全局复杂性，即系统整体结构的复杂性，程序主要部分之间的关联或相互依赖程度。
通常，我们可以把局部复杂性理解为单一微服务的复杂性，由服务实现方式决定，而全局复杂性指的是系统整体复杂性，由服务间的交互和依赖关系决定。
一定程度上，这两种复杂性是“互斥”的。如果想要使全局复杂性最低，那么消除系统组件间的一切交互，在同一单体服务内实现所有功能即可，但是这会使得整个系统都特别拧巴，甚至可能会使得局部复杂性变得无法管理。而如果只优化局部复杂性，那么这些代码又会构成一个个新的复杂“单体”。所以，大规模分布式系统中，必须在全局和局部复杂性之间找到平衡。
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
