谈谈我对服务网格的理解

作者：王夕宁

服务网格作为一种用来管理应用服务通信的基础核心技术，为应用服务间的调用带来了安全、可靠、快速、应用无感知的流量路由、安全、可观测能力。

什么是服务网格技术

以 Istio 为代表的 Service Mesh 技术已经存在四五年的时间了，阿里云也是第一批支持 Service Mesh 云服务的厂商。在 Service Mesh 技术中，通过把服务治理的能力进行 Sidecar 化，实现与应用程序本身的解耦。这些若干个 Sidecar 代理就形成了一个网状的数据平面，通过该数据平面可以处理和观察所有应用服务间的流量。

负责数据平面如何执行的管理组件称为控制平面，是服务网格的大脑，它为网格使用人员提供公开 API，以便更容易地操纵网络行为。通过 Service Mesh，Dev/Ops/SRE 将以统一的、声明的方式解决应用服务管理问题。

服务网格一种应用感知的云原生基础设施

我们认为服务网格是一种应用感知的云原生基础设施。它不仅仅是服务治理，而且包括了其他几个维度的云原生应用感知的特征与能力。我们把它分为了 5 个部分，分别是：

云原生应用网络
云原生应用治理
云原生零信任安全
云原生可观测及应用弹性
云原生应用生态引擎****

云原生应用网络

首先来看云原生应用网络，分为 3 个部分来介绍。

Sidecar 模式下的云原生应用网络
数据面 L4 与 L7 代理解耦模式下的网络
基于地域可用区信息的优先路由

网络是 Kubernetes 的核心部分，涉及了 Pod 间通信、Pod 和服务间通信以及服务与外部系统间的通信等。Kubernetes 集群中使用 CNI 插件来管理其容器网络功能，使用 Kube-proxy 维护节点上的网络规则，譬如使发往 Service 的流量（通过 ClusterIP 和端口）负载均衡到正确的后端 Pod。

容器网络成为用户使用 IaaS 网络的新界面，以阿里云 ACK Terway 网络为例，基于阿里云 VPC 网络直通弹性网卡，具备高性能特征，同时无缝地跟阿里云 IAAS 网络对接。然而，kube-proxy 设置是全局的，无法针对每个服务进行细粒度控制，而且 kube-proxy 只是专在网络数据包级别上运行。它无法满足现代应用程序的需求，如应用层流量管理、跟踪、身份验证等。

我们来看服务网格 Sidecar 代理模式下的云原生应用网络是如何解决这些问题的。服务网格通过 Sidecar 代理将流量控制从 Kubernetes 的服务层中解耦，将代理注入到每个 Pod，并通过控制平面操纵管理这些分布式代理，从而可以更加精细地控制这些服务之间的流量。

那么在 Sidecar 代理下的网络数据包的传输是怎样的过程？

当前 Istio 实现中涉及了 TCP/IP 堆栈的开销，它使用了 Linux 内核的 netfilter 通过配置 iptables 来拦截流量，并根据配置的规则对进出 sidecar 代理的流量进行路由。客户端 pod 到服务器端 pod 之间的典型路径（即使在同一主机内）至少要遍历 TCP/IP 堆栈 3 次（出站、客户端 Sidecar Proxy 到服务器端 Sidecar Proxy、入站）。

为了解决这个网络数据路径问题，业界通过引入 eBPF 绕过 Linux 内核中的 TCP/IP 网络堆栈来实现网络加速，这不但降低了延迟，同时也提升了吞吐量。当然，eBPF 并不会替换 Envoy 的七层代理能力，在七层流量管理的场景下，仍然是 4 层 eBPF + 7 层 Envoy 代理的融合模式。只有在针对 4 层流量网络的情况下，跳过代理 pod 直接进入网络接口。

