关于devops:阿里巴巴服务网格技术三位一体战略背后的思考与实践

简介：本文分享了阿里巴巴服务网格技术三位一体策略背地的思考和实际，对于阿里云服务网格 ASM 的一些产品性能，包含最近公布的一些性能。

作者：宗泉、宇曾

阿里巴巴三位一体策略

阿里云外部很早就提出了开源、自研、商业化三位一体策略，先谈谈我对它的了解。

多年的软件开发教训通知咱们，开发出一款杰出的软件有一些要害因素：

• 沟通
• 反馈
• 实际

在软件开发过程中咱们不能闭门造车，不能随便“发明”业务场景需要。业务场景和产品性能须要提炼，开源给咱们提供了一个独特翻新的平台，基于这个平台，大家能够独特定义一些标准和规范。不同的厂商遵循相应的规范，客户就没有被锁定的危险，能够不停地迁徙，总是能找到最好的厂商，将本人的业务放上去，用最简略、最便捷、最经济的形式来经营本人的业务。

很多客户在抉择阿里云服务网格的时候，有一条比拟重要的评判指标：是否和社区 Istio 兼容。因为客户放心被锁定，强依赖于阿里云；

而后说到自研，兴许有同学会问到，开源与自研是否互相矛盾，答案是否定的。

因为，咱们这里提到的自研，其实是基于开源的自研，并非摒弃开源的版本，从新造个新的轮子。自研是指咱们要对开源产品有足够深度的了解：

• 要把握所有源代码；
• 领有批改每一行代码的能力
• 当然，自研还有意味着可能有本身业务特定独有的需要场景，一些没方法标准化的场景。

基于自研，对开源产品的深度把控和了解，咱们将有通用客户场景需要的性能搬到云上，封装成云产品，让云上客户能够开箱即用去应用，这是商业化的初心。

回到阿里团体外部，开源、自研、商业其实是一个技术飞轮。

对于阿里的技术同学来说，每年的 双 11 都是一场“盛宴”。为了让顾客有顺滑的购物体验，给商户提供更多样化的让利流动，阿里电商平台对于效率、可靠性、规模性的要求在 双 11 的驱动下成倍进步，激发着技术人的后劲。作为根底技术外围之一，阿里巴巴中间件也会在每年 双 11 迎来一次技术的全面演进和降级。

阿里在开源社区中推出了 Dubbo、RocketMQ、Nacos、Seata 等多个为人熟知的开源我的项目，激励宽广开发者共建中间件生态体系，也包含了 ServiceMesh 相干技术。

拥抱服务网格开源技术

阿里云外部很早就开始调研并实际 ServiceMesh 技术。2018 年，Istio 正式公布 1.0 版本，进入公众视线。在这更早期间，阿里巴巴外部曾经开始参加相干生态开源产品的奉献。

阿里云在微服务生态畛域，也有一些开源的服务化框架，比方 Dubbo、Spring Cloud Alibaba，能够说微服务畛域，因为电商这层试验大平台，阿里云在这方面是妥妥滴“技术专家”，咱们会进行横向性能比照，比照 Sidecar 模式和原有模式的优缺点；在这过程中，咱们也积极参与 Istio 微服务相干生态我的项目的开源奉献；例如 Envoy、Dubbo Filter、RocketMQ Filter、Nacos Mcp 性能、Spring Cloud Alibaba、Sentinel 等。

目前风行着各种各样的服务框架，如何基于不同的框架开发的可互通的业务？服务框架就像铁路的铁轨一样，是互通的根底，只有解决了服务框架的互通，才有可能实现更高层的业务互通，所以用雷同的规范对立，合二为一并共建新一代的服务框架是必然趋势。

Dubbo 和 HSF 都是阿里巴巴外部在应用的微服务 RPC 框架。这些框架在阿里业务一直迭代开发的过程提供了松软的底层微服务能力反对，保障了一个又一个 双 11 大促。

