服务网格 ASM 年终总结：最终用户如何使用服务网格？

简介：本文不打算回顾 Istio 或是阿里云服务网格 ASM 的变化或趋势，我们来聊一聊阿里云 ASM 服务网格，它的最终用户是如何使用服务网格的。

作者：叶剑宏

背景

阿里云服务网格 ASM 于 2020 年 2 月公测，近 2 年的时间，已有大量用户采用其作为生产应用的服务治理平台。阿里云服务网格 ASM 基于开源 Istio 构建。同时，Istio 仍然年轻，2021 年我们看到 Istio 不少新的进展，eBPF、Multi-buffer、Proxyless 等，每一次 Istio 的变化都牵动人们的神经——是时候采用服务网格了吗？

本文不打算回顾 Istio 或是阿里云服务网格 ASM 的变化或趋势，我们来聊一聊阿里云 ASM 服务网格，它的最终用户是如何使用服务网格的。

为什么采用服务网格

服务网格的理念是将服务治理能力下沉到基础设施，让业务更加专注于业务逻辑。我们可以很轻松地举出服务网格带来的服务治理能力，比如流量管理、可观测性、服务安全通信、策略增强如限流和访问控制等。但是，最终用户真的需要这些功能吗？Istio 的这些能力真的满足生产要求吗？为了一两个功能引入服务网格是否值得大费周章？

比如说流量管理，最受关注的是 Traffic Splitting，常用于灰度发布或者 A/B 测试。Istio 的功能设计非常简洁，但是默认无法实现全链路流量管理。如果没有在所有微服务拓扑节点里透传自定义的 Header 或标签，具有关联性的服务流量切割则完全不可能。

比如是安全能力，采用传统手段进行大量微服务 TLS 认证几乎是 Impossible Mission，而 Envoy 提供的 mTLS 加密则非常轻松地完成了服务间加密通信，或者说零信任安全。但是，用户是否真的关心服务间安全，毕竟这些微服务大多运行在云上的一个 VPC 的一个 Kubernetes 集群里。

比如可观测性，Istio 将 Metrics、Logging、Tracing 统一起来，可以很方便地获取微服务拓扑结构，快速地定位微服务问题。但是，Sidecar 无法深入进程级别，相关的 Metrics 和 Tracing 相比经典的 APM 软件实在相形见绌，无法真正有效地定位代码级别问题。

最后策略增强比如限流能力，Istio 提供 Global Rate Limit 和 Local Rate Limit 限流能力，确实是大量面向 C 端用户应用的强需求。但是它真的能满足复杂的生产应用限流降级需求吗？

真正的生产环境各式各样，服务网格在落地过程中又会遭遇各种各样的挑战。最终用户最关心的服务网格的能力是什么，在落地过程中又有怎么的实践经验？

用户主要采用服务网格什么能力？

我先暂时不回答上面提出的疑问。我们来看看阿里云服务网格 ASM 用户主要使用服务网格的哪些能力，我相信读者会形成自己的答案。

流量管理

首先当然是流量管理，这是 Istio 最显著地提升应用发布幸福感的能力。阿里云服务网格 ASM 大部分的用户出于流量管理的需求选择了 ASM 服务网格。而流量管理主要应用在灰度发布或 A/B 测试。最常见的应用场景如下：

上图的灰度流量切换发生在 Ingress 网关上，服务内部在各自的 Namespace 里闭环，方案简单有效。缺点是每次灰度需要在灰度的 Namespace 里部署全量微服务。另外一种朴素的想法是希望实现全链路灰度发布，我有时候喜欢称之为 Dark Release。什么是全链路灰度发布？如下图所示：

可以任意地灰度其中的一个或多个服务而不需要高成本地部署全量微服务。基于社区 Istio 的 Header-based traffic routing，可以实现全链路灰度发布，前提是在全链的每一个服务中，开发透传规定的自定义 Header。

这种方式显得稍费工夫，每个服务都需要侵入式的修改，落地过程中往往只有新的项目和应用能在一开始便如此设计。有没有替代方案？阿里云服务网格 ASM 提供了一种基于 Tracing 的全链路灰度发布方案。原理并不复杂，既然全链微服务需要有一个 header 或标签将服务请求关联性串联起来，traceid 显然是个现成的“连接器”。

这跟自定义 header 透传相比似乎有点显得“换汤不换药”，Tracing 接入一样需要代码侵入。但 Tracing 有开源的标准，实现 Tracing 的同时赋能了全链路流量管理能力，这是开源标准的力量。另外，如果是 Java 应用，阿里云 ARMS 提供了无代码浸入的 Tracing 接入能力，与阿里云服务网格 ASM 配合即可实现完全无代码修改的全链路灰度发布。

