解读服务网格的2021：告别架构“”技术生态百家争鸣

　　服务网格的 2021，“稳” 字当先。不管是原生社区发展，还是行业实践落地，都以 “稳定” 为第一要义。少了前几年式的架构演进、功能更迭，多了更务实、更落地的行业探索与实践，2021 年的服务网格正从当年那个狂奔的“少年”、“流量明星”，成长为真正的“实力派”，逐步进入成熟期，被更多行业、企业和标准化组织所接纳。本文将从社区进展、实践落地、行业标准、技术生态等角度回顾服务网格的 2021，帮助读者了解过去一年服务网格的整体进展，为企业选型、落地服务网格提供一些参考。

　　2021 年，Istio 社区如约每三个月推出一个版本：1.9，1.10，1.11，1.12。稳定的版本发布周期显示出 Istio 社区发展进入常态化，也为企业选择合适的版本提供了便利。总的来说，2021 年 Istio 社区没有发布特别重大的架构调整或者创新能力，更多在接入性、运维性、API 等方面提供更好的原生支持：

　　接入易用性提升： 增加虚拟机、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 年服务过的多家金融行业头部企业，及其他公开的技术资料，总结了金融行业企业对服务网格技术的典型诉求。

　　在 微服务 2020 年度复盘 一文中，我们提出 “平滑落地支撑” 是企业落地服务网格的两大关键要素之一。在金融行业，这一点尤为明显。服务网格落地零门槛，是企业的核心诉求之一。

　　通信协议： 服务网格能支持的服务通信协议，常见的如 HTTP、gRPC、Dubbo 等，另外也有具备行业属性的私有 RPC 协议；

　　注册中心： 服务网格能纳管的注册中心，包括常见的 Eureka、Consul、Nacos、Zookeeper 以及 Kubernetes （ETCD）；

　　部署环境： 服务网格能支持的业务部署环境，除了天然云原生的 Kubernetes + Docker 外，对于遗留系统所在的虚拟机、物理机，也需要同等对待。

　　严格的环境管控： 部署平台（容器、虚拟机、物理机）与基础平台（微服务、中间件）分属不同团队，又由于企业职责划分、金融合规要求等因素，服务网格的落地受到了诸如 网络环境、管理权限、金融规范 等更多限制；

　　复杂的存量系统： 头部金融行业企业大多已具备了比较完整的分布式体系，但也存在不少复杂、异构的外采、遗留系统，由于多开发语言、多通信协议、无法修改代码、没有注册发现机制等因素，不少系统无法纳管在已有体系中，成为企业分布式体系的 “孤岛”。

　　与传统微服务框架侧重覆盖服务治理能力的业务场景不同，服务网格重点解决企业的架构场景问题。除了要实现云原生体系下微服务纳管与治理能力外，还需要覆盖异构应用统一治理、遗留系统迁移等架构场景需求，真正意义上解决企业微服务化后存在的整体性问题。

　　在初步完成服务网格认知后，企业用户往往会发出灵魂拷问：为什么要上服务网格？服务网格有什么价值？

　　即使 Istio 版本趋于稳定，众多互联网公司也已经顺利完成服务网格落地，更多行业企业落地服务网格依旧面临挑战。

　　通信协议扩展 —— 作为企业落地服务网格的“三要素”之首，实现通信协议的代理、解析、治理、可观测等全套能力是一个浩大的工程，特别是对于那些设计上远离 HTTP、gRPC 等通用协议的私有 RPC 协议（在金融行业特别常见），需要有巧妙且完整的扩展机制加以实现。

　　自定义插件扩展 —— 大部分研发者无法直接编写 Envoy C++ 的扩展代码，Envoy 原生提供的 Lua 语言扩展能力薄弱，被社区寄以厚望的 WASM（WebAssembly）性能方面距离生产落地尚存不小差距，需要有真正好用且生产可用的 Envoy 自定义插件扩展机制。

　　虚拟机 / 物理机环境纳管 —— 即使 Istio 社区一直在改善服务网格的虚拟机 / 物理机环境纳管体验，各类公有云厂商也提供了相应“残血版”能力 ，但部署在非容器的业务始终像是“二等公民”一样 —— 很难得到与容器化环境部署业务对等且同等的服务网格能力，需要有更完整、更兼容的非容器环境 Sidecar 管理、流量拦截等落地方案。

　　金融行业企业业务往往在各类环境、规范约束下部署运维，再加上业务系统本身的庞杂，存量、遗留、外采系统的组合存在，服务网格落地金融行业天然存在场景覆盖挑战：

　　业务的多集群、多机房部署， 跨集群、跨机房调用的互联互通、统一治理、异常灾备，各类高可用保障等等，都需要服务网格系统具备适应能力；

　　业务架构的平滑演进， 从现有的单体、微服务架构，逐步迁移到云原生服务网格架构，包含微服务框架、服务网格等 “跨代” 技术栈的长期共存、服务发现、互访、治理、观测，需要真正意义上实现业务架构迁移场景的能力适应与高 SLA 保障。

　　服务网格技术在社区进展、实践落地等方面逐步稳定后，相应的行业标准与标准平台也水到渠成，开始扬帆起航。

　　2021 年 7 月，由中国信息通信研究院主办的 2021 年可信云大会上，《服务网格技术能力要求》标准正式发布，阿里、网易、字节、Flomesh 四家企业通过了首批测评，获得了服务网格最高级别评估。有趣的是，首批通过的四家企业可以说是云计算大厂、老牌互联网公司、新晋互联网公司、技术型创业公司的典型代表，这也侧面反映出各类企业对推进服务网格技术标准和落地的重视。

