共计 7888 个字符，预计需要花费 20 分钟才能阅读完成。
服务网格的 2021，“稳”字当先。不论是原生社区倒退，还是行业实际落地，都以“稳固”为第一要义。少了前几年大跃进式的架构演进、性能更迭，多了更求实、更落地的行业摸索与实际，2021 年的服务网格正从当年那个狂奔的“少年”、“流量明星”，成长为真正的“实力派”，逐渐进入成熟期，被更多行业、企业和标准化组织所接收。本文将从社区停顿、实际落地、行业标准、技术生态等角度回顾服务网格的 2021，帮忙读者理解过来一年服务网格的整体停顿，为企业选型、落地服务网格提供一些参考。
社区停顿：稳固求实
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 年服务过的多家金融行业头部企业，及其他公开的技术材料，总结了金融行业企业对服务网格技术的典型诉求。
落地零门槛
在 微服务 2020 年度复盘 一文中，咱们提出“平滑落地撑持”是企业落地服务网格的两大要害因素之一。在金融行业，这一点尤为显著。服务网格 落地零门槛，是企业的外围诉求之一。
咱们演绎了服务网格撑持企业落地须要具备的“三要素”：通信协议，注册核心，部署环境。
通信协议：服务网格能反对的服务通信协议，常见的如 HTTP、gRPC、Dubbo 等，另外也有具备行业属性的公有 RPC 协定；
注册核心：服务网格能纳管的注册核心，包含常见的 Eureka、Consul、Nacos、Zookeeper 以及 Kubernetes（ETCD）；
部署环境：服务网格能反对的业务部署环境，除了人造云原生的 Kubernetes + Docker 外，对于遗留零碎所在的虚拟机、物理机，也须要同等对待。
在满足“三要素”后，服务网格能力达到业务落地的“及格线”。
此外咱们发现，金融行业还存在着更多“拦路虎”：
严格的环境管控：部署平台（容器、虚拟机、物理机）与根底平台（微服务、中间件）分属不同团队，又因为企业职责划分、金融合规要求等因素，服务网格的落地受到了诸如 网络环境、管理权限、金融标准 等更多限度；
简单的存量零碎：头部金融行业企业大多已具备了比拟残缺的分布式体系，但也存在不少简单、异构的外采、遗留零碎，因为多开发语言、多通信协议、无奈批改代码、没有注册发现机制等因素，不少零碎无奈纳管在已有体系中，成为企业分布式体系的“孤岛”。
架构场景匹配
与传统微服务框架偏重笼罩服务治理能力的业务场景不同，服务网格重点解决企业的架构场景问题。除了要实现云原生体系下微服务纳管与治理能力外，还须要笼罩 异构利用对立治理、遗留零碎迁徙 等架构场景需要，真正意义上解决企业微服务化后存在的整体性问题。
咱们演绎了金融行业企业在架构场景方面的典型诉求如下：
多集群、多机房业务的纳管：包含提供失常的服务发现、调用、治理、跨区域容灾等；
现有单体、微服务架构，向云原生服务网格架构长期、平滑、稳固迁徙演进：以业务无感知形式，从现有架构逐渐灰度形式演进到服务网格架构，迁徙过程服务互通、可治理、可观测，并保障高 SLA。
外围价值
在初步实现服务网格认知后，企业用户往往会收回灵魂拷问：为什么要上服务网格？服务网格有什么价值？
一般来说，通识的服务网格外围价值“标准答案”是：
业务无需感知微服务组件：微服务架构撑持、网络通信、治理等相干能力下沉到基础设施层，业务部门无需投入专人开发与保护，能够无效升高微服务架构下研发与保护老本；
反对多开发语言、框架：服务网格人造不限度开发语言、开发框架，提供多语言服务治理能力；
框架降级零老本：反对框架热降级，升高中间件和技术框架客户端、SDK 降级老本；
微服务体系对立纳管、演进：将存量微服务集群、遗留零碎、外购零碎微服务体系对立治理、演进。
对于企业外部不同团队，服务网格价值偏重会有所不同：
基础架构 / 平台研发团队：更看重服务网格笼罩的架构场景
多开发语言、框架无关，能够纳管各种业务利用接入；
框架降级零老本，无需业务重启或感知；
微服务体系对立纳管、演进，能够将已有微服务集群、遗留零碎、外购零碎等“一把抓”，对立治理与演进；
业务研发团队：更看重服务网格笼罩的业务场景
一键接入微服务治理全套治理、监控能力，如熔断、限流、降级、容错、故障注入、指标监控、链路追踪等；
遗留、外购零碎能够纳入对立治理，具备等同治理、监控能力，与其余业务微服务互联互通；
无需感知微服务组件，业务研发者不再须要学习、钻研和保护微服务相干技术与框架。
面临挑战
即便 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 年进入稳定期，服务网格技术生态也在这一年百花齐放百家争鸣。
开源我的项目
在 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 合作，能力互补；多运行时下存在的能力短板能够交融服务网格的成熟能力，减速本身倒退。
参考资料（特别感谢服务网格畛域的诸多实践者与分享者）：
从服务框架到服务网格，网易轻舟双引擎多模式服务治理演进实际：https://www.infoq.cn/article/…
解读微服务的 2020：框架在左网格在右，云原生时代的微服务路在何方：https://www.infoq.cn/article/…
云原生时代的流量入口：Envoy Gateway：https://www.infoq.cn/article/…
Istio 1.9 公布——重点改善 Istio 的 Day2 操作：https://mp.weixin.qq.com/s/E7…
Istio 1.10 公布及官网改版：https://mp.weixin.qq.com/s/Lq…
Istio 1.11 公布：https://mp.weixin.qq.com/s/Qk…
Istio 1.12 公布：https://mp.weixin.qq.com/s/Q5…
基于 gRPC 和 Istio 的无 Sidecar 代理的服务网格：https://mp.weixin.qq.com/s/aY…
都 2021 年了，对于服务网格，社区到底在探讨什么：https://mp.weixin.qq.com/s/ZD…
Dapr v1.0 瞻望：从 servicemesh 到云原生：https://skyao.io/talk/202103-…
辞别 Sidecar—— 应用 EBPF 解锁内核级服务网格：https://mp.weixin.qq.com/s/W9…
译文：服务网格将应用 eBPF？是的，但 Envoy 代理将持续存在：https://mp.weixin.qq.com/s/iZ…
作者介绍：
裴斐，网易数帆高级技术专家、资深架构师。10 余年企业级平台架构和开发教训，目前次要负责网易数帆轻舟微服务团队，专一于企业微服务架构及云原生技术的钻研与落地工作。率领团队实现轻舟服务网格、微服务框架、API 网关等多个我的项目在网易团体落地及商业化产品输入，并主导建设了 Slime、Hango 等多个云原生开源我的项目。
