什么是Service Mesh？什么是 Multi Runtime? Istio 与 Dapr？

 All problems in computer science can be solved by another level of indirection

                                                                      -------------------  David Wheeler

计算机领域的每个问题都可以通过引入中间层解决，这句计算机格言相信大多人都曾听过。自 Service Mesh 模式推出以来，业界至今没有形成一套标准化架构，即使是广泛使用的 Istio 也经历了几次重大架构变革，本质上 Mesh 也是一层代理。本文介绍 Service Mesh 模式的场景、演进、多种部署架构，以及与 Multi Runtime 的联系。

0 背景

通常在多云环境下存在异构问题和跨语言问题，比如

• 某些中间件的非标语言SDK不够稳定

• 业务在不同环境下，消息队列、配置中心、RPC、存储等中间件和技术选型不同导致业务代码难以兼容，有厂商锁定风险

• 非 Java 应用无法使用 Java 开发的SDK

这些问题可以考虑通过 Service Mesh 或 Multi Runtime 解决。

1 Service Mesh

从单体架构演进到微服务，微服务已经极大满足了业务中的实际需要，如故障域控制、独立升级、可扩展、可重用等，但微服务拆分引入了开发更复杂、代码更繁重的问题，原因是对于中间件等公用能力需要每一个微服务引入其 SDK，带来了业务代码与中间件代码深度耦合、SDK 升级成本高、版本不统一、微服务策略无统一控制等痛点。

Service Mesh，中文即服务网格，可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控，它负责构成现代云原生应用程序的复杂服务拓扑来可靠地交付请求。在实践中，通常以轻量级网络代理阵列的形式实现，这些代理与应用程序代码部署在一起，对应用程序来说无需感知代理的存在。一种常见的 Service Mesh 结构如下图，每个元素都是一个pod，绿色代表业务容器，蓝色则是边车代理，流量出入由代理完成。

其初衷是提供更丰富的服务治理、安全性、可观测性等核心能力，让通用能力下沉到“代理”中，便于业务瘦身和快速迭代。

1.1 Sidecar 

Sidecar 模式则是实现 Service Mesh 的架构模式之一，作为基础设施层，每个服务和一个轻量 Sidecar 容器一同部署，由 Sidecar 容器接管出入流量。Sidecar 模式允许您在应用程序旁边添加更多功能，而无需额外第三方组件配置或修改应用程序代码。

需要明确的是，Service Mesh 的本质不是 Sidecar 模式，其本质是标准化的服务间通信标准，Sidecar 模式只是当前较为成熟的实现方式之一。

1.2 几种 Sidecar 部署模式

Sidecar 的部署模式选型一直以来都是业界争论的重点，时至今日仍然不存在公认的标准模式，争论的主要原因在于资源消耗问题。上文所介绍的最常见的 Sidecar per Workload 模式无疑是资源消耗最大的，即使足够轻量，数量的放大效果也使得资源问题不得不被重视。

目前提出了 4 种部署模式，如下图：

下表中详细对比了这四种部署方式，它们各有优劣，具体选择哪种根据实际情况而定

模式	内存开销	安全性	故障域	运维
Sidecar 代理	为每个 pod 都注入一个代理，开销最大。	由于 Sidecar 必须与工作负载一起部署，工作负载有可能绕过 Sidecar。	Pod 级别隔离，如果有代理出现故障，只影响到 Pod 中的工作负载。	可以单独升级某个工作负载的 sidecar 而不影响其他工作负载。
节点共享代理	每个节点上只有一个代理，为该节点上的所有工作负载所共享，开销小。	对加密内容和私钥的管理存在安全隐患。	节点级别隔离，如果共享代理升级时出现版本冲突、配置冲突或扩展不兼容等问题，则可能会影响该节点上的所有工作负载。	不需要考虑注入 Sidecar 的问题。
Service Account / 节点共享代理	服务账户 / 身份下的所有工作负载都使用共享代理，开销小。	工作负载和代理之间的连接的认证及安全性无法保障。	节点和服务账号之间级别隔离，故障同 “节点共享代理”。	同 “节点共享代理”。
带有微代理的共享远程代理	因为为每个 pod 都注入一个微代理，开销比较大。	微代理专门处理 mTLS，不负责 L7 路由，可以保障安全性。	当需要应用 7 层策略时，工作负载实例的流量会被重定向到 L7 代理上，若不需要，则可以直接绕过。该 L7 代理可以采用共享节点代理、每个服务账户代理，或者远程代理的方式运行。	同 “Sidecar 代理”。

1.3 Istio