随同着云原生的浪潮，以及整体资源老本优化、DevOps 等大背景下，原有微服务框架 Dubbo、HSF 的一些毛病也在缓缓裸露进去，比方多语言的反对，配置和代码逻辑拆散等，SDK 版本升级须要推动业务方，收买的业务采纳不同框架互通的问题等。

阿里团体外部局部业务开始尝试应用服务网格技术来革新底层微服务框架，Dubbo 框架在 Mesh 化的过程中，阿里云服务网格团队奉献了 Envoy Dubbo Filter，就是为了实现原有 Dubbo 业务的 Mesh 化，以取得服务网格带来的新的增量价值。

另一方面，Dubbo 社区自身也在朝着云原生畛域往前迭代。Dubbo 从 Dubbo2.7.8 版本开始探讨 Dubbo 的云原生演进计划，为了更好地适配云原生场景（基础设施的变动 Kubernetes 已成为资源调度编排的事实标准），Dubbo 团队目前在将 Dubbo 2.0 向 Dubbo 3.0 做技术演进，并提出了 Proxyless Mesh 的设计。

随着业务逐步上云，因为上云门路的多样以及从现有架构迁徙至云原生架构的过渡态存在，部署利用的设施灵便异变，云上的微服务也呈现出多元化的趋势。跨语言、跨厂商、跨环境的调用必然会催生基于凋谢规范的对立协定和框架，以满足互通需要，这些场景，正式服务网格善于的畛域，给了服务网格很好的施展空间；

目前，Dubbo 3.0 社区版本已公布，外围变动有：

• 利用级服务发现
• Dubbo 2.0 协定演进为 基于 gPRC 的 Triple 协定
• 无 Sidecar 的 ProxylessMesh

Mesh 化不是欲速不达，对于原有的存量业务相似业务上云，存在一个两头过渡阶段，传统微服务框架，例如：Dubbo、Spring Cloud 等存量业务采纳 Nacos、Eureka、Zookeeper 服务注册核心，咱们须要对它进行兼容适配；基于 Istio 管制面凋谢的 Mcp Over XDS 协定，优先在 Nacos 实现了该协定反对，让 Istiod 能够间接对接 Nacos 注册核心。

开源产品在大规模生产环境往往不能间接应用，须要做一些适配和调优，以及一些产品化能力的封装；例如：Intel 的 mTLS 减速计划。

Intel 提交了 Envoy 侧 Upstream 的实现，但 Istiod 还未反对。作为云产品，咱们心愿提供给客户开箱即用的能力，服务网格 ASM 基于 Intel 开源的 mTLS 减速计划，实现了管制面 Istiod 的扩大反对，而且因为该 mTLS 减速计划依赖底层资源的理论 CPU 机型（icelake)，ASM 针对用户业务理论部署做了自适应的减速性能的开启和敞开，multiBuffer 减速性能在开启状态下，采纳阿里云 g7 代 ecs 作为 node 节点，QPS 有靠近 80% 的晋升。

提到服务网格，常常被提起的一个话题：“它和 Dapr 的区别是什么？”

Dapr 应用 Sidecar 架构，与应用程序一起作为独自的过程运行，包含服务调用、网络安全和分布式跟踪等性能。这常常会引发一个问题：Dapr 与 Istio 等服务网格解决方案相比如何？

尽管 Dapr 和服务网格的确存在一些重叠性能，但与专一于网络问题的服务网格不同，Dapr 专一于提供构建基块，使开发人员更容易将应用程序构建为微服务。Dapr 以开发人员为核心，而服务网格以基础设施为核心。此外，Dapr 不提供路由或流量调配等对于流量管制的性能。

当然, 两者能够部署在一起，此时，Dapr 和服务网格的 Sidecar 都在利用环境中运行。

服务网格在阿里巴巴的落地和实际

