介绍：本文无意回顾Istio或阿里云服务网格ASM的变化或趋势。下面说说阿里云ASM服务网格，以及它的终端用户是如何使用服务网格的。作者：叶剑红背景阿里云服务网格ASM于2020年2月上线公测，近两年大量用户将其作为生产应用的服务管理平台。阿里云服务网格ASM建立在开源Istio之上。同时，Istio还很年轻。2021年，我们会看到Istio的很多新进展，比如eBPF、Multi-buffer、Proxyless等。Istio的每一个变化都牵动着人们的神经——是时候采用服务网格了吗？本文无意回顾Istio或阿里云服务网格ASM的变化或趋势。下面说说阿里云ASM服务网格，以及它的终端用户是如何使用服务网格的。为什么要使用服务网格？服务网格的概念是将服务治理能力下沉到基础设施，让业务更专注于业务逻辑。我们可以很容易地举出服务网格带来的服务治理能力，比如流量管理、可观察性、服务安全通信，以及流量限制和访问控制等策略增强。但是最终用户真的需要这些功能吗？Istio的这些能力真的能满足生产需求吗？为一两个功能引入服务网格是否值得？比如流量管理，大家最关心的就是TrafficSplitting，经常用在规范发布或者A/B测试中。Istio的功能设计非常简单，但默认无法实现全链路流量管理。如果没有在所有微服务拓扑节点中透传自定义的header或tag，是完全不可能通过关联来切分业务流量的。比如在安全能力方面，使用传统手段对大量微服务进行TLS认证几乎是不可能完成的任务，而Envoy提供的mTLS加密可以轻松完成服务间的加密通信，或者零信任安全。然而，用户真的关心服务间安全吗？毕竟，这些微服务中的大多数都运行在云上VPC中的Kubernetes集群中。比如可观察性，Istio统一了Metrics、Logging、Tracing，可以方便的获取微服务拓扑，快速定位微服务问题。但是Sidecar无法深入流程层面，相关的Metrics和Tracing与经典的APM软件相比相形见绌，无法真正有效定位代码层面的问题。最后是限流能力等策略增强，Istio提供了GlobalRateLimit和LocalRateLimit限流能力，这确实是大量面向消费者的应用的强烈需求。但它真的能满足复杂生产应用的限流降级需求吗？真实的生产环境多种多样，ServiceMesh在落地的过程中会遇到各种挑战。终端用户最关心的服务网格有哪些能力，在实施过程中有哪些实践经验？ServiceMesh用户主要采用哪些能力？我暂时不回答上面提出的问题。下面来看看阿里云服务网格的服务网格ASM用户主要使用了哪些能力。相信读者会形成自己的答案。流量管理首先当然是流量管理，这是Istio最显着提升应用发布快乐度的能力。阿里云服务网格ASM大多数用户选择ASM服务网格是出于流量管理的需要。流量管理主要用于规范发布或A/B测试。最常见的应用场景如下：上图中的灰度流量切换发生在Ingress网关上，服务关闭在自己的Namespace中。该解决方案简单有效。缺点是每个灰度都需要在灰度Namespace中部署全量的微服务。另一个简单的想法是实现全链路灰度发布，我有时喜欢称之为暗发布。什么是全链路灰度发布？如下图所示：一个或多个服务可以任意灰度化，无需高成本部署全微服务。基于社区Istio的Header-basedtrafficrouting，可以实现全链路灰度发布，前提是在全链条的每个服务中，开发一个透传指定的自定义header。这种方法看起来有点费功夫，而且每个服务都需要进行侵入式的修改。在落地的过程中，只有新的项目和应用才可以一开始就这样设计。有其他选择吗？阿里云服务网格ASM提供了基于Tracing的全链路灰度发布解决方案。原理并不复杂。由于整个微服务链需要一个header或label来串联服务请求，traceid显然是一个现成的“连接器”。与自定义header的透传相比，这似乎是“换汤不换药”。跟踪访问也需要代码入侵。但是，Tracing有一个开源标准。在实现Tracing的同时，还开启了全链路的流量管理能力。这就是开源标准的力量。另外，如果是Java应用，阿里云ARMS提供了无需代码沉浸即可接入Tracing的能力，配合阿里云ServiceGridASM实现无需修改代码的全链路灰度发布。让我们回到登陆场景。在ASM用户中，中小企业或应用程序往往能够建立完整的跟踪。反倒是大公司应用多，溯源环节又碎片化，真是头疼。幸运的是，相关服务的灰度往往发生在“本地”，而本地的服务链路完整性已经可以满足灰度要求。南北流量管理上面我们讨论的主要是东西流量管理，而南北流量管理是一个生态比较丰富的领域。Solo在这个领域的GlooEdge和GlooPortal堪称典范，国内也有很多基于Envoy或者面向Mesh的API网关。Istio-ingressgateway和LagacyAPIGateway有什么区别和联系？社区中有很多讨论。我个人的观点是原子力没有明显的区别，只是运行的接口不同，现在的生态不同而已。部分用户之所以采用阿里云服务网格ASM，并不是服务治理的需要，而是借用了Istio-ingressgateway的增强能力。Istio的Gateway、VirtualService、DestinationRule定义明显比KubernetesIngress模型更清晰，层次分明。加上Envoy强大的可扩展性，Envoy和Istio-ingressgateway在网关选择上逐渐受到青睐。举个简单的例子——gRPC负载均衡，Envoy/Istio实现起来很简单，很多用户的Istio选型都是从这里开始的。比如AIServing推理服务场景，服务链路并不长，Sidecar带来的延迟几乎可以忽略不计。Istio/Envoy在网关上的扩展目前大多基于Lua或者WASM，通过Envoyfilter可以实现很多自定义的能力扩展。着陆挑战也非常简单明了。用户说小妾不会写Lua，更不会写WASM。云厂商说可以，我就写。如果基于场景扩展写的东西太多，可以把它们放在一起作为一个插件市场，根据自己的需要选择。从今年的用户角度来看，WASM知道的多了，但是应用起来还是比较复杂。让我们来看一个常见的应用场景——入口流量标记，或流量着色。根据入口流量的特征，如来源私网或Internet、登录用户信息等进行流量标记。标记后进行流量导流或灰度发布。另一个值得添加的场景是Egress流量控制。很多对应用安全要求高的用户使用IstioEgressgateway来控制7层应用的访问范围，NetworkPolicy容易实现三四层，七层控制可以考虑servicemesh。多语言服务治理上面我们讲了Istio的流量管理，貌似基本解决了这个问题。但是人们往往忽略了一个隐藏的前提——流量管理能力需要被Kubernetes服务发现，或者服务间调用需要携带Host头或者访问KubernetesclusterIP。在现实世界中，大量使用注册中心作为服务发现的微服务应用都运行在ACK上，并且有多种语言。我们看到，多语言使用正变得越来越普遍，这通常是业务快速增长的结果。为了快速满足需求，不同项目的不同团队选择了不同的语言进行开发，服务治理需求后来也提上了日程。这些微服务可以是带有ZK、Eureka、Nacos的Dubbo或SpringCloud微服务，或者带有Consul、ETCD和Nacos的Go、C++、Python和PHP微服务应用程序。这些服务从registry获取实例PodIP列表，通过Envoy成为PassthroughCluster，直接绕过Envoy过滤链，流量管理等Istio能力无从谈起。因此，Istio从诞生之日起就承诺的多语言无侵入微服务治理在现实世界中充满了荆棘。不同注册中心的微服务和注册到Kubernetes和Pilot的微服务如何玩得开心？一个简单的解决方案是去除注册中心，使用KubernetesCoreDNS服务发现，完全使用ServiceMesh。采用该方案的ASM用户往往是新开发的应用或者是对老应用进行重构，服务链接较短的应用。但是，如果很多应用采用这种方案，将不得不考虑开发的侵入式修改和应用的平滑迁移等挑战，在实际实施中会面临更多的障碍。应该保留原有的应用架构还是为Kubernetes设计？左转右转？这是一个问题。针对需要保留注册中心的场景，阿里云设计了两种方案：服务发现同步和服务发现拦截。什么是服务发现同步？既然问题的根源是Nacos/Consul注册中心和Pilot注册都存在，那么同步一下就可以了。Nacos/Consul通过MCPoverxDS同步到Pilot，使得Mesh端的服务可以发现左边的服务。如果左边的服务想通过原来的方式访问Mesh服务，添加一个同步组件，将Pilot注册信息同步到Nacos。这个方案有点复杂，但是好处是尽量保持原有的结构和开发方式。结合阿里云MSE，可以实现Java端微服务的服务治理。再来看另一种方案——服务注册拦截，或者说全Mesh方案。原理很简单。比如Nacos返回的注册实例的IP信息，被Sidecar截获，改成Kubernetes的clusterIP，这样Envoy过滤链就会重新生效。或者可以概括为“保留它，但忽略它”。全Mesh方案的好处也是显而易见的。所有的微服务都通过一个统一的Mesh技术栈（包括数据平面和控制平面）进行管理。解决方案清晰，没有开发意义。目前，这两个方案已经在阿里云用户中落地。哪一个更适合你的应用可能要具体分析。服务安全是指Istio提供的安全能力，从mTLS证书加密开始。在Istio默认的Permissive策略下，同一个网格中的所有服务都会自动获得mTLS加密能力（有些用户似乎并不知道它已经默认开启）。国内用户关注度不高，但ASM海外用户对mTLS有强烈需求。海外用户的理解是，一个Istio或者Kubernetes集群的节点可能分布在云端的多个AZ，而公有云的AZ分布在不同的机房，跨机房的流量可能会暴露非云管理器。被嗅探，还可能面临被机房管理员和运维人员窃取的风险。海外用户普遍更注重安全，这也算是中外“文化”的差异。许多用户提到的另一个是自定义外部授权。Istio默认支持的认证授权比较简单，比如基于sourceIP、JWT等，更复杂的授权通过Istio自定义的外部授权能力进行扩展和支持。IngressGateway的认证授权简单易懂，Mesh范围内任意服务授权的复杂工程在Istio的条件下轻松简化了很多。多集群服务网格Istio原生支持多个Kubernetes集群，阿里云服务网格ASM产品简化了多集群接入。为什么要使用多个集群？从目前的ASM用户来看，主要有两种：一种是多个业务中心统一Mesh管理。业务中心部署在不同的Kubernetes集群中，相对独立，业务中心之间直接相互调用。.Mesh可用于跨业务平台进行服务管理；二是跨AZ或Region双集群应用容灾。通过Istio的LocalityLoadBalancing可以实现跨AZ或Region的容灾切换。可观察性可观察性是指监控。当然，可观察性在云原生语境下有更丰富的含义，强调超前感知和主动干预。Istio对可观察性的增强主要是提供了丰富的协议层指标和服务sidecar日志。比如在熔断中，有些用户认为网格的sidecar是一个黑盒子，不清楚里面发生了什么，但实际上，Envoy对熔断过程揭示了清晰的指标。然而，我们发现大量用户对Istio和ASM提供的丰富指标知之甚少，往往没有很好地利用它们。这可能是用户的Istio采用阶段或功能优先级导致的，更可能的原因是作为云厂商，产品的可观察性没有做好。我们还有工作要做。此外，Mesh在应用层统一了Metrics、Logging、Tracing，越来越多的用户使用Grafana访问这三类数据源进行统一的可观察性分析。PolicyEnhancement在PolicyEnhancement部分，我们主要看限流能力。CommunityIstio提供全局速率限制和本地速率限制。GlobalRateLimit需要提供统一的RateLimitServer，LocalRateLimit通过EnvoyFilter发送到Sidecar本地配置。GlobalRateLimit的问题在于它依赖中心化的限流服务，在每个服务的sidecar拦截过程中引入了新的延迟，而LocalRateLimit缺乏全局判断，不方便配置EnvoyFilter。我们认为在生产环境中引入EnvoyFilter应该非常谨慎，因为Envoy版本更新很容易造成不兼容。阿里云服务网格ASM在Envoy过滤机制的基础上集成了sentinelfilter。Sentinel最初是阿里巴巴的一个开源限流和断路器项目。现在它已集成到Envoy中，提供更丰富和面向生产的性能和策略增强。支持流量控制、排队、断路器、降级、自适应过载保护、热点流量控制和可观察性。服务网格生产实践从生产应用来看，Envoy和Pilot都表现不错，在中小规模场景（1000个pod）没有问题。对于中大规模（超过1000个pod），相应的配置细节需要做相应的优化。Observability访问，EnvoySidecarlogging不会消耗太多性能，大量使用metrics可能会导致sidecar内存增加。跟踪采样率需要在生产环境中进行控制。大规模的xDS配置加载需要通过一定的手段来控制。有一些开源解决方案。ASM还提供了基于访问日志分析自动推荐的sidecar配置方案，使得相应工作负载上的sidecar只会专注于与自身调用依赖。服务信息。在Istio的一些功能配置中，也有一些需要注意的地方，比如重试策略的超时时间和退避延迟的关系，以及雷羊效应的避免。另外需要注意的是Istio-ingressgateway在高并发场景下的专有部署和配置优化，以及Sidecar的优雅上线和下线。这里我就不细说了。服务网格的未来？阿里云服务网格ASM作为托管服务网格的先行者，获得了大量的用户，这些用户更加坚定了我们做这个产品的信心。服务网格不再是一堆流行语，而是一个真正的生产应用，处理一个又一个琐碎的技术问题。回归本质，服务网格还是要解决业务问题。ServiceMesh社区蓬勃发展，ASM产品仍有待完善，但在市场验证中已经蓄势待发。服务网格的史诗故事才刚刚开始。原文链接本文为阿里云原创内容，未经许可不得转载。