前面讲述的是传统的 Sidecar 代理模式，除此之外，业界开始探索一种新型的数据平面模式。它的设计理念是：将数据平面分层，4 层用于基础处理，特点是低资源、高效率；7 层用于高级流量处理，特点是功能丰富（当然也需要更多的资源）。这样的话，用户可以根据所需功能的范围，以渐进增量的方式采用服务网格技术。

具体来说，在 4 层处理中，主要包括：

流量管理： TCP 路由
安全： 面向 4 层的简单授权策略、双向 TLS
可观测： TCP 监控指标及日志

在 7 层处理中，则主要包括：

流量管理： HTTP 路由、负载均衡、熔断、限流、故障容错、重试、超时等
安全： 面向 7 层的精细化授权策略
可观测： HTTP 监控指标、访问日志、链路追踪

那么数据面 L4 与 L7 代理的解耦模式下，Service Mesh 的网络拓扑将是什么形式？

一方面，将 L4 Proxy 能力下移到 CNI 组件中，L4 Proxy 组件以 DaemonSet 的形式运行，分别运行在每个节点上。这意味着它是为一个节点上运行的所有 pod 提供服务的共享基础组件。

另一方面，L7 代理不再以 Sidecar 模式存在，而是解耦出来，我们称之为 Waypoint Proxy，它是为每一个 Service Account 创建的 7 层代理 pod。

4 层和 7 层代理的配置仍然保持通过 Service Mesh 控制面组件来进行下发管理。

总之，通过这种解耦模式，实现了 Service Mesh 数据平面与应用程序之间的进一步解耦分离。

那么，在 Istio 的具体实现中，可以分为 3 个部分：

Waypoint代理： L7 组件完全独立于应用程序运行，安全性更高；每个身份（Kubernetes 中的服务账户）都有自己专用的 L7 代理（ Waypoint 代理），避免多租户 L7 代理模式引入的复杂度与不稳定性；同时，通过 K8s Gateway CRD 定义触发启用；
ztunnel： 将 L4 处理下沉到 CNI 级别，来自工作负载的流量被重定向到 ztunnel，然后 ztunnel 识别工作负载并选择正确的证书来处理；
与 Sidecar 模式兼容： Sidecar 模式仍然是网格的一等公民，Waypoint 代理可以与部署了 Sidecar 的工作负载进行本地通信；

Service Mesh 作为云原生应用网络之场景示例：基于地域可用区信息的优先路由

在这个示例中，我们部署了两套一样的应用服务到 2 个不同的可用区下，即这个部署架构图中的可用区 A 和 B。正常情况下，这些应用服务本身是遵循了同 AZ 流量路由优先的机制，也就是说可用区 A 中的应用服务 productpage 会指向本可用区中的 reviews 服务。

而当本可用区服务不可用时，譬如 reviews 服务出现故障，容灾模式就会自动开启，这个时候可用区 A 中的应用服务 productpage 会指向另一可用区 B 中的 reviews 服务。

这个流量拓扑是阿里云 ASM 产品提供的网格拓扑中按可用区信息展示的调用链路。在实现同 AZ 路由的过程中，是不需要修改应用代码本身就可以完成的。

同样地，在不需要修改应用代码本身的情况下，Service Mesh 自动实现故障转移以保证高可用。这个拓扑图中可以看到可用区 A 中的应用服务会自动切换到调用可用区B中的服务了。

云原生应用治理

接下来看云原生应用治理，它的内容包含很多维度，这里重点摘取讲述 3 个部分。

服务慢启动以支持预热能力
全链路流量管理
与服务框架的融合

先来看下启用预热模式前后的差异。

未启用预热模式：

不支持新 Pod 的渐进式流量增加。每当新目标 Pod 加入时，请求方都会向该 Pod 发送一定比例的流量。这对于需要一些预热时间来提供全部负载的服务可能是不可取的，并且可能会导致请求超时、数据丢失和用户体验恶化。
作为一个实际示例，上述问题体现在基于 JVM 的 Web 应用程序中，这些应用程序使用水平 pod 自动缩放。当服务刚启动时，它会被大量请求淹没，这会导致应用程序预热时持续超时。因此，每次扩展服务时，都会丢失数据。

