阿里巴巴 Service Mesh 落地的架构与挑战

点击下载《不同的 双11 技术：阿里巴巴经济体云原生实践》

本文节选自《不同的 双11 技术：阿里巴巴经济体云原生实践》一书，点击上方图片便可下载！

做者 | 方克明（溪翁）阿里云中间件技术部技术专家

导读：云原生已成为整个阿里巴巴经济体构建面向将来的技术基础设施，Service Mesh 做为云原生的关键技术之一，顺利完成在 双11 核心应用严苛而复杂场景下的落地验证。本文做者将与你们分享在完成这一目标过程当中咱们所面临和克服的挑战。

部署架构

切入主题前，须要交代一下在 双11 核心应用上落地的部署架构，以下图所示。在这篇文章中，咱们主要聚焦于 Service A 和 Service B 之间 RPC 协议的 Mesh 化。

图中示例说明了 Service Mesh 所包含的三大平面：即数据平面（Data Plane）、控制平面（Control Plane）和运维平面（Operation Plane）。数据平面咱们采用的是开源的 Envoy（上图中的 Sidecar，请读者注意这两个词在本文中能够互换使用），控制平面采用的是开源的 Istio（目前只使用了其中的 Pilot 组件），运维平面则彻底自研。

与半年前落地时不一样，此次 双11 核心应用上落地咱们采用了 Pilot 集群化部署的模式，即 Pilot 再也不与 Envoy 一块儿部署到业务容器中，而是搭建了一个独立的集群。这一变化使得控制平面的部署方式演进到了 Service Mesh 应有的终态。

挑战

落地所选择的 双11 核心应用都是采用 Java 编程语言实现的，在落地的过程当中咱们面临了如下挑战。

1. 在 SDK 没法升级的情形下如何实现应用的 Mesh 化

在决定要在 双11 的核心应用上落地 Mesh 时，Java 应用依赖的 RPC SDK 版本已经定稿，为了 Mesh 化彻底没有时间去开发一个适用于 Mesh 的 RPC SDK 并作升级。那时，摆在团队面前的技术问题是：如何在不升级 SDK 的情形下，实现 RPC 协议的 Mesh 化？

熟悉 Istio 的读者想必清楚，Istio 是经过 iptables 的 NAT 表去作流量透明拦截的，经过流量透明拦截可在应用无感的情形下将流量劫持到 Envoy 中从而实现 Mesh 化。但很不幸，NAT 表所使用到的 nf_contrack 内核模块由于效率很低，在阿里巴巴的线上生产机器中被去除了，所以没法直接使用社区的方案。好在年初开始不久咱们与阿里巴巴 OS 团队达成了合做共建，由他们负责承担 Service Mesh 所需的流量透明拦截和网络加速这两块基础能力的建设。通过两个团队的紧密合做，OS 团队探索了经过基于 userid 和 mark 标识流量的透明拦截方案，基于 iptables 的 mangle 表实现了一个全新的透明拦截组件。

下图示例说明了存在透明拦截组件的情形下，RPC 服务调用的流量走向。其中，Inbound 流量是指调进来的流量（流量的接受者是 Provider 角色），而 Outbound 是指调出去的流量（流量的发出者是 Consumer 角色）。一般一个应用会同时承担两个角色，因此有 Inbound 和 Outbound 两股流量并存。

有了透明拦截组件以后，应用的 Mesh 化彻底能作到无感，这将极大地改善 Mesh 落地的便利性。固然，因为 RPC 的 SDK 仍存在之前的服务发现和路由逻辑，而该流量被劫持到 Envoy 以后又会再作一次，这将致使 Outbound 的流量会由于存在两次服务发现和路由而增长 RT，这在后面的数据部分也将有所体现。显然，以终态落地 Service Mesh 时，须要去除 RPC SDK 中的服务发现与路由逻辑，将相应的 CPU 和内存开销给节约下来。

2.短期内支持电商业务复杂的服务治理功能

路由

