解读微服务的 2020：框架在左网格在右，云原生时代的微服务路在何方？

本文是 InfoQ“解读 2020”年终技术盘点系列文章之一。

微服务的 2020，有坚守有破局。服务框架依然在持续进化和奔向云原生，Service Mesh 在持续进步的同时依旧疑点重重。总体而言，微服务架构的演进并非一蹴而就，过于保守或激进都不是解决之道。长期修行，苦练内功，或许才是微服务架构的前路方向。

2020 年，微服务这一持续多年的话题热度依旧：以 Spring Cloud、Dubbo 为代表的服务框架依然在持续进化，并加速奔向云原生；Service Mesh 这一云原生、微服务双圈“网红”依然在迷雾中砥砺前行。对大多数企业而言，面对云原生和微服务技术的蓬勃发展，不免有些疑惑：一边是成熟演进的服务框架，一边是代表未来方向的 Service Mesh，企业的架构演进方向究竟该如何选择？

服务框架：进化与困局

Spring Cloud：武器库迷局

Spring Cloud 之于微服务体系，就像 Spring 之于 Java 开源框架：地位举足轻重。

在微服务生态圈，Spring Cloud 像一个武器库，具备了大量解决分布式、微服务场景问题的“武器”。目前的 Spring Cloud 项目下，已经有超过 30 个子项目，有些子项目下还包括了功能丰富、数量可观的的子模块。一方面，得益于此的开发者可以方便的复用已有的开源能力，无需重复造轮子；另一方面，Spring Cloud 的初学者需要付出较多代价去学习框架本身的使用姿势与特性，这给 Spring Cloud 的前期应用、后期维护均造成一定困难。

Spring Cloud Netflix 正是融合 Spring Cloud 与 Netflix OSS 两大“武器库”的 Spring Cloud 优秀子项目，大多 Spring Cloud 开发者熟知的 Eureka、Hystrix、Ribbon、Zuul 等组件皆来源于此。不过随着这些组件的成熟，以及 Netflix 公司开源策略调整，2018 年开始 Hystrix、Ribbon 等核心组件相继进入维护状态，Spring Cloud 也给出了相应作为替代的长期演进的方案。或许是受 Netflix 组件“主动毕业”影响，Spring Cloud 将原先几个企业 OSS 的核心组件直接升级为 Spring Cloud 子项目，如微服务网关 Zuul 由实现机制相似的 Spring Cloud Gateway 替代，熔断降级组件 Hystrix 由支持多种方案的 Spring Cloud Circuit Breaker 替代，似乎是想让核心组件摆脱受制于企业开源组件策略影响。2020 年，换代的 Spring Cloud 武器库依旧向前发展，但新组件成熟度尚存不足，能力完整性、性能稳定性想达到当年 Netflix 核心组件的高度依旧需要经历时间检验。

Spring Cloud Alibaba 作为 Spring Cloud 与阿里系 OSS 生态融合的项目，在 2020 年也持续发展。Spring Cloud Alibaba 整合了 Sentinel、Nacos、Dubbo 等阿里微服务开源组件，旨在帮助开发者快速引入阿里系开源组件。不过，其与 Spring Cloud Netflix 类似的生长模式，究竟会重走 Netflix 老路，还是另辟蹊径独树一帜，项目后续发展需要继续关注。

Spring Cloud 武器库模式伴随着 Netflix、Alibaba 等企业 OSS 形态在 2020 年依旧显得有些“迷”，一方面 Spring Cloud 希望复用企业 OSS 让项目保持成熟度，另一方面又担心这种模式重蹈被企业“毕业”覆辙。真正的企业开发者在坐享 Spring Cloud 福报的同时，可能会有点懵。

Dubbo：加速奔向云原生

Dubbo 在经历一段时间停更后不仅重新营业，2019 年还成为 Apache 毕业项目。2020 年，Dubbo 开始加速奔向云原生。

在 Apache Dubbo 里程碑意义的 2.7.5 版本 中，做出两大重要调整：

• 服务模型调整：从一直以来的“接口即服务”的模型调整为与 Spring Cloud、Kubernetes 相同的服务模型。

• 协议支持调整：增加了 HTTP/2（gRPC）作为通信协议的能力。

Dubbo 传统的模型将 Interface 作为服务，方便了开发者的 RPC 接口维护。但在服务数量膨胀式增长的大规模企业微服务集群场景下，各种性能问题接踵而至。从 2.7.5 版本开始，服务模型不再在 Interface 维度细分，简化后的服务模型一方面有利于优化大规模场景的性能问题，更为关键的是与 Spring Cloud、Kubernetes 服务模型统一，可以帮助企业业务更好的实现服务体系兼容，进而无缝接入到云原生服务体系。

