作者 | 叶剑宏
布景
阿里云服务网格 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 产品仍有需求完善的当地，但它现已在商场验证中获得了前行的力气。服务网格的史诗故事才刚刚开始。