在阿里巴巴电商业务场景下的路由特性丰富多样，除了要支持单元化、环境隔离等路由策略，还得根据 RPC 请求的方法名、调用参数、应用名等完成服务路由。阿里巴巴内部的 Java RPC 框架是经过嵌入 Groovy 脚原本支持这些路由策略的，业务方在运维控制台上配置 Groovy 路由模板，SDK 发起调用时会执行该脚本完成路由策略的运用。

将来的 Service Mesh 并不打算提供 Groovy 脚本那么灵活的路由策略定制方案，避免由于过于灵活而给 Service Mesh 自身的演进带去掣肘。所以，咱们决定借 Mesh 化的机会去除 Groovy 脚本。经过落地应用所使用 Groovy 脚本的场景分析，咱们抽象出了一套符合云原生的解决方案：扩展 Istio 原生的 CRD 中的 VirtualService 和 DestinationRule，增长 RPC 协议所需的路由配置段去表达路由策略。

目前阿里巴巴环境下的单元化、环境隔离等策略都是在 Istio/Envoy 的标准路由模块内作了定制开发，不可避免地存在一些 hack 逻辑。将来计划在 Istio/Envoy 的标准路由策略以外，设计一套基于 Wasm 的路由插件方案，让那些简单的路由策略以插件的形式存在。如此一来，既减小了对标准路由模块的侵入，也在必定程度上知足了业务方对服务路由定制的须要。设想的架构以下图所示：

限流

出于性能考虑，阿里巴巴内部落地的 Service Mesh 方案并无采用 Istio 中的 Mixer 组件，限流这块功能借助阿里巴巴内部普遍使用的 Sentinel 组件来实现，不只能够与已经开源的 Sentinel 造成协力，还能够减小阿里巴巴内部用户的迁移成本（直接兼容业务的现有配置来限流）。为了方便 Mesh 集成，内部多个团队合做开发了 Sentinel 的 C++版本，整个限流的功能是经过 Envoy 的 Filter 机制来实现的，咱们在 Dubbo 协议之上构建了相应的 Filter（Envoy 中的术语，表明处理请求的一个独立功能模块），每一个请求都会通过 Sentinel Filter 作处理。限流所需的配置信息则是经过 Pilot 从 Nacos 中获取，并经过 xDS 协议下发到 Envoy 中。

3. Envoy 的资源开销过大

Envoy 诞生之初要解决的一个核心问题就是服务的可观测性，所以 Envoy 一开始就内置了大量的 stats（即统计信息），以便更好地对服务进行观测。

Envoy 的 stats 粒度很细，甚至细到整个集群的 IP 级别，在阿里巴巴环境下，某些电商应用的 Consumer 和 Provider 服务加起来达到了几十万之多的 IP（每一个 IP 在不一样的服务下携带的元信息不一样，因此不一样的服务下的相同 IP 是各自独立的）。如此一来，Envoy 在这块的内存开销甚是巨大。为此，咱们给 Envoy 增长了 stats 开关，用于关闭或打开 IP 级别的 stats，关闭 IP 级别的 stats 直接带来了内存节约 30% 成果。下一步咱们将跟进社区的 stats symbol table 的方案来解决 stats 指标字符串重复的问题，那时的内存开销将进一步减小。

4. 解耦业务与基础设施，实现基础设施升级对业务无感

Service Mesh 落地的一项核心价值就是让基础设施与业务逻辑彻底解耦，二者能够独立演进。为了实现这个核心价值，Sidecar 须要具有热升级能力，以便升级时不会形成业务流量中断，这对方案设计和技术实现的挑战仍是蛮大的。

咱们的热升级采用双进程方案，先拉起新的 Sidecar 容器，由它与旧的 Sidecar 进行运行时数据交接，在新的 Sidecar 准备发接管流量后，让旧的 Sidecar 等待必定时间后退出，最终实现业务流量无损。核心技术主要是运用了 Unix Domain Socket 和 RPC 的节点优雅下线功能。下图大体示例了关键过程。

数据表现

