共计 6063 个字符，预计需要花费 16 分钟才能阅读完成。
简介：本文不打算回顾 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 的关系，以及惊群效应的防止。
另外一些须要留神的是 Istio-ingressgateway 在高并发场景下的专有部署和配置优化，Sidecar 的优雅上线和下线等。这里就不再细述。
服务网格的将来？
阿里云服务网格 ASM 作为托管服务网格的先行者，曾经播种了大量的用户落地，这些用户更加动摇了咱们做这个产品的信念。服务网格不再是成堆的 buzzword，而是真真实实的生产化利用，解决一个又一个的琐碎的技术问题。回到实质，服务网格还是要解决业务问题。
服务网格社区在蓬勃发展，ASM 产品仍有须要欠缺的中央，但它曾经在市场验证中取得了前行的力量。服务网格的史诗故事才刚刚开始。
原文链接
本文为阿里云原创内容，未经容许不得转载。