后面能够看到阿里针对微服务生态，开源了一些产品，这些产品其实在最开始都是因为有外部业务场景，基于这些外部业务场景的孵化和大规模业务测验，外部感觉内部客户也有相似需要，所以才把这些外部实现全副开源。

对应 Istio Mesh 同样也是，团体外部业务在很早就开始了 Mesh 的业务摸索，咱们具体来看：

从整体架构图能够看到，阿里团体外部提供了一套控制台供 Mesh 用户操作，控制台以利用为视角，集成 CICD、权限治理、平安生产、SRE 运维零碎等其余平台，提供利用接入 Mesh 化后的对立 Portal，让用户能够基于 DevOps 的理念，实现对利用的全生命周期治理，并通过 Mesh 形式提供应用服务治理、全链路灰度以及平安生产等能力，达到利用 Owner 能够自助和自愈运维的成果。

其中，Mesh 外围能力反对对 Dubbo、MetaQ(RocketMQ)、LWP 等 RPC 协定的反对，扩大实现了全链路染色、路由策略、插件市场等 Mesh 能力。

同时，阿里团体外部也反对通过 OpenAPI、Kubernetes API 形式提供给第三方系统集成的能力。

在社区 Istio 架构的根底上，阿里团体外部和外部中间件（Diamond、ConfigServer）做了深度集成，兼容保留业务的原始应用形式，让业务无缝接入到 Mesh，这也是咱们思考到局部 Mesh 业务有须要应用 Nacos，在 ASM 产品层面反对 Nacos 等多注册核心的场景；

同时形象出运维立体，能够通过 UI 控制台的形式实现服务流量治理规定（virtualservice、destinationrule 等) 的配置，同时通过和 OpenKrusise 的集成，实现 pod 粒度的 Sidecar 的开启、敞开以及热降级等性能，通过对团体外部 Prometheus 和 Grafana 以及告警 ARMS 的集成，实现微服务的可察看和可监控。

阿里团体服务网格的演进门路

阿里团体服务网格演进分为三个阶段：无侵入局部规模化、无侵入全面规模化、云原生终态，目前集群业务 Mesh 化处于第二阶段。

第一阶段：存量业务 Mesh 化存在一个过渡阶段，而且须要保障这个过渡阶段绝对无侵入，让业务开发者无感知；这是为什么咱们须要采纳无侵入计划的背景和前提；并且须要采纳 Mesh 笼罩已有的微服务治理的能力，同时提供 Mesh 的增量价值；

第二阶段：全面规模化，同时解决规模化带来的资源开销和性能问题，通过 Sidecarcrd 实现服务配置懒加载，达到配置隔离的问题，通过对 Metrics 的优化裁剪，升高 Sidecar 内存开销，同时通过优化 Dubbo/HSFFilter 实现惰性编解码，进步数据面解决性能升高提早。

随着外部业务 Dubbo 2.0/HSF 演进到 Dubbo 3.0，最终演进到云原生终态计划。

第三阶段：云原生终态，随着基础设施向 Kubernetes 演进，在云原生场景下，服务发现、服务治理能力下沉，通过 Mesh 能够解耦业务逻辑和服务治理，实现配置和代码逻辑拆散，从而更好地 DevOps 化，并享受 Mesh 带来的丰盛的可扩大流量调度能力和可察看性。

Dubbo/HSF RPC 反对多种序列化形式，而 Mesh 针对一些序列化并不能做到很敌对的反对，比方 Java 序列化。

因而，业务在 Mesh 化第一阶段，针对 Java 序列化，Sidecar 不做编解码，采纳 Passthrough 流量透传的形式；针对 Hessian2 序列化，Mesh 实现了残缺的编解码反对，并基于性能思考实现了惰性编解码。基于此，咱们能够实现对这类流量实现流量打标（染色）并通过扩大 VirtualService 的形式，实现标签路由和 Fallback 的能力。还能够实现一些特定的业务场景，如金丝雀公布、全链路灰度等场景；