Dubbo 传统的 RPC 协议选择了私有二进制协议，相较于低版本 HTTP 协议性能方面有一定优势。在云原生背景下，负责流量代理的 Sidecar 下沉到基础设施层，Dubbo 原生协议设计使得请求的 7 层协议内容需要以 attachment 方式包装在请求 body 中，Sidecar 需要解析 body 才能拿到请求参数，之后再进行进一步的流量调度，这让 Dubbo 原生协议性能方面的优势几乎消失，成为 Dubbo 在云原生时代的又一“偏离项”。增加 HTTP/2（gRPC）协议支持不仅使协议更为通用，性能、扩展性等方面提升也能满足大规模云原生场景需求。

Dubbo 加速奔向云原生表明了成熟服务框架的正确演进方向，但步子过大带来的 老版本兼容问题、稳定性 同样值得企业业务关注。有趣的是，Dubbo 选择在 2.7.5 这样一个版本号做了重大调整，后面 3.0 版本的走向同样值得关注。

Service Mesh：进步、分化、落地

Istio 的进步与问题

2020 年，Istio 不仅信守承诺每个季度发布一个版本（1.5, 1.6, 1.7, 1.8），还带来了大量提升易用性、企业可落地性的能力：

• 性能 & 扩展性：Mixer V2  & WASM

• 控制面单体化：Pilot、Galley、Citadel 合并为 Istiod

• 多集群能力明确

• 非容器能力明确

• 安全模型简化

• 排障工具丰富化

• …… (一切为了企业落地、易用)

Istio 的开年版本 1.5 推翻了之前的设计，提出了“回归单体”的架构思路，1.6 版本的 Release note 更是在开篇就表明了要将极简主义进行到底。在 1.7 版本推出后，前 Red Hat 首席架构师、Istio in action 作者、solo.io Field CTO Christian Posta 认为 Istio 1.7 将成为生产可用的最稳定版本… 一切的一切，让 2020 年的 Istio 显得格外阳光、充满希望，也迎来了 1.1 版本后的第二次信心爆棚期。

不过，纵然光芒万丈也终需照进现实。Istio 1.5 版本开启的架构跃进使得至少在 1.5、1.6 两个版本难于生产落地，1.7 版本依然存在严格的平台版本要求（Kubernetes 的起步版本提升到 1.16 版本以上）、依赖 API 即将被迫迁移等问题，年末发布的 1.8 版本是否能真正成为企业生产可用的最稳定版本依旧有待生产检验。

2020 年的 Istio，依旧还是那在路上狂奔的少年。

阵营的二次分化

2020 年，Service Mesh 阵营依旧在分化：

• Istio 背后的两大靠山 Google 与 IBM 在商标问题上发生分歧，Istio 商标被 Google 捐献给 Open Usage Commons 组织，而非 CNCF；

• 微软发布了自己的开源 Service Mesh 项目 —— Open Service Mesh，遵循 Istio 以外阵营制定的 SMI（Service Mesh Interface）规范；

• 微服务 API 网关资深玩家 Kong 推出了自己的 Service Mesh 项目 —— Kuma，有趣的是 Kuma 选择了 Envoy 作为数据面，而非 Kong 网关核心内核 Nginx+OpenResty；

• Service Mesh 远古玩家 Nginx 也祭出自己新一代产品 —— NGINX Service Mesh（NSM），主打简化 Service Mesh，并顺势推出商业产品 Aspen Mesh

• …

阵营的分化在 Service Mesh 圈子似乎根本不算大事，也侧面证明了 Service Mesh 标准制订在一线云厂商眼中的战略地位。

不得不说：贵圈真乱。

企业落地关键要素

2020 年，企业的 Service Mesh 落地稳步推进。

早期入场 Service Mesh 的大厂在这一年几乎都经历了业务大规模生产验证，在协议拓展、注册中心对接、平台建设、性能稳定性等方面工作均得到生产级考验与沉淀。这也为后继者提供了更多的信心。

之前更多以观望者姿态场外候场的企业也逐步开启了自己的 Service Mesh 之旅：对落地场景相对简单、性能要求不高、历史负担轻的企业，选择 1.5 之前稳定版本，可以快速实现微服务架构升级到 Service Mesh；更多企业选择 Service Mesh 是希望可以实现架构的演进和历史痛点的根除，这些企业往往落地场景复杂、有一定落地规模和性能要求、希望做到业务无感知迁移… 可以说对 Service Mesh 寄予厚望。那么 2020 的 Service Mesh，真的能承此重任吗？答案是 并不容易。

对大部分企业来说，落地 Service Mesh 需要具备两大能力要素：平滑落地支撑，大规模落地保障。

1. 平滑落地支撑

全新的企业服务，或是已经高度平台化管理的服务，可以方便按照统一的方式落地 Service Mesh；多数企业面临的问题会复杂很多：框架不统一、协议不一致、注册中心多样、平台割裂、语言异构…  理想中的 Service Mesh 已成奢望，能否 支撑企业业务平滑落地 成为关键要素：

• 支撑已使用 Spring Cloud、Dubbo 框架、有自己的注册中心的业务服务无缝接入

• 存量虚拟机 / 物理机部署的业务服务，与容器化服务一起纳管治理

• 支撑存量使用私有协议、异构语言实现的业务服务接入 Service Mesh