我们再回到落地场景，ASM 用户里常常是中小规模的企业或应用能够建立完整的 Tracing 跟踪，反而是大公司应用众多，Tracing 链路断得稀碎，实在让人头疼。好在关联服务的灰度往往发生在“局部”内，局部内的服务链路完整已经可以满足灰度的要求。

南北流量管理

我们在上面讨论的主要还是东西向流量管理，而南北向流量管理是一个具有更丰富生态的领域。Solo 公司在这一领域的 Gloo Edge 和 Gloo Portal 堪称楷模，国内也有不少的基于 Envoy 或面向 Mesh 的 API 网关。Istio-ingressgateway 与 Lagacy API Gateway 有什么区别和联系？社区有非常多的讨论，我个人的观点是，原子能力上没有明显差别，只是面向的操作界面不同和目前生态不同。

有些用户采用阿里云服务网格ASM的原因其实并不是需要服务治理，而是借用 Istio-ingressgateway 的增强能力。Istio 的 Gateway、VirtualService 和 DestinationRule 定义显然比 Kubernetes Ingress 模型更加清晰，分层明确，再加上 Envoy 强大的扩展能力，Envoy 和 Istio-ingressgateway 在网关选型中逐渐受到青睐。举个简单的例子—— gRPC 负载均衡，Envoy/Istio 轻而易举实现，很多用户的 Istio 选型则由此出发。例如对 AI Serving 推理服务场景，服务链路不长，Sidecar 带来的延迟几可忽略。

Istio/Envoy 在网关上的扩展目前大多基于 Lua 或者 WASM，通过 Envoyfilter 可以实现非常多的自定义能力扩展。落地挑战也非常简单直接，用户说，臣妾不会写 Lua，更不会写 WASM 啊。云厂商说没关系，我来写啊，根据场景的扩展的东西写多了，就可以放在一块做个插件市场，按需选择。从今年的用户视角来看，WASM 知道的颇多，但应用起来仍然比较复杂。

举一个常见的应用场景——入口流量打标，或者流量染色。根据入口流量的特征，比如来源的私网或互联网、登录用户信息等进行流量打标。打标后的再进行流量分流或灰度发布。

还有一个场景值得补充，Egress 流量控制，不少对应用安全要求高的用户采用 Istio Egress 网关来控制应用七层可访问的范围。Network Policy 三四层易做，七层控制可考虑采用服务网格。

多语言服务治理

我们上面聊了一通 Istio 流量管理，似乎问题已经基本解决。但是人们经常忽略了一个潜藏的前提 —— 流量管理能力生效是需要服务采用 Kubernetes 服务发现的，或者说，服务间调用需要带上 Host 的 Header 或访问 Kubernetes clusterIP。现实世界中，ACK 上运行着大量采用注册中心作为服务发现的微服务应用，并且存在多语言。我们发现多语言越来越普遍，而这往往是业务快速发展的结果。为了快速满足需求，不同项目不同团队选择了不同的语言开发，服务治理需求随后才提上日程。这些微服务可能是采用 ZK、Eureka、Nacos 的 Dubbo 或 Spring Cloud 微服务，或者是采用 Consul、ETCD 和 Nacos 的 Go、C++ 、Python 和 PHP 微服务应用。这些服务从注册中心获取实例 Pod IP 列表，通过 Envoy是成为 PassthroughCluster，直接绕过了 Envoy filter chain，流量管理和其他 Istio 能力则无从谈起。

于是，Istio 从诞生之日起许诺的多语言无侵入微服务治理在现实世界中落地之路中布满荆棘。不同注册中心的微服务和注册到 Kubernetes 和 Pilot 的微服务如何能愉快地玩耍？

一个简单朴素的方案是，把注册中心拆掉，采用 Kubernetes CoreDNS 服务发现，全面用 Service Mesh。ASM 用户中采用这种方案的常常是新开发的应用或者老应用重构、服务链路较短的应用。但非常多的应用如果采用这种方案，将要考虑开发的侵入修改，应用的平滑迁移等挑战，在实际推行中会面临较多的阻碍。

应该保留原来的应用架构还是面向 Kubernetes 设计？向左走，向右走？It’s a Question。

对于需要保留注册中心的场景，阿里云设计了 2 个方案：服务发现同步和服务发现拦截。

什么是服务发现同步？既然问题根源在同时存在 Nacos/Consul 注册中心和 Pilot 注册，那就把它们互相同步一下就好了嘛，Nacos/Consul 通过 MCP over xDS 同步到 Pilot，让 Mesh 侧服务能发现左侧的服务。如果左侧的服务希望以保持原来的方式访问 Mesh 服务，再增加同步组件将 Pilot 注册信息同步到 Nacos。这个方案稍显复杂，好处是尽量保持原有的架构和开发方式。结合阿里云 MSE 可以实现对 Java 侧微服务的服务治理。

我们再来看另外一个方案——服务注册拦截，或者称之为全 Mesh 方案。

