站长工具手机综合查询,网络营销的六大功能,手机兼职平台网站开发,苏州塔维斯网站建设简介#xff1a;本文不打算回顾 Istio 或是阿里云服务网格 ASM 的变化或趋势#xff0c;我们来聊一聊阿里云 ASM 服务网格#xff0c;它的最终用户是如何使用服务网格的。
作者#xff1a;叶剑宏
背景
阿里云服务网格 ASM 于 2020 年 2 月公测#xff0c;近 2 年的时间…简介本文不打算回顾 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 LimitGlobal Rate Limit 需要提供统一的 Rate Limit ServerLocal Rate Limit 则通过 EnvoyFilter 下发到 Sidecar 本地配置。Global Rate Limit 的问题在于依赖集中式限流服务并在每一个服务 Sidecar 拦截过程中引入新的延迟而 Local Rate Limit 则缺乏全局判断并且配置 EnvoyFilter 不便。我们认为 EnvoyFilter 在生产环境的引入是应该非常谨慎的Envoy 版本更新很容易造成不兼容。
阿里云服务网格 ASM 基于 Envoy filter 机制集成了 sentinel filtersentinel 本是阿里巴巴开源的限流熔断项目如今被集成到 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 产品仍有需要完善的地方但它已经在市场验证中获得了前行的力量。服务网格的史诗故事才刚刚开始。
原文链接
本文为阿里云原创内容未经允许不得转载。