Istio 是由 Google、IBM 和 Lyft 开源的微服务管理、保护和监控框架。Istio 为希腊语，意思是起航。Istio 是一个用于服务治理的开放平台，它是第二代 Service Mesh 的典型代表，从2017年5月发布第一个版本0.1开始就被广泛关注，直到现在成为被业界公认 Service Mesh 最成功的实现。

Istio 提供的治理功能主要有：

流量管理：Istio 通过简单的规则配置和流量路由，可以控制服务之间的调用的流量和API调用。简化了熔断、超时和重试等配置，并且可以轻松设置 A/B 测试和金丝雀发布等任务；

安全：Istio 管理服务间通信的认证机制、通道加密服务和访问授权，可以保障服务通信的安全性，并且所有的这些功能都不必更改应用程序；

可观测性：Istio 具备强大的链路追踪、监控和日志记录能力，从而方便了解服务的运行状况，发现并解决问题。

从架构上来看，Istio 分为数据平面和控制平面，数据平面默认采用 Envoy，负责流量的治理和与控制平面的交互，控制平面由 Pilot、Citadel 和 Galley 组成，负责服务发现、路由、配置管理等。

数据平面由一组以 Sidecar 方式部署的智能代理 Envoy 组成，所有进入和流出服务的流量都会被 Envoy 拦截，并与控制面进行交互，根据配置执行相应的通信功能。Envoy 之所以称之为智能，是因为 Envoy 相对于其他代理来说有着更丰富的治理能力和灵活的配置方式，并且支持各种插件可用于扩展流量治理能力，并生成遥测数据。

在控制平面上，Istio由三个组件（ Pilot、Citadel、Galley ）整合成了一个单进程、多模块的Istiod，极大的降低了部署的复杂度。其中 Pilot 组件负责提供服务发现、智能路由和弹性功能（如超时、重试）；Citadel 负责安全，管理密钥和证书；Galley 负责对配置的验证和处理等功能。Istiod作为一种全新的设计，构建了一套标准的控制面规范，主要提供服务发现、规则配置和证书管理等功能，并向数据平面传递这些信息。

1.3.1 无 Sidecar 模式 - Ambient Mesh

自诞生以来，Istio 架构的一个决定性特征就是使用 Sidecar 模式，Sidecar 模式允许服务获得 Istio 的好处，而不需要应用程序进行大幅改造。尽管 Sidecar 模式相比重构应用程序具有显著优势，但它们并没有提供应用程序和 Istio 数据平面之间的完美分离，这导致了一些限制：

• 侵入性：Sidecar 通过 Inject 的方式注入到 Pod 中，因此安装或升级 Sidecar 需要重新启动应用程序 Pod

• 资源利用不足：Sidecar 增加了资源负载，必须为每个 Pod 的最坏使用情况配置 CPU 和内存资源，这会导致大量预留，从而导致整个集群的资源利用不足

• 流量破坏：流量捕获和 HTTP 处理的计算成本很高，并且可能会破坏某些非标的 HTTP 实现的应用程序

为了克服上述缺点，Istio 官方在1.11版本提出了 Proxyless 模式，继而在2022年9月7日正式推出了 Ambient Mesh 架构。

从图中我们可以看到 Ambient 模式对应用程序本身没有任何侵入，而是在应用程序外围：

• 同 node 上部署 ztunnel：使用 Envoy 实现的共享代理，多租户模式，负责 L4 网络，主要是安全性方面

• 以服务账户为单位部署 Waypoint proxy：同样使用 Envoy 实现，单租户模式，使用 Gateway API 部署的 Gateway 资源，负责 L7 网络，当服务需要 L7 网络功能的时候才部署

Ambient Mesh 本质是将 Sidecar L4 和 L7 做了分层，以更低的成本接入，但是当前 Ambient Mesh 仍在实验阶段，还不可投入生产环境使用，如节点部署 ztunnel 爆炸半径过大等因素还需要更多的优化和考量。

1.3.2 xDS

Service Mesh 数据面和控制面之间的通信采用控制面标准 API xDS （x Discovery Service）协议交互，xDS 是一套基于 grpc 的协议，通常 Sidecar 需要与 Pilot 保持长连接，设计上是解决4层和7层问题，在多运行时架构中并不适用，因此 Dapr 等多运行时框架并未采用 xDS。

2 Multi Runtime

Service Mesh 只解决了服务间通讯的需求，而现实中的分布式应用存在更多需求，比如“协议转换”、“状态管理”等。Multi-Runtime 架构提出将各种各样的分布式能力外移到独立 Runtime，最后和应用 Runtime 共同组成微服务，形成所谓的“Multi-Runtime”（多运行时）架构。

