简介： 服务网格的 2021，“稳” 字当先。不管是原生社区发展，还是行业实践落地，都以 “稳定” 为第一要义。少了前几年大跃进式的架构演进、功能更迭，多了更务实、更落地的行业探索与实践，2021 年的服务网格正从当年那个狂奔的“少年”、“流量明星”，成长为真正的“实力派”，逐步进入成熟期，被更多行业、企业和标准化组织所接纳。本文将从社区进展、实践落地、行业标准、技术生态等角度回顾服务网格的 2021，帮助读者了解过去一年服务网格的整体进展，为企业选型、落地服务网格提供一些参考。
本文是“2021 InfoQ 年度技术盘点与展望”系列文章之一。
社区进展：稳定务实
2021 年，Istio 社区如约每三个月推出一个版本：1.9，1.10，1.11，1.12。稳定的版本发布周期显示出 Istio 社区发展进入常态化，也为企业选择合适的版本提供了便利。总的来说，2021 年 Istio 社区没有发布特别重大的架构调整或者创新能力，更多在接入性、运维性、API 等方面提供更好的原生支持：
- 1.9 —— 更好用的虚拟机集成（Beta）、请求分类（Beta）、Kubernetes Service API 支持（Alpha）、与外部授权系统的整合（Experimental）等。其中虚拟机集成延续了 1.8 版本引入智能 DNS （解决跨环境服务名解析问题）后虚拟机接入的体验持续优化，进一步增强服务网格纳管非容器环境的能力。
- 1.10 —— Kubernetes 资源发现选择器、稳定的修订版标签、Sidecar 网络变化等。其中 Kubernetes 资源发现选择器可以限制 Istiod 从 Kubernetes 接收和处理的配置集，配合 Sidecar CRD/API 资源，进一步优化了 Istiod 到 Envoy 的配置量。
- 1.11 —— CNI 插件（Beta）、外部控制平面（Beta）、网关注入、对修订和标签部署的更新、支持 Kubernetes 多集群服务（实验性）。其中 CNI 插件 为用户提供了 Kubernetes 环境下替代 istio-init 容器的方案（不需要更高 Kubernetes 权限）；外部控制平面 可以为用户提供部署在管控集群的网格控制面；对修订和标签部署的更新 可以让用户灰度进行 Istio 自身的部署、升级，降低 Istio 自身的运维风险。
- 1.12 —— WebAssembly API、遥测 API、Kubernetes Gateway API。其中增加了 WasmPlugin 作为 WebAssembly API，改善 Istio 使用 WebAssembly 进行插件扩展的体验。
纵观 2021 年 Istio 社区发布的四个版本，不难看出：
- 没有发布特别重大的架构调整、创新能力：企业在 Istio 版本选择上没有特别的门槛。
- 接入易用性提升：增加虚拟机、CNI 插件、WebAssembly 等方面支持的内容，为更多复杂的业务部署环境、更苛刻的容器环境、更多语言的扩展需求提供原生能力支持。
- 运维性提升：稳定的修订版标签、外部控制平面等，为 Istio 自身运维、多集群管控提供更好的原生支持。
- API 标准化：包括 WebAssembly API、Kubernetes Gateway API、Kubernetes Service API 支持等，不管是 Istio 自身 API 的标准化，还是对 Kubernetes 标准 API 的支持，Istio 社区在 API 标准化方面持续努力中。
实践落地：行业延展
服务网格技术最早起源于大型互联网公司（Google、IBM、Twitter/Buoyant），服务网格技术早期的应用落地也多为互联网公司：互联网大厂凭借其技术方面的深厚功力与持续投入，在最近几年已经完成了服务网格从初期探索到大规模生产应用的跨越；中小型互联网公司也紧跟大厂步伐，顺应云原生技术浪潮，完成了服务网格“初体验”。2021 年，更多行业的企业开始尝试落地服务网格。
企业诉求
以大规模、高稳定、强安全著称的金融行业为例， 2021 年国内多家大型国有银行、头部股份制银行、头部券商的基础架构团队都开始引进服务网格技术，进行技术研究、平台搭建、业务试用。这里结合我们在 2021 年服务过的多家金融行业头部企业，及其他公开的技术资料，总结了金融行业企业对服务网格技术的典型诉求。
1. 落地零门槛
在 微服务 2020 年度复盘 一文中，我们提出 “平滑落地支撑” 是企业落地服务网格的两大关键要素之一。在金融行业，这一点尤为明显。服务网格 落地零门槛，是企业的核心诉求之一。
我们归纳了服务网格支撑企业落地需要具备的 “三要素” ：通信协议，注册中心，部署环境。
- 通信协议：服务网格能支持的服务通信协议，常见的如 HTTP、gRPC、Dubbo 等，另外也有具备行业属性的私有 RPC 协议；
- 注册中心：服务网格能纳管的注册中心，包括常见的 Eureka、Consul、Nacos、Zookeeper 以及 Kubernetes （ETCD）；
- 部署环境：服务网格能支持的业务部署环境，除了天然云原生的 Kubernetes + Docker 外，对于遗留系统所在的虚拟机、物理机，也需要同等对待。
在满足 “三要素” 后，服务网格才能达到业务落地的 “及格线”。
此外我们发现，金融行业还存在着更多“拦路虎”：
- 严格的环境管控：部署平台（容器、虚拟机、物理机）与基础平台（微服务、中间件）分属不同团队，又由于企业职责划分、金融合规要求等因素，服务网格的落地受到了诸如 网络环境、管理权限、金融规范 等更多限制；
- 复杂的存量系统：头部金融行业企业大多已具备了比较完整的分布式体系，但也存在不少复杂、异构的外采、遗留系统，由于多开发语言、多通信协议、无法修改代码、没有注册发现机制等因素，不少系统无法纳管在已有体系中，成为企业分布式体系的 “孤岛”。
2. 架构场景匹配
与传统微服务框架侧重覆盖服务治理能力的业务场景不同，服务网格重点解决企业的架构场景问题。除了要实现云原生体系下微服务纳管与治理能力外，还需要覆盖 异构应用统一治理、遗留系统迁移 等架构场景需求，真正意义上解决企业微服务化后存在的整体性问题。
我们归纳了金融行业企业在架构场景方面的典型诉求如下：
- 多集群、多机房业务的纳管：包括提供正常的服务发现、调用、治理、跨区域容灾等；
- 现有单体、微服务架构，向云原生服务网格架构长期、平滑、稳定迁移演进：以业务无感知方式，从现有架构逐步灰度方式演进到服务网格架构，迁移过程服务互通、可治理、可观测，并保证高 SLA。
核心价值
在初步完成服务网格认知后，企业用户往往会发出灵魂拷问：为什么要上服务网格？服务网格有什么价值？
一般来说，通识的服务网格核心价值 “标准答案” 是：
- 业务无需感知微服务组件：微服务架构支撑、网络通信、治理等相关能力下沉到基础设施层，业务部门无需投入专人开发与维护，可以有效降低微服务架构下研发与维护成本；
- 支持多开发语言、框架：服务网格天然不限制开发语言、开发框架，提供多语言服务治理能力；
- 框架升级零成本：支持框架热升级，降低中间件和技术框架客户端、SDK 升级成本；
- 微服务体系统一纳管、演进：将存量微服务集群、遗留系统、外购系统微服务体系统一管理、演进。
对于企业内部不同团队，服务网格价值侧重会有所不同：
- 基础架构 / 平台研发团队：更看重服务网格覆盖的架构场景
- 多开发语言、框架无关，可以纳管各种业务应用接入；
- 框架升级零成本，无需业务重启或感知；
- 微服务体系统一纳管、演进，可以将已有微服务集群、遗留系统、外购系统等 “一把抓”，统一管理与演进；
- 业务研发团队：更看重服务网格覆盖的业务场景
- 一键接入微服务治理全套治理、监控能力，如熔断、限流、降级、容错、故障注入、指标监控、链路追踪等；
- 遗留、外购系统可以纳入统一治理，具备同等治理、监控能力，与其他业务微服务互联互通；
- 无需感知微服务组件，业务研发者不再需要学习、研究和维护微服务相关技术与框架。
面临挑战
即使 Istio 版本趋于稳定，众多互联网公司也已经顺利完成服务网格落地，更多行业企业落地服务网格依旧面临挑战。
1. 技术面：零门槛接入不易
从技术角度分析，实现 “零门槛” 面临三大挑战：
- 通信协议扩展 —— 作为企业落地服务网格的“三要素”之首，实现通信协议的代理、解析、治理、可观测等全套能力是一个浩大的工程，特别是对于那些设计上远离 HTTP、gRPC 等通用协议的私有 RPC 协议（在金融行业特别常见），需要有巧妙且完整的扩展机制加以实现。
- 自定义插件扩展 —— 大部分研发者无法直接编写 Envoy C++ 的扩展代码，Envoy 原生提供的 Lua 语言扩展能力薄弱，被社区寄以厚望的 WASM（WebAssembly）性能方面距离生产落地尚存不小差距，需要有真正好用且生产可用的 Envoy 自定义插件扩展机制。
- 虚拟机 / 物理机环境纳管 —— 即使 Istio 社区一直在改善服务网格的虚拟机 / 物理机环境纳管体验，各类公有云厂商也提供了相应“残血版”能力 ，但部署在非容器的业务始终像是“二等公民”一样 —— 很难得到与容器化环境部署业务对等且同等的服务网格能力，需要有更完整、更兼容的非容器环境 Sidecar 管理、流量拦截等落地方案。
2. 场景面：复杂场景覆盖不易
金融行业企业业务往往在各类环境、规范约束下部署运维，再加上业务系统本身的庞杂，存量、遗留、外采系统的组合存在，服务网格落地金融行业天然存在场景覆盖挑战：
- 业务的多集群、多机房部署，跨集群、跨机房调用的互联互通、统一治理、异常灾备，各类高可用保障等等，都需要服务网格系统具备适应能力；
- 业务架构的平滑演进，从现有的单体、微服务架构，逐步迁移到云原生服务网格架构，包含微服务框架、服务网格等 “跨代” 技术栈的长期共存、服务发现、互访、治理、观测，需要真正意义上实现业务架构迁移场景的能力适应与高 SLA 保障。
行业标准：扬帆起航
服务网格技术在社区进展、实践落地等方面逐步稳定后，相应的行业标准与标准平台也水到渠成，开始扬帆起航。
信通院标准
2021 年 7 月，由中国信息通信研究院主办的 2021 年可信云大会上，《服务网格技术能力要求》标准正式发布，阿里、网易、字节、Flomesh 四家企业通过了首批测评，获得了服务网格最高级别评估。有趣的是，首批通过的四家企业可以说是云计算大厂、老牌互联网公司、新晋互联网公司、技术型创业公司的典型代表，这也侧面反映出各类企业对推进服务网格技术标准和落地的重视。
标准平台
在 2021 年，云计算厂商提供服务网格标准平台逐步完善与成熟，企业可以按需选择标准平台，或与厂商共建方式落地服务网格。
不同厂商提供标准平台类型上略有差异：
- 原生 Istio 资源 + 公有云基础设施 + 生态集成：侧重对原生 Istio 的兼容及与公有云现有生态集成；
- 原生 Istio 平台化 + 私有化部署 + 三方集成：基于 Istio 扩展与增强，屏蔽原生 Istio 复杂性，侧重对微服务体系的统一管控、治理，以及对企业私有化环境的适应与兼容、集成；
- 自研服务网格部分体系或全体系：不受限与 Istio 等开源社区，对开源服务网格的弱项针对性加强。
不同平台都有各自的适用场景和强弱项，企业可以结合自身情况自行选择。
技术生态：百家争鸣
服务网格在 2021 年进入稳定期，服务网格技术生态也在这一年百花齐放百家争鸣。
开源项目
在 2021 年，一大批 Istio 相关的优秀项目开源，围绕易用性、扩展性、运维性等方面增强 Istio：
- Slime：基于 Istio 的智能服务网格管理器，为 Istio 增加了一个无侵入管理平面。2021 年 1 月由网易开源。
- GetMesh：Istio 集成和命令行管理工具，可用于 Istio 多版本管理。2021 年 2 月由 Tetrate 开源。
- Aeraki：管理 Istio 的任何七层负载，提供对服务网格多协议扩展支持。2021 年 3 月由腾讯开源。
- Layotto：云原生应用运行时，可作为 Istio 的数据平面。2021 年 6 月由蚂蚁开源。
- Hango Gateway：基于 Envoy 和 Istio 构建的 API 网关，天然兼容 Istio，提供原生高性能和富代理能力。2021 年 8 月由网易开源。
众多服务网格生态开源项目的出现，侧面印证了服务网格领域的勃勃生机。
多运行时
与服务网格将微服务治理能力下沉到基础设施层（Sidecar）的思想类似，多运行时（Multi-Runtime）在 2020 年由 Bilgin Ibryam 提出，其对 Sidecar 模式的各种形态进行了总结和升华。多运行时自身特点可以归纳如下：
- 能力：提供相较服务网格更宽广的分布式能力，如中间件代理、消息 pub/sub 等；
- 部署：可以跟业务 1：1（per-pod） 或 1：N（per-node）对应，按需部署在多种环境下，且进行组件组合；
- 交互：与应用通过标准 API 进行通信，不强调业务无侵入，应用内会有承载标准 API 的 SDK。
比较典型的多运行时开源框架是由微软开源的 Dapr（ Distributed Application Runtime），其在 2021 年迎来了标志性的 1.0 版本，并且进入 CNCF Sandbox 进行孵化，目前仍在高速发展中。
从落地实践角度，多运行时在 2021 年展现了不错的潜力和发展态势：
- 理念先进，可能是分布式架构的未来趋势；
- 大厂主导，社区发展迅速，已有多家大厂入局探索；
- 整体成熟度还不高，在点对点服务通信治理、能力完整度、API 稳定性等方面尚存不足；
- 可以与服务网格等已有技术进行生态整合，补齐短板。
eBPF
eBPF 技术的出现使得在 Linux 内核编程并运行沙盒程序成为可能，而且无需更改内核源代码或加载内核模块。这就使得开发者可以从内核出发增强系统的可观察性、优化网络及其安全性。在服务网格领域，eBPF 可以用于 Sidecar 网络加速，并且可以从底层观测内核消息队列、任务队列、网络包信息、网络连接等更深层次的信息。
在 2021 年，Cilium（eBPF 开源框架） 提出了用 eBPF 替代 Sidecar 实现内核级服务网格（数据面代理）的构想，以解决独立 Sidecar 带来的部署资源消耗、延时性能损耗等问题，实现真正意义上流量治理、观测能力下沉到基础设施层。不过，Cilium 的这一大胆构想很快就收到了来自 “传统” 服务网格阵营的 “反击”，理由包括 eBPF 实现服务代理能力的诸多限制、操作复杂、协议处理复杂度高、内核版本有依赖等等。
不论如何，eBPF 技术融入服务网格生态已经是一个新趋势，即使无法真正实现 Sidecar 的完美替代，eBPF 同样可以作为 Sidecar 的有力补充，使两者在流量链路上水乳交融。
Proxyless
服务网格在诞生之初就以独立 Sidecar Proxy 负责流量的代理、治理、观测，服务网格实现框架也都默认以独立 Proxy 方式来组织数据平面能力，并与应用进程内的 传统微服务框架划清界限，各谈利弊，似乎 Proxy 模式就是服务网格数据平面的标准模式。在 2021 年，应用进程内框架与独立 Sidecar Proxy 间的 “次元壁” 被打破，Proxyless 理念被越来越多提及。
WHY Proxyless（本质上是针对服务网格独立 Sidecar Proxy 模式的 “弊” 而来）：
- 性能问题：独立 Proxy 带来的额外部署资源开销和延时性能开销；
- 流量拦截：独立 Proxy 的流量拦截大多需要配合 IPTables 等技术，需要管理权限，逻辑复杂，排障不易；
- 治理粒度：独立 Proxy 在应用进程外工作，且无状态，无法对应用进程内的程序、方法进行治理与观测。
WHAT Proxyless（能提供对各类分布式场景的能力补充）：
- 服务网格优化：在应用内提供细粒度治理、监控以及流量拦截能力；
- 多运行时操作：在应用内提供标准 SDK，为业务提供对基础设施资源操作接口；
- 能力继续下沉：在操作系统内核实现流量的处理、治理、观测。
HOW Proxyless（几种常见实现方式）：
- 框架 / SDK：经典用法，回到过去；
- 无侵入 Agent：无侵入方式实现业务代码增强，原理可以参考我们之前 从服务框架到服务网格，网易轻舟双引擎多模式服务治理演进实践 一文中 “服务框架：无侵入 Agent 服务治理” 部分介绍；
- 原生 RPC 支持：新版本 gRPC 直接提供治理功能，并支持了直接对接控制平面的标准 xDS 协议；
- eBPF：在 Linux 内核对流量进行处理、治理、观测。
从架构演进层面考量，Proxyless 有 “逆流” 发展的嫌疑。不过，从务实落地角度来看，Proxyless 为 Proxy 带来的能力补充，或许可以更好地帮助企业完成从传统架构到云原生架构的逐步迁移落地。
未来展望
针对服务网格 2021 的复盘到这里告一段落，对于服务网格的未来，我们充满信心。在本文的最后，给出我们对服务网格的未来展望：
零门槛
随着服务网格技术的逐步精进成熟，以及越来越多行业的落地经验积累，技术面和场景面所面临的挑战终将被克服，服务网格落地门槛逐步会趋于零。
标准化
服务网格的技术能力和场景覆盖得以高度抽象化和通用化，服务网格平台 / 产品也会随之高度标准化，企业选择服务网格平台 / 产品会更加容易。
全面统一
以 Envoy、Istio 为代表的服务网格技术会助力实现相关软件领域的统一，如更多的 L7 流量代理会以 Envoy 为核心构建，数据平面与控制平面之间会以 xDS 协议交互等。企业架构师想实现的分布式体系全局统一治理将不再是奢望。
生态融合：Proxyless + Proxy + eBPF + 多运行时
服务网格不同生态间不会是对立关系，最终会 “务实” 地形成 “合力”，彼此共赢：在流量链路上的 Proxyless -> Proxy -> eBPF 协作，能力互补；多运行时下存在的能力短板可以融合服务网格的成熟能力，加速自身发展。
参考资料（特别感谢服务网格领域的诸多实践者与分享者）：
从服务框架到服务网格，网易轻舟双引擎多模式服务治理演进实践
解读微服务的 2020：框架在左网格在右，云原生时代的微服务路在何方
Istio 1.9 发布——重点改善 Istio 的 Day2 操作
基于 gRPC 和 Istio 的无 Sidecar 代理的服务网格
都 2021 年了，对于服务网格，社区到底在讨论什么
Dapr v1.0 展望：从 servicemesh 到云原生
告别 Sidecar—— 使用 EBPF 解锁内核级服务网格
译文：服务网格将使用 eBPF ？是的，但 Envoy 代理将继续存在
作者介绍：
裴斐，网易数帆高级技术专家、资深架构师。10 余年企业级平台架构和开发经验，目前主要负责网易数帆轻舟微服务团队，专注于企业微服务架构及云原生技术的研究与落地工作。带领团队完成轻舟服务网格、微服务框架、API 网关等多个项目在网易集团落地及商业化产品输出，并主导建设了 Slime、Hango 等多个云原生开源项目。
