企业级服务网格平台：企业数字化转型和现代化改造的重要桥梁

以下内容摘自2022 CSDI 技术峰会演讲内容。

作者： 王夕宁  阿里云服务网格负责人

回顾什么是服务网格技术

以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实现统一的代理可扩展能力, 以此构筑企业级能力。可以通过https://www.aliyun.com/product/servicemesh 查看具体的内容介绍。

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

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

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

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

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

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

优势之三：零信任安全

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

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

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

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

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

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

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