Bilgin Ibryam 在2020 年发表文章 "Multi-Runtime Microservices Architecture" ，正式提出了多运行时微服务架构（别名 Mecha）。Bilgin Ibryam是《Kubernetes Patterns》一书的作者，Apache Camel 项目的 committer，目前工作于 Red Hat 。在这篇文章中，Bilgin Ibryam 巧妙的总结了分布式应用存在的四大类需求：

分别是 Binding（绑定）、State（状态管理）、Lifecycle（生命周期）、Networking（网络），每种类型下面还有一些子能力，如 Point-to-Point， pub/sub， Caching 等常用的中间件能力。因此 Multi Runtime，其本质是面向云原生应用的分布式能力抽象层。

目前对于 Multi Runtime 的实现，主要是开源 CNCF 项目 dapr 和蚂蚁 Layotto 等。

2.1 与 Service Mesh 的差异

虽然同为 Sidecar 部署模式，但是和 Service Mesh 相比，Multi-Runtime 有自身的特点：

• 提供能力的方式和范围：Multi-Runtime 提供的是分布式能力，体现为应用需要的各种分布式原语，并不局限于单纯的服务间点对点通讯的网络代理

• 交互方式：Multi-Runtime 和应用之间的交互是开放而且有 API 标准的，另外 Multi-Runtime 不要求无侵入，还会提供各种语言的 SDK 以简化开发。

Multi-Runtime 和 Service Mesh 的差异总结如下图所示：

2.2 Dapr

Dapr is a portable, event-driven runtime that makes it easy for any developer to build resilient, stateless and stateful applications that run on the cloud and edge and embraces the diversity of languages and developer frameworks.

Dapr 是一个可移植的、事件驱动的运行时，它使任何开发者都能轻松地构建运行在云和边缘的弹性、无状态和有状态的应用程序，并拥抱语言和开发者框架的多样性。

Dapr (distributed application runtime) 是由微软发起的开源项目，由 Go 语言编写，现已被收纳入 CNCF。Dapr 为应用提供各种分布式能力，以简化应用的开发，通过与应用约定抽象的中间件协议，实现多运行时的无感接入，同时解决了部分跨语言调用问题。下图表示了 Dapr 的主要能力以及和 Service Mesh 的区别与联系：

Darp 中将各类抽象的能力称为 Building Blocks 构建块，包括服务调用、状态管理、发布订阅、资源绑定、可观测性等，构建块定义了标准化的 API。每个构建块由可插拔的 Component 组件组成，组件下则接入了各类 runtime，对应具体的实现。

Dapr 在 Service Mesh 的基础上进一步扩展 Sidecar 模式的使用场景，一方面提供天然的多语言解决方案，满足云原生下应用对分布式能力的需求，另一方面提供面向应用的分布式能力抽象层和标准 API，为多云、混合云部署提供绝佳的可移植性，避免厂商锁定。

3 总结

本文介绍了 Service Mesh 和 Multi Runtime 架构

感兴趣的朋友未来可以关注下多运行时的发展。如果 Service Mesh 解决的是服务间的通信问题，那多运行时，就是 Service Mesh 的延展和升华，对分布式应用运行时所需的能力进行了抽象，对外暴露统一的分布式原语 API，并且不局限于 Sidecar 模式，甚至支持 node 模式，以适应更多应用场景，为多云、混合云部署提供更好的可移植性，避免厂商锁定。

4 Reference

从Service Mesh到Multi-Runtime - Ruilin 《从service mesh到multi-runtime》

一年增加1.2w星，Dapr能否引领云原生中间件的未来？ 《dapr能否引领未来》

如何看待 Dapr、Layotto 这种多运行时架构？_开源_周群力_InfoQ精选文章 《如何看待 Dapr、Layotto 多运行时架构》

不是所有的应用都需要Service Mesh架构_架构_Tina_InfoQ精选文章 《不是所有的应用都需要 Service Mesh 架构》

Beyond Istio OSS —— Istio 服务网格的现状与未来 · Jimmy Song《Istio服务网格现状与未来》

Istio 《Istio官网》

Dapr Docs 《dapr官网》

Istio / Introducing Ambient Mesh 《Introducing Ambient Mesh》

关于 Istio 推出 ambient 数据平面模式的看法 · Jimmy Song《关于 Istio 推出 Ambient 数据平面模式的看法》

Common discovery API components (proto) — envoy 1.29.0-dev-503242 documentation 《xDS协议request官方说明》