外部业务 MeshSDK 这层会逐渐降级到 Dubbo3.0 SDK，在开启 Mesh 的场景下，Dubbo3.0 SDK 仅提供 RPC 等能力，对应 ThinSDK 模式，Mesh 化后，Sidecar 的协定反对友好度更好、资源开销老本有肯定的升高；当 Sidecar 故障时，能够快读切回 FatSDK 模式，业务无感知；

对于集群外部业务，流量调度存在一些较为简单的场景，特地是一些规模较大的业务。比方多机房多区域部署，同时在单个区域下还存在服务多版本、多环境的的路由等

这就波及到不同维度的路由和后端 cluster 抉择，这些维度可能有：

• 区域化路由
• 机房路由
• 单元化路由
• 环境路由
• 多版本路由

团体电商场景尤为典型，基于此，外部扩大 Istio 通过引入新的 CRD：RouteChain、TrafficLable 以及对 VirtualService 的扩大，实现了对流量打标和按标路由的能力。image.gif

商业化产品阿里云服务网格 ASM 也将这些能力进行了不同水平的透出，能够基于此实现比方金丝雀公布、A/B 测试、全链路灰度等场景。

云产品：阿里云服务网格 ASM

后面咱们介绍了阿里巴巴服务网格在开源和大规模落地方面的实际，接下来分享下在云原生三位一体中对于云产品方面的设计。阿里云通过总结业务场景落地教训，继续驱动技术倒退，积淀一系列服务网格核心技术。

在大规模落地方面：比方按需动静推送规定配置，大规模业务无损下 Sidecar 热降级，反对最全面的异构计算基础设施，反对多注册核心与平台。

在流量治理方面：提供了精细化的流量管制，按需对流量协定、端口动静拦挡，零配置实现申请标签路由以及流量染色，反对多种协定的精细化治理。

在可观测能力方面：提供了日志、监控与跟踪交融的一体化智能运维，同时基于 eBPF 加强可观测性，实现无侵入实现全链路可观测，辅助业务疾速排障。

在平安能力方面：反对 Spiffe/Spire、实现零信赖网络、加强认证鉴权机制, 反对渐进式逐渐实现 mTLS。

在性能优化方面：通过 eBPF 技术进行网络减速，实现软硬一体的性能优化。

阿里云服务网格 ASM 是业界首个兼容 Istio 的托管式服务网格平台，反对残缺的服务网格产品能力：精细化的利用流量治理、端到端的可观测能力、平安和高可用；反对多语言多环境、多种微服务框架、多协定互联互通等简单场景。服务网格 ASM 技术架构曾经升全面降级 V2.0，托管了管制面外围组件，保障了标准版和专业版的架构对立，平滑反对社区各个版本的降级。同时 ASM 在和社区规范对立的根底上进行各种能力加强。次要包含流量治理和协定加强，反对多种零信赖平安能力，反对对接 Nacos、Consul 等多种注册核心。除此之外通过网格诊断能力疾速剖析网格的健康状况，配合管制面告警疾速响应。

服务网格 ASM 和各种云服务能力充沛交融，包含链路追踪、Prometheus 监控、日志服务等可观测能力。集成 AHAS 反对服务限流、集群限流和自适应限流，联合微服务引擎 MSE 反对服务治理，并且可能给跨 VPC 多集群提供统一的治理体验。在自定义扩大方面反对 OPA 平安引擎，webAssembly 等自定义扩大能力。

用户能够通过 ASM 控制台、OpenAPI、申明式云原生 API、数据面和管制面 Kubeconfig 应用服务网格技术。通过服务网格 ASM 在管制面和管控面的打磨，能够为运行在异构计算基础设施上的服务提供对立的网格化治理能力（Anywhere Service Mesh），从入口网关到数据面 Sidecar 注入，反对容器服务 ACK、Serverless kubernetes、边缘集群和内部注册 Kubernetes 集群，以及 ECS 虚拟机等多种基础设施。