　　在 2021 年，云计算厂商提供服务网格标准平台逐步完善与成熟，企业可以按需选择标准平台，或与厂商共建方式落地服务网格。

　　原生 Istio 资源 + 公有云基础设施 + 生态集成： 侧重对原生 Istio 的兼容及与公有云现有生态集成；

　　原生 Istio 平台化 + 私有化部署 + 三方集成： 基于 Istio 扩展与增强，屏蔽原生 Istio 复杂性，侧重对微服务体系的统一管控、治理，以及对企业私有化环境的适应与兼容、集成；

　　自研服务网格部分体系或全体系： 不受限与 Istio 等开源社区，对开源服务网格的弱项针对性加强。

　　在 2021 年，一大批 Istio 相关的优秀项目开源，围绕易用性、扩展性、运维性等方面增强 Istio：

　　与服务网格将微服务治理能力下沉到基础设施层（Sidecar）的思想类似，多运行时（Multi-Runtime）在 2020 年由 Bilgin Ibryam 提出，其对 Sidecar 模式的各种形态进行了总结和升华。多运行时自身特点可以归纳如下：

　　eBPF 技术的出现使得在 Linux 内核编程并运行沙盒程序成为可能，而且无需更改内核源代码或加载内核模块。这就使得开发者可以从内核出发增强系统的可观察性、优化网络及其安全性。在服务网格领域，eBPF 可以用于Sidecar 网络加速，并且可以从底层观测内核消息队列、任务队列、网络包信息、网络连接等更深层次的信息。

　　在 2021 年，Cilium（eBPF 开源框架） 提出了用eBPF 替代 Sidecar 实现内核级服务网格（数据面代理）的构想，以解决独立 Sidecar 带来的部署资源消耗、延时性能损耗等问题，实现真正意义上流量治理、观测能力下沉到基础设施层。不过，Cilium 的这一大胆构想很快就收到了来自 “传统” 服务网格阵营的 “反击”，理由包括 eBPF 实现服务代理能力的诸多限制、操作复杂、协议处理复杂度高、内核版本有依赖等等。

　　不论如何，eBPF 技术融入服务网格生态已经是一个新趋势，即使无法真正实现 Sidecar 的完美替代，eBPF 同样可以作为 Sidecar 的有力补充，使两者在流量链路上水融。

　　服务网格在诞生之初就以独立 Sidecar Proxy 负责流量的代理、治理、观测，服务网格实现框架也都默认以独立 Proxy 方式来组织数据平面能力，并与应用进程内的 传统微服务框架划清界限，各谈利弊，似乎 Proxy 模式就是服务网格数据平面的标准模式。在 2021 年，应用进程内框架与独立 Sidecar Proxy 间的 “次元壁” 被打破，Proxyless理念被越来越多提及。

　　无侵入 Agent： 无侵入方式实现业务代码增强，原理可以参考我们之前 从服务框架到服务网格，网易轻舟双引擎多模式服务治理演进实践 一文中 “服务框架：无侵入 Agent 服务治理” 部分介绍；

　　原生 RPC 支持： 新版本 gRPC 直接提供治理功能，并支持了直接对接控制平面的标准 xDS 协议；

　　从架构演进层面考量，Proxyless 有 “逆流” 发展的嫌疑。不过，从务实落地角度来看，Proxyless 为 Proxy 带来的能力补充，或许可以更好地帮助企业完成从传统架构到云原生架构的逐步迁移落地。

　　针对服务网格 2021 的复盘到这里告一段落，对于服务网格的未来，我们充满信心。在本文的最后，给出我们对服务网格的未来展望：

　　随着服务网格技术的逐步精进成熟，以及越来越多行业的落地经验积累，技术面和场景面所面临的挑战终将被克服，服务网格落地门槛逐步会趋于零。

　　服务网格的技术能力和场景覆盖得以高度抽象化和通用化，服务网格平台 / 产品也会随之高度标准化，企业选择服务网格平台 / 产品会更加容易。

　　以 Envoy、Istio 为代表的服务网格技术会助力实现相关软件领域的统一，如更多的 L7 流量代理会以 Envoy 为核心构建，数据平面与控制平面之间会以 xDS 协议交互等。企业架构师想实现的分布式体系全局统一治理将不再是奢望。

　　服务网格不同生态间不会是对立关系，最终会 “务实” 地形成 “合力”，彼此共赢：在流量链路上的 Proxyless - Proxy - eBPF 协作，能力互补；多运行时下存在的能力短板可以融合服务网格的成熟能力，加速自身发展。

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

　　后续，迷你书、专题将集合发布与 InfoQ 官网，登录 InfoQ 官网：注册并将 InfoQ 添加进收藏夹，精彩不错过。

　　2021 InfoQ 年度技术展望直播周将在元旦前后两周持续输出精彩内容，关注 InfoQ 视频号，与行业技术大牛连麦~

　　解读操作系统的2021：触到了创新的天花板，却站在巨变的前夜首次揭秘，字节跳动数据平台为什么不选“纯中台制”前滴滴技术总监受贿千万案宣判：获刑5年罚金50万；阿里计划出售微博全部股份；字节高级工程师薪资排世界第五 Q资讯 解读大前端的 2021 ：究竟“卷”出了什么名堂？

　　2021 InfoQ 写作平台年度优质创作者评选火热进行中，2021 年度优质创作者、年度社区荣誉共建者、年度影响力作者即将揭晓！2021 年 12 月入驻并发布文章还有机会获得“失之交臂奖”～