启用预热模式：

预热/慢启动模式又称渐进式流量增加，用户可以为他们的服务配置一个时间段。每当一个服务实例启动时，请求方会向该实例发送一部分请求负载，并在配置的时间段内逐步增加请求量。当慢启动窗口持续时间到达，它就会退出慢启动模式。
在慢启动模式下，在添加新的目标服务 Pod 时，可以使得他们不会被大量请求压倒，这些新目标服务可以根据指定的加速期在接受其均衡策略的请求之前进行预热。

通过这两个图也可以看到，在启用了预热模式之后，新创建的 pod 达到均衡的负载请求所需的时间会拉长，这也反映了在一定的预热时间内，进入该 pod 的请求是逐步增加的。

一个实际客户案例：扩容和滚动更新场景下支持预热实现服务优雅上线

背景：

Java 应用冷启动时大流量导致 CPU 打满，调用异常
应用滚动更新仅仅通过 readiness 无法实现优雅上线

支持预热实现服务优雅上线：

ASM 感知实例的上下线，当发现一台机器刚上线时，自动将其权重给调低，过了一定的时间后（预热周期）再将权重调到 100%（权重调整比例）；
对应用完全没有侵入性；

那这个功能是怎么在服务网格 ASM 中实现的呢，简单说，一行配置就可以实现预热、慢启动能力。这个拓扑图也是这个实际案例的脱敏简化版，可以看到通过预热功能：

能够实现业务的平滑启动，完美避免业务抖动问题；
启用预热功能之后，流量均衡地分布到 v1 和 v2 版本，相比未启用热功能多花费了 1 分 10 秒左右的时间，以此缓冲。

全链路流量管理，两个使用场景

全链路灰度发布：

在生产环境正常运行的同时，开始针对部分应用服务进行灰度升级，譬如图中的 B 和 D 应用进行灰度，在不需要修改应用逻辑的情况下，利用 Service Mesh 技术就可以实现根据请求来源或者请求的头信息，动态地路由到不同版本的服务上。譬如，当请求头中包含 tag1 时，应用 A 就会调用灰度版本 B，而 C 并没有灰度版本，系统就会自动 fallback 回退到原有的版本。

多版本开发环境：

类似地，有一个基线环境，其他不同的开发环境可以根据需要，分别部署各自版本的部分应用服务。根据请求来源或者请求的头信息，动态地路由到不同版本的服务上。

整个过程中，不需要修改应用代码逻辑，只需要针对应用打标，ASM 产品实现了一个 Traffic Label CRD 抽象定义，简化对流量和应用实例打标。

应用治理与服务框架融合

在遗留的应用系统中，仍然还是实现了类似 Spring Cloud 或者 Dubbo 的服务框架，服务网格 ASM 支持了多模服务治理，实现了调用互通、监控互通、治理互通。

通过 MCP over xDS 协议将原有注册中心的服务信息注册到 Service Mesh 中，通过 Service Mesh 控制面组件统一管理规则配置，并以 xDS 协议统一下发管理。

云原生应用的零信任安全

接下来看云原生应用的零信任安全，包括：

零信任的基础 - 工作负载身份
零信任的载体 - 安全证书
零信任的引擎 - 策略执行
零信任的洞察 - 可视化与分析

具体来说，构建基于服务网格的零信任安全能力体系包括了以下几个方面：

1、零信任的基础 - 工作负载身份， 如何为云原生工作负载提供统一的身份：ASM 产品为服务网格下的每一个工作负载提供了简单易用的身份定义，并根据特定场景提供定制机制用于扩展身份构建体系，同时兼容社区 SPIFFE 标准；

2、零信任的载体 - 安全证书， ASM 产品提供了如何签发证书以及管理证书的生命周期、轮转等机制，通过 X509 TLS 证书建立身份，每个代理都使用该证书，并提供证书和私钥轮换；

