江苏龙网

  1. 首页 > 资讯 > 科技 > >

「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 读者一起畅所欲言 ， 和编辑们零距离接触 ， 超值的技术礼包等你领取， 还有超值活动等你参加 ， 快来加入我们吧！


推荐阅读


上一篇：腾讯科技■消费券“暖”市场，中山市发2000万微信消费券

下一篇：门店■苹果公司启动门店恢复计划