公布性能数据一不当心就会引起争议和误解，由于性能数据的场景存在不少变量。好比，并发度、QPS、payload 大小等对最终的数据表现将产生关键影响。也正因如此，Envoy 官方历来没有提供过本文所列出的这些数据，背后的缘由正是其做者 Matt Klein 担忧引起误解。值得强调的是，在时间很是紧迫的情形下，咱们所落地的 Service Mesh 并不是处于最优状态，甚至不是最终方案（好比 Consumer 侧存在两次路由的问题）。咱们之因此选择分享出来，是但愿让更多的同行了解咱们的进展和状态。

本文只列出了 双11 所上线核心应用中某一个的数据。从单机 RT 抽样的角度，部署了 Service Mesh 的某台机器，其 Provider 侧的 RT 均值是 5.6ms，Consumer 侧的是 10.36ms。该机器在 双11 零点附近的 RT 表现以下图所示：

没有部署 Service Mesh 的某台机器，Provider 侧的均值为 5.34ms，Consumer 侧的则是 9.31ms。下图示例了该机器在 双11 零点附件的 RT 表现。

相比之下，Provider 侧的 RT 在 Mesh 化先后增长了 0.26ms，Consumer 侧则增长了 1.05ms。注意，这个 RT 差是包含了业务应用到 Sidecar，以及 Sidecar 处理的全部时间在内的，下图示例说明了带来时延增长的链路。

总体上，该核心应用全部上线了 Service Mesh 的机器和没有上线 Service Mesh 的机器在某个时间段的总体均值数据作了对比。Provider 侧 Mesh 化后的 RT 增长了 0.52ms，而 Consumer 侧增长了 1.63ms。

在 CPU 和内存开销方面，Mesh 化以后，Envoy 所消耗的 CPU 在全部核心应用上都维持在 0.1 核左右，会随着 Pilot 推送数据而产生毛刺。将来须要借助 Pilot 和 Envoy 之间的增量推送去对毛刺作优化。内存的开销随着应用的服务和集群规模不一样而存在巨大差别，目前看来 Envoy 在内存的使用上仍存在很大的优化空间。

从全部双11 上线的核心应用的数据表现来看，Service Mesh 的引入对于 RT 的影响和带来的 CPU 开销是基本同样的，而内存开销则由于依赖服务和集群规模的不一样而有至关大的差别。

展望

在云原生的浪潮下，阿里巴巴借这波技术浪潮致力于打造面向将来的技术基础设施。在发展的道路上将贯彻“借力开源，反哺开源”的发展思路，经过开源实现技术普惠，为将来的云原生技术在更大范围的普及作出本身的贡献。

接下来，咱们的总体技术着力点在于：

• 与 Istio 开源社区共同加强 Pilot 的数据推送能力。在阿里巴巴具有 双11 这种超大规模的应用场景下，咱们对于Pilot 的数据推送能力有着极致的要求，相信在追求极致的过程当中，能与开源社区一道加速全球事实标准的共建。从阿里巴巴内部来看，咱们目前拉通了与 Nacos 团队的共建，将经过社区的 MCP 协议与 Nacos 对接，让阿里巴巴所开源的各类技术组件能体系化地协同工做；
• 以 Istio 和 Envoy 为一体，进一步优化二者的协议以及各自的管理数据结构，经过更加精炼、更加合理的数据结构去减小各自的内存开销；
• 着力解决大规模 Sidecar 的运维能力建设。让 Sidecar 的升级作到可灰度、可监控和可回滚；
• 兑现 Service Mesh 的价值，让业务与技术设施能以更高的效率彼此独立演进。

本书亮点

• 双11 超大规模 K8s 集群实践中，遇到的问题及解决方法详述
• 云原生化最佳组合：Kubernetes+容器+神龙，实现核心系统 100% 上云的技术细节
• 双 11 Service Mesh 超大规模落地解决方案

“ 阿里巴巴云原生微信公众号（ID：Alicloudnative）关注微服务、Serverless、容器、Service Mesh等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发者的技术公众号。”