服务网格 ASM 的功能设计

基于 ASM 的流量打标和标签路由实现全链路灰度。微服务软件架构下，业务新性能上线前搭建残缺的一套测试零碎进行验证是相当费人费时的事，随着所拆分出微服务数量的一直增大其难度也愈大。基于“流量打标”和“按标路由”能力是一个通用计划，能够较好地解决测试环境治理、线上全链路灰度公布等相干问题。并且基于服务网格技术能够做到与开发语言无关，该计划适应于不同的 7 层协定，以后服务网格 ASM 曾经反对 HTTP/gRpc 和 Dubbo 协定。在 ASM 中引入了全新的 TrafficLabel CRD 用于定义 Sidecar 所需透传的流量标签从哪里获取，全链路流量管制进行逻辑隔离，对流量进行打标（染色）和按标路由，通过应用服务网格 ASM，无需每位技术研发人员部署一整套环境，实现多环境治理，大幅度降低研发老本。

服务网格 ASM 反对实现金丝雀公布。公布是整个性能更新到线上的最初一个环节，一些研发过程中累计的问题，在最初公布环节才会触发。同时公布自身也是一个简单的过程，在公布过程中，往往容易呈现一些错误操作或者脱漏要害操作。金丝雀公布配置灵便，策略自定义，能够依照流量或具体的内容进行灰度（比方不同账号，不同参数），呈现问题不会影响全网用户。图中给利用打上环境标签，通过 TrafficLable 对用户流量比方对 http-header: user-id % 100 == 20 打上 gray 标签，同时通过 VirtualService 下发标签流量路由规定，所以 userId 为 120 的用户流量会被路由到 gray 灰度环境，userId 为 121 的用户流量被路由到 normal 失常环境。服务网格 ASM 实现的金丝雀公布反对按流量百分比路由，按申请特色（如 http header, 办法参数等）路由，并且和服务网格入口网关完满集成，反对 HTTP/gRPC/Dubbo 协定。

除了应用流量打标和标签路由得实现全链路灰度和金丝雀公布，服务网格 ASM 也反对和 KubeVela 联合实现渐进式公布。KubeVela 是一个开箱即用的、现代化的利用交付与治理平台，可能简化面向混合环境的利用交付过程；同时又足够灵便能够随时满足业务一直高速变动所带来的迭代压力。KubeVela 后的利用交付模型 Open Application Model（OAM）是一个从设计与实现上都高度可扩大的模型，具备齐全以利用为核心、可编程式交付工作流、与基础设施无关的特点。阿里云服务网格 ASM 反对联合 KubeVela 进行简单的金丝雀公布流程能够将 KubeVela 定义的相干配置转化为流量治理规定下发到数据面。

阿里云服务网格 ASM 实现了零信赖平安能力。在微服务网络中应用 HTTP 通信的交互并不平安，一旦外部的某个服务被攻陷，攻击者可能以该机器为跳板来攻打内网。服务网格 ASM 可能减小云原生环境中的被攻打面积，并提供零信赖利用网络所需的根底框架。通过 ASM 治理服务到服务的安全性，能够确保服务网格的端到端加密、服务级别身份认证和细粒度受权策略。

相比传统的在利用程序代码中构建平安机制，ASM 零信赖平安体系具备以下劣势：

• ASM Sidecar 代理的策略生命周期与应用程序放弃独立，因而能够更轻松地治理这些 Sidecar 代理。
• ASM 反对动静配置策略，更新策略变得更加容易，更新立刻失效而无需重新部署应用程序。
• ASM 提供了对附加到申请的终端用户凭据进行身份验证的能力，例如 JWT。
• ASM 的集中控制架构使企业的平安团队能够构建、治理和部署实用于整个企业的安全策略。