• 具备全平台能力实现业务迁移的平滑、可观测

• …

2. 大规模落地保障

Service Mesh 架构下，由控制面进行数据面 Sidecar 管理、服务信息分发、配置分发。这样的结构简化了客户端逻辑，让服务框架更简单轻量，让 Sidecar 可以专注于治理流量职责，更多的管理 Service Mesh 体系职责由控制面承担。大规模业务场景下的服务规模支撑成为 Service Mesh 落地新挑战。

以 Istio 控制面为例，原生模式下控制面需要监听全局 Kubernetes 的服务信息变化，并将信息全量分发给所有 Sidecar。生产场景下，全局 Kubernetes 服务信息批量变动让控制面难负其重，即使 Istio 增加了 Sidecar Scope 这样用于隔离配置分发的机制，也只能优化控制面到 Sidecar 链路的配置分发，而且需要预先感知调用关系并进行针对配置，复杂的生产环境 配置处理的综合性能表现依旧不佳。

目前的原生 Istio 控制面也 缺乏自我保护机制，比如大规模场景下用于自我保护的限流 & 熔断、主动断连、连接负载均衡等能力。缺乏保护的控制面在极端情况下一旦发生宕机，再叠加一些业务重启、重连风暴，同样会给业务 SLA 带来较大挑战。

Service Mesh 架构下流量代理能力下沉，整体调用链路较传统 RPC 框架方式复杂。极端情况下一旦 Service Mesh 数据面 Sidecar 无法正常工作，会直接影响业务流量。这种场景一旦扩散到全局，会升级为系统级风险。原生组件提供了高可用保障，但 缺乏极端情况整体故障兜底能力。

总体而言，大规模场景下的 Service Mesh 仍需扎实的性能稳定性保障工作支撑。

微服务架构演进：长期修行，苦练内功

服务框架、Service Mesh 长期共存

服务框架与 Service Mesh 本身都是为解决业务微服务架构演进问题而生的，并不存在谁更好或者更先进的问题。相反，我认为在微服务领域的未来，服务框架和 Service Mesh 会处在长期共存、互补的状态。

Spring Cloud、Dubbo 以及 gRPC 都是成熟的服务框架，定位和发展方式虽有不同，但依然可以作为业务服务框架的长期选型，即使在 Service Mesh 架构下也同样需要易用的框架、通用的协议将服务流量引入 Sidecar，只不过更多 服务级 的流量治理能力从服务框架下沉到 Sidecar，而服务框架的 代码级 的治理能力依旧可以保留，形成 服务框架细粒度治理 +Service Mesh 流量治理能力的互补。这种共存状态下的微服务架构需要有足够兼容、稳定的方案进行支撑。

业务低感知更被重视

在企业微服务架构演进到 Service Mesh 的过程中，业务的低感知需要更加被重视。

前文提到企业微服务演进到 Service Mesh 所面临的诸多复杂场景挑战，实际落地迁移过程中能否做到业务的低感知甚至无感知，对业务演进迁移的信心保障显得格外重要。注册中心打通、请求流量互通、治理能力拉齐、灰度迁移、统一平台管控… 通过架构演进解决业务痛点是终点和目标，业务无感知迁移才是一切的起点。

平台趋同

针对微服务架构演进过程中遇到的诸多挑战，企业或是自身投入研发资源进行应对，或是寻找云厂商进行系统性保障。不管是哪种方式，我认为在微服务领域的未来，企业级微服务平台会向能力长期趋同的方向发展。

中国信通院主办的 2020 云原生产业大会上，发布了云原生领域系列各项评估结果。在首次针对微服务平台的评估过程中，包括阿里、网易、腾讯、华为等多家云厂商通过了信通院数百项微服务能力条目的严苛测试，获评最高等级（先进级）。这次评估覆盖了微服务平台完整能力闭环，数百项能力评估不仅明确了企业级微服务平台的标准，还从侧面体现了微服务平台的趋同性。

苦练内功，方得始终

云原生理念为微服务架构演进这一老生常谈的话题带来了新的契机。不管是服务框架的进化，还是 Service Mesh 的落地，对企业自身和各大云厂商都有不小的挑战。在企业级微服务平台能力趋同的趋势下，苦练微服务能力“内功”，积极应对业务低侵入接入、大规模生产支撑带来的挑战，才是微服务架构演进的正确方向。

作者介绍

裴斐，网易数帆云计算技术专家、资深架构师。10 年企业级平台架构和开发经验，目前主要负责网易轻舟微服务治理团队，专注于企业微服务架构及云原生技术的研究与落地工作。带领团队完成网易轻舟 Service Mesh、微服务框架 NSF、API 网关等多个项目在网易集团落地及商业化产品输出。

参考资料

Spring Cloud Netflix Projects Entering Maintenance Mode

从 2019 到 2020，Apache Dubbo 年度回顾与总结

专访 Christian Posta —— Istio 1.7 将成为生产可用的最稳定版本

Istio 1.7——进击的追风少年

中国信通院主办 2020 云原生产业大会，发布云原生领域系列评估结果