原理非常简单，将如 Nacos 的返回注册实例 IP 信息由 Sidecar 拦截篡改为 Kubernetes clusterIP，使得 Envoy filter 链重新生效。或者可以总结为 “Keep it, But ignore it”。全 Mesh 方案好处也显而易见，通过统一的 Mesh 技术栈(包括数据面和控制面)管理所有的微服务，方案清晰，对开发无感。

目前这 2 个方案都在阿里云用户中获得了落地实践，到底哪一个更适合你的应用，可能就得具体分析了。

服务安全

提到 Istio 提供的安全能力，首先便是 mTLS 证书加密。Istio 默认 Permissive 策略下，同一个网格内的所有服务都自动获得 mTLS 加密能力(有些用户似乎没有意识到已经默认开启了)。国内用户几乎不太关注这项能力，但 ASM 海外用户对 mTLS 却是强需求。一位海外用户的理解是，一个 Istio 或 Kubernetes 集群的节点可能分布在云上多个 AZ 中，而公有云的 AZ 分布在不同机房中，跨机房流量就可能暴露在非云的管理者里而被嗅探到，同时也可能面临来自机房管理者和运维人员的窃取风险。海外用户普便更重视安全，这也算是中外的“文化”差异了。

另外一个被较多用户提及的是自定义外部授权。Istio 默认支持的认证授权比较简单，比如基于 sourceIP、JWT 等，更复杂的授权则通过 Istio 的自定义外部授权能力进行扩展支持。入口网关处的认证授权容易理解，Mesh 范围内任意服务的授权这项复杂的工程在 Istio 的条件下轻松简化了很多。

多集群服务网格

Istio 原生支持多 Kubernetes 集群，阿里云服务网格 ASM 产品在多集群上做了简化接入。为什么采用多集群？从目前 ASM 用户来看，主要是 2 种：一是多个业务中台的统一 Mesh 管理，业务中台分别部署在不同的 Kubernetes 集群，相对来说比较独立，业务中台之间存在直接相互调用。通过 Mesh 能进行跨业务中台的服务治理；其二是跨 AZ 或 Region 的双集群应用容灾。通过 Istio 的 Locality Load Balancing 可以实现跨 AZ 或 Region 的容灾切换。

可观测性

可观测性指涉监控，当然可观测性在云原生语境下含义更加丰富，更强调提前感知和主动干预。Istio 对可观测性的增强主要在提供了丰富的协议层 metrics 和服务 sidecar 日志。举个例子，circuit breaking，有用户会觉得网格的 sidecar 是个黑盒，里面发生了什么也不太清楚，但其实 Envoy 对熔断过程都透出了清晰的指标。不过我们发现大量用户对 Istio 和 ASM 提供的丰富的 metrics 感知不多，也经常没有很好地利用起来。这可能是用户 Istio 采用阶段或功能优先级导致的，更可能的原因是作为云厂商没有把产品可观测性做好。我们仍需努力。

另外，Mesh 在应用层面统一了 Metrics、Logging 和 Tracing，越来越多用户采用 Grafana 接入这 3 类数据源进行统一的可观测性分析。

策略增强

策略增强部分我们主要来看看限流能力。社区 Istio 提供 Global Rate Limit 和 Local Rate Limit，Global Rate Limit 需要提供统一的 Rate Limit Server，Local Rate Limit 则通过 EnvoyFilter 下发到 Sidecar 本地配置。Global Rate Limit 的问题在于依赖集中式限流服务，并在每一个服务 Sidecar 拦截过程中引入新的延迟，而 Local Rate Limit 则缺乏全局判断，并且配置 EnvoyFilter 不便。我们认为 EnvoyFilter 在生产环境的引入是应该非常谨慎的，Envoy 版本更新很容易造成不兼容。

阿里云服务网格 ASM 基于 Envoy filter 机制集成了 sentinel filter，sentinel 本是阿里巴巴开源的限流熔断项目，如今被集成到 Envoy 中，提供了更加丰富且面向生产的性能和策略增强。支持流控，排队等待，熔断，降级，自适应过载保护，热点流控和可观测能力。

服务网格生产实践

从生产化应用来看，Envoy 和 Pilot 的性能都不错，在中小规模场景(1000 pod)下问题不大。中大规模(1000 pod 以上)则对相应配置细节需要做相应的优化。可观测性的接入，Envoy Sidecar logging 对性能消耗不大，metrics 开启在大规模下可能引发 Sidecar 内存升高，tracing 采样率在生产环境中需要有一定控制。

大规模下的 xDS 配置加载需要有一定的手段控制，开源有一些方案，ASM 也提供了基于访问日志分析自动推荐的 Sidecar 配置方案，使对应工作负载上的 Sidecar 将仅关注与自己有调用依赖关系的服务信息。

在 Istio 的一些功能性配置上，也有一些需要注意的内容，比如重试策略的 timeout 和 backoff delay 的关系，以及惊群效应的避免。