3、零信任的引擎 - 策略执行， 基于策略的信任引擎是构建零信任的关键核心，ASM 产品除了支持 Istio RBAC 授权策略之外，还提供了基于 OPA 提供更加细粒度的授权策略；同时，支持 dry-run 模式；

4、零信任的洞察 - 可视化与分析， ASM 产品提供了可观测机制用于监视策略执行的日志和指标，来判断每一个策略的执行情况等；

使用服务网格实现零信任具备如下优势：

Sidecar 代理生命周期独立
动态配置、无需重启
服务网格集中控制，降低开发心智负担
加强身份认证授权系统本身安全保障
集中管理并下发 OPA 授权策略
简化接入第三方授权服务、OIDC 身份认证

这是某平台使用网格零信任安全技术的场景。可以看到，客户使用中遵循了零信任安全架构的基本原则：

工作负载身份标识
服务认证
服务授权
TLS 加密
OPA 策略
最小权限访问策略

云原生应用的可观测及应用弹性

接下来看云原生应用的可观测及应用弹性，包括：

网格可观测中心
网格诊断
网格拓扑

网格可观测中心：统一的可观测性体系和联动分析（3 个维度）

一是日志分析。 通过对数据平面的 AccessLog 采集分析，特别是对入口网关日志的分析，可以分析出服务请求的流量情况、状态码比例等，从而可以进一步优化这些服务间的调用；
第二个可观测性能力是分布式追踪能力。 为分布式应用的开发者提供了完整的调用链路还原、调用请求量统计、链路拓扑、应用依赖分析等工具，可以帮助开发者快速分析和诊断分布式应用架构下的性能瓶颈，提高微服务时代下的开发诊断效率；
第三个可观测性能力是监控能力。 根据监视的四个维度（延迟，流量，错误和饱和度）生成一组服务指标, 来了解、监视网格中服务的行为。

网格诊断：检测网格配置的潜在问题及提供改进措施

根据我们对 Service Mesh 技术的客户支持和实战经验，在服务网格 ASM 中：

内置 30+ 项诊断规则、最佳实践
针对每个 Istio 资源对象提供语法的静态检查
支持多个 Istio 资源对象的执行语义的动态验证
针对诊断出的问题提供相应的改进措施

网格拓扑：提供对服务网格行为的即时洞察

除了强大的网格流量拓扑可视化之外，还提供了回放功能可以选定过去时间段的流量。

云原生应用的生态引擎

接下来看云原生应用的生态引擎，包括 3 个部分：

插件市场
能力中心
新场景定义

开箱即用的 EnvoyFilter 插件市场、WebAssembly 插件全生命周期管理

基于内置的模板，用户只需要根据对应的参数要求，进行简单配置，就可以部署出对应的 EnvoyFilter 插件。通过这样的机制，使得数据平面成为更易可扩展的插件集合能力。

能力中心: 服务网格与生态系统的集成整合能力

围绕服务网格技术, 业界存在着一系列以应用为中心的生态系统。其中, 阿里云托管服务网格 ASM 支持了以下多种生态系统，列举如下。

蓝绿发布、渐进式交付、GitOps、CI/CD
- 支持了与 Argo Rollout、Flagger 以及云效等系统的集成实现了应用的蓝绿或者金丝雀发布

微服务框架兼容

- 支持 Spring Boot/Cloud 应用无缝迁移至服务网格进行统一纳管和治理。
Serverless

- 支持 Knative 运行于托管的服务网格 ASM 之上, 用于部署和运行 Serverless 工作负载, 并基于服务网格实现了在各个版本之间的流量路由。
AI Serving

