作者 | 褚杏娟
Service Mesh（服务网格）的概念由 Buoyant CEO William Morgan 首次提出。2017 年 4 月该公司发布了第一个 Service Mesh 产品 Linkerd。当时在同一时间发表的文章《What’s a service mesh？And why do I need one?》也被公认是 Service Mesh 的权威定义。
“A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.”
翻译：Service Mesh 是一个处理服务通讯的专门的基础设施层。它的职责是在由云原生应用组成服务的复杂拓扑结构下进行可靠的请求传送。在实践中，它是一组和应用服务部署在一起的轻量级的网络代理，对应用服务透明。
为什么需要 Service Mesh？
Service Mesh 诞生的背景主要有两点：首先，微服务架构模式逐渐流行，开发者将多个服务组合在一起来构建应用程序；其次，企业已经使用了云原生平台技术，例如容器（Docker）、编排器（Kubernetes）和网关等。
Service Mesh 模式试图解决的问题包括：
- 无需将特定语言的通信库编译到单个服务中来处理服务发现、路由和 application-level (Layer 7) 非功能性通信需求。
- 外部化服务通信配置，包括外部服务的网络位置、安全凭证和服务质量目标。
- 为其他服务提供被动和主动监控。
- 在整个分布式系统中，执行分散策略。
- 提供可观察性默认值并标准化相关数据的收集，如启用请求日志记录、配置分布式跟踪、收集指标等。
Phil Calçado 在Pattern：Service Mesh 一文中讲述了服务通信演变的过程：
- 最初，流量管理和控制能力（比如图例中的熔断、服务发现）是和业务逻辑耦合在一起，即便以引用包的方式被调用，依然解决不了异构系统无法重用的问题。
- 流控功能和业务耦合相当不美好，于是出现了提供这些功能的公共库和框架。但这些库通常比较复杂，无论是学习使用，与业务系统整合、维护都会带来很大的成本。
- 为避免花费太多时间开发和维护这些通用库，人们希望流量控制能力可以下沉到网络通讯栈的层面，但几乎无法实现。
- 于是另一种思路出现，就是将这些功能独立成一个代理，由它先接管业务服务的流量，处理完成后再转发给业务服务本身，这就是 Sidecar 模式。
- 为统一管理 Sidecar，该模式进一步进化，形成网络拓扑，增加了控制平面，演变成 Service Mesh（最后的网格图中，绿色代表业务服务，蓝色代表 sidecar 服务）。
从上图可以看出，Service Mesh 就是 Sidecar 的网络拓扑形态，Mesh 这个词也由此而来。Service Mesh 的出现主要带来了以下两方面的变革：
- 解决了微服务框架中的服务流量管理的痛点，使开发人员专注于业务本身；
- 将服务通信及相关管控功能从业务程序中分离并下层到基础设施层，使其和业务系统完全解耦。
生态发展
2013 年，Airbnb 发布了 SmartStack ，为新兴的“微服务”架构提供了进程外服务发现机制（使用 HAProxy ）。当然，许多以企业在此之前都进行过此类技术的研究。从 2000 年代初开始，Google 就在开发 Stubby RPC 框架，后来演变为 gRPC 以及 Google Frontend (GFE) 和 Global Software Load Balancer (GSLB)，在 Istio 中依然可以看到这些产品的特征。2010 年代初期，Twitter 开始开发基于 Scala 的 Finagle，Linkerd 由此衍生而来。
2014 年底，Netflix 发布了一整套基于 JVM 的实用程序， 包括 Prana，这是一个“sidecar”进程，允许任何语言编写的应用程序服务通过 HTTP 与库的独立实例进行通信。2016 年，NGINX 团队开始谈论“ Fabric 模型”，它与服务网格非常相似，但需要使用他们的商业 NGINX Plus 产品来实现。此外，Linkerd v0.2 于 2016 年 2 月发布，尽管该团队后来才开始将其称为 Service Mesh。
Service Mesh 历史上的其他重要事件还包括 2017 年 5 月发布的 Istio、2018 年 7 月的 Linkerd 2.0、2018 年 11 月的 Consul Connect 和 Gloo Mesh 、2019 年 5 月的服务网格接口 (SMI) 以及同年 9 月发布的 Maesh（现称为 Traefik Mesh ） 和 Kuma。
其他企业的产品，如 HashiCorp 的 Consul 等，也都是从上述技术中汲取灵感。
实践现状
很多企业都是多协议、多语言栈的，他们选择使用 Service Mesh 来解决复杂的服务治理问题。在之前的一些实践取得正反馈后，Service Mesh 使用范围也在扩大。如今的 Service Mesh 不再局限于 RPC，开始向对象存储、加解密、MySQL、Redis 等领域深入。
但总体看，如今 Service Mesh 落地还是遇到了大的技术挑战，远没有达到企业理想的使用状态。有一定研发能力的企业使用传统治理模式也可以做得不错，这时就不会选择完全换成 Mesh 架构，只会在一些新的、没有历史负担的业务上试用。
本质上，Service Mesh 只是转移了复杂度，当业务发展到一定规模后，复杂度问题就会再次显现。sidecar 模式很适用于逻辑复杂的场景，如路由、治理，灵活且对业务无入侵。但在大规模场景下，其复杂度就上来了，性能优势不再明显，资源占用也变得不可忽略。可以说，sidecar 模式天生在大规模场景应用中就有一定的局限性。
为解决这个问题，今年九月，Istio 推出了 Sidecarless 的 Ambient Mesh。Ambient 是将 Istio 分成两个不同的层次：安全覆盖层（四层治理）和 七层处理层（七层治理）。但在网易数帆云原生平台负责人冯常健看来，四层治理模式将复杂度降到了 Node 级别，但可能只有对网格安全能力感兴趣的企业会尝试，而七层治理模式本质上还是独立的应用层代理，链路也并未减少。因此，对于该模式的应用，业内更多还是持观望态度。
现在，Service Mesh 社区还在统一的方向演化。比如今年 4 月谷歌声明将 Istio 捐赠给 CNCF，9 月份 Istio 正式成为 CNCF 孵化项目。这一事件使 CNCF 社区的确定性更强，也消除了前些年大家对社区治理、法规等方面的顾虑。
但在网关层面，社区基本还是分为 NGINX 和 Envoy 两派：Kong 、APISIX 等基于 NGINX，网易、阿里云等更多应用 Envoy 技术栈。有人认为 NGINX 及其生态已经比较成熟了，但随着 Kubernetes Gateway API 的成熟，今年社区推出了 Envoy Gateway 组件，新一轮网关标准定义的争论再次掀起。
Kubernetes Gateway API 对标的是 Ingress API。Ingress 的 API 解决流量从集群外导入集群内的问题，但表达能力较弱，使用场景有限，因此社区推出了 Kubernetes Gateway API，希望其提供更高级的网络能力。
Kubernetes Gateway API 直接促进了 Envoy Gateway 项目的发展。Envoy Gateway 进而统一了网关的控制面 API。原先网关控制面是通过 xDS 控制数据面，现在更多会基于 Kubernetes Gateway API。
实际上，现在各个企业都在从不同的方向尝试对 Service Mesh 进行完善和补充。虽然社区有了各种开源产品，但业内还没有形成像 Kubernetes 这样的事实标准。当有这样的一个事实标准出来后，Service Mesh 才会迎来自己的爆发。这与容器的发展轨迹是类似的。
Service Mesh 也在寻找更适合的落地方式。现在，业内有尝试不再将 Service Mesh 作为一个独立的产品，而是将其与 Serverless 结合。Serverless 不让用户去关心服务器，Service Mesh 不让用户关心服务治理，如果将服务治理的 Service Mesh 容器内置到 Serverless 平台里面，企业提交一个业务的容器进项后也会拥有 Serverless 的能力。