将身份验证和受权零碎作为服务部署在网格中，如同网格中的其余服务一样，这些平安零碎从网格中自身也能够失去平安保障，包含传输中的加密、身份辨认、策略执行点、终端用户凭据的身份验证和受权等。策略管制面定义并治理多种类型的认证策略；网格管制面赋予网格中工作负载身份，并主动轮转证书；数据面的 Sidecar 代码执行策略。图中用户配置规定只容许交易服务发动调用订单服务，回绝购物车服务调用订单服务。

因为服务网格 ASM 是管制立体托管，反对管控多个数据面集群，流量治理 CR 存在管制立体，反对用户通过管制立体的 KubeAPI 操作治理规定。在服务网格新版本中，为了：

1、反对用户在非托管模式下的操作习惯，可能在数据面 Kubernetes 集群中读写 Istio 资源；

2、反对 Helm 常用命令工具；

3、兼容其余开源软件在单集群 addon 模式下的 API 操作，阿里云服务网格 ASM 实现了反对数据面集群 Kube API 拜访 Istio 资源。两者同时对外提供，用户能够依据理论场景按需应用。image.gif

ASM 兼容社区规范，提供了管制立体的平滑降级，那么数据面的降级能够降级两种形式：滚动降级和热降级能力，对于滚动降级能力须要设置降级 Strategy 为 RollingUpdate，注入 Sidecar 的 Pod 在公布时，Envoy 镜像会主动降级到新版本。图中次要介绍第二种形式阿里云服务网格 ASM 联合 OpenKruise 我的项目实现的热降级性能，在降级数据立体时不会中断服务，使数据立体在利用无感知的状况下实现降级。利用公布和更新主动生成 SidecarSet 配置，更新 SidecarSet 配置实现数据面的降级，目前这项能力在新版本灰度中。

服务网格 ASM 配合阿里云利用高可用服务 AHAS 能够对部署在服务网格内的利用进行流量管制，目前曾经反对单机限流，集群限流，自适应限流。同时服务网格 ASM 也原生反对 Istio 的全局限流和本地限流，全局限流应用全局 gRPC 服务为整个网格提供速率限度，本地限流用于限度每个服务实例的申请速率，本地限流能够与全局限流联合应用。

服务网格 ASM 也反对通过 MCP over XDS 协定对接微服务引擎 MSE 的注册核心，同步服务信息到网格。MSE 的 Nacos 原生反对 MCP 协定，用户只须要在创立或更新 ASM 实例时开启 Nacos 注册核心对接性能，实现注册核心的服务同步到服务网格，能够很不便地反对 Dubbo、Spring Cloud 服务的网格化，用户侧无需做任何业务代码批改。

最初分享几个客户案例，客户如何应用服务网格 ASM 缩短服务网格技术落地周期、加重异样排错老本，节俭管制面资源老本。

1、东风日产随着业务的倒退，早前打造的「十二生肖」（十二套残缺的测试环境）已无奈满足泛滥并发需要，甚至须要摇号调配环境。通过引入阿里云服务网格 ASM，构建了基于流量治理的「有限生肖」零碎，满足了主动按需提供环境的诉求。基于 ASM 提供的免运维、易降级以及产品丰盛反对能力，让产研团队集中享受 ServiceMesh 带来的价值。

2、职优你为了应答业务的全球化扩张与一体化经营，基于阿里云服务网格 ASM 和容器服务 ACK 将业务利用跨区域部署，通过服务按地区就近拜访的策略，优化了客户拜访体验，无效升高业务拜访时延，晋升业务响应速度。

3、商米科技引入阿里云服务网格 ASM，构建智能的数字化商业智能 POS 软硬件一体化零碎解决方案，应用服务网格 ASM 解决 gRPC 服务负载平衡、链路追踪以及流量对立治理等外围问题。

原文链接
本文为阿里云原创内容，未经容许不得转载。