- Kubeflow Serving 是谷歌牵头发起的一个基于 Kubernetes 支持机器学习的社区项目，它的下一代名称改为 KServe，该项目的目的是可以通过云原生的方式支持不同的机器学习框架，基于服务网格实现流量控制和模型版本的更新及回滚。
Policy As Code
- OPA（Open Policy Agent）/声明式策略表达语言 Rego：在使用 Kubernetes Network Policy 实现三层网络安全控制之上，服务网格 ASM 提供了包括工作负载身份、对等身份和请求身份认证能力、Istio 授权策略以及更为精细化管理的基于 OPA(Open Policy Agent) 的策略控制能力。
- 一般来说，构建基于服务网格的零信任安全能力体系包括了以下几个方面：零信任的基础 - 工作负载身份，零信任的载体 - 安全证书，零信任的引擎 - 策略执行，零信任的洞察 - 可视化与分析。

此外，我们也在探索拓宽服务网格驱动的新场景，我这里举一个 AI Serving 示例。

这个需求来源也是来自我们的实际客户，这些客户使用场景就是希望在服务网格技术之上运行 KServe 来实现 AI 服务。KServe 平滑运行于服务网格之上，实现模型服务的蓝/绿和金丝雀部署、修订版本之间的流量分配等能力。支持自动伸缩的 Serverless 推理工作负载部署、支持高可扩展性、基于并发的智能负载路由等能力。

云原生基础设施的关键层，企业数字化转型的重要桥梁

作为业内首个全托管 Istio 兼容的服务网格产品 ASM，一开始从架构上就保持了与社区、业界趋势的一致性，控制平面的组件托管在阿里云侧，与数据面侧的用户集群独立。ASM 产品是基于社区开源的Istio定制实现的，在托管的控制面侧提供了用于支撑精细化的流量管理和安全管理的组件能力。通过托管模式，解耦了 Istio 组件与所管理的 K8s 集群的生命周期管理，使得架构更加灵活，提升了系统的可伸缩性。

托管式服务网格 ASM 在成为多种类型计算服务统一管理的基础设施中，提供了统一的流量管理能力、统一的服务安全能力、统一的服务可观测性能力、以及基于 WebAssembly 实现统一的代理可扩展能力，以此构筑企业级能力。可以点击文末“此处”查看具体的内容介绍。

总结如下，服务网格作为一种用来管理应用服务通信的基础核心技术，为应用服务间的调用带来了安全、可靠、快速、应用无感知的流量路由、安全、可观测能力。

可以看到，服务网格加持下的云原生应用基础设施带来了重要的优势，总结为以下六个方面。

优势之一：异构服务统一治理

多语言多框架的互通与治理、与传统微服务体系融合的双模架构
精细化的多协议流量控制、东西向与南北向流量的统一管理
统一的异构计算基础设施的自动服务发现

优势之二：端到端的可观测

日志、监控与跟踪融合的一体化智能运维
直观易用的可视化网格拓扑、基于颜色标识的健康识别体系
内置最佳实践、自助式网格诊断

优势之三：零信任安全

端到端 mTLS 加密、基于属性的访问控制 (ABAC)
OPA 声明式策略引擎、全局唯一的工作负载身份（Identity）
带有仪表板的完整审计历史记录及洞察分析

优势之四：软硬结合性能优化

首个基于 Intel Multi-Buffer 技术提升 TLS 加解密的服务网格平台
NFD 自动探测硬件特征, 自适应支持诸如 AVX 指令集、QAT 加速等特性
首批通过可信云服务网格平台以及性能评测先进级认证

优势之五：SLO 驱动的应用弹性

服务级别目标 (SLO) 策略
基于可观测性数据的应用服务的自动弹性伸缩
多集群流量突发下的自动切换与故障容灾

优势之六：开箱即用扩展 & 生态兼容

开箱即用的 EnvoyFilter 插件市场、WebAssembly 插件全生命周期管理
与 Proxyless 模式的统一融合，支持 SDK、内核 eBPF 方式
兼容 Istio 生态系统，支持 Serverless/Knative，AI Serving/KServe