简介：本文分享阿里巴巴服务网格技术三合一战略背后的思考与实践。部分功能请点击下方查看详情~作者：宗权、曾宇阿里巴巴三位一体战略阿里云很早就提出了开源、自研、商业化三位一体的战略。我先说说我对它的理解。多年的软件开发经验告诉我们，开发一款优秀的软件有几个关键要素：沟通反馈实践在软件开发过程中，我们不能闭门造车，不能随意“创造”业务场景需求。业务场景和产品功能需要细化。开源为我们提供了联合创新的平台。基于这个平台，大家可以共同定义一些规范和标准。不同厂商遵循相应的标准，不存在客户被锁定的风险，可以不断迁移，总能找到最好的厂商，把生意放在上面，用最简单、最方便、最经济的方式.经营自己的事业。很多客户在选择阿里云服务网格的时候，有一个很重要的标准：是否兼容社区Istio。因为客户担心被锁定，所以强烈依赖阿里云；说到自研，可能有同学会问开源和自研是否矛盾，答案是否定的。因为，我们这里说的自研，其实是基于开源的自研，而不是放弃开源的版本，重新造一个轮子。自研意味着我们需要对开源产品有足够深入的了解：掌握所有源代码；有能力修改每一行代码。当然，自研也意味着我们自己的业务可能有特定的、独特的需求场景。标准化场景。基于我们自研和对开源产品的深入把控和理解，我们将满足一般客户场景需求的功能迁移到云端，打包成云产品，让云端的客户可以使用出来的盒子。这是商业的初衷。回到阿里集团内部，开源、自研、商业其实是一个技术飞轮。对于阿里的技术同学来说，一年一度的双11是一场“盛宴”。为了给顾客提供顺畅的购物体验，为商家提供更多元化的让利活动，阿里电商平台对效率、可靠性、规模的要求在双11的带动下成倍增长，激发了技术人的潜力。阿里中间件作为核心基础技术之一，每年双11也会迎来一次全面的技术演进和升级，阿里公开推出了Dubbo、RocketMQ、Nacos、Seata等众多知名开源项目源码社区，鼓励开发者共同构建中间件生态，包括ServiceMesh相关技术。拥抱ServiceMesh开源技术阿里云长期以来一直在研究和实践ServiceMesh技术。2018年，Istio正式发布1.0版本，进入大众视野。在这个前期，阿里巴巴已经开始参与相关生态开源产品的贡献。阿里云在微服务生态领域也有一些开源的面向服务的框架，比如Dubbo、SpringCloudAlibaba。可以说，在微服务领域，由于电商这个大型实验平台，阿里云在这方面是妥妥的“技术专家”，我们将进行横向功能对比，比较优劣势Sidecar模型和原始模型；在此过程中，我们也积极参与Istio微服务相关生态项目的开源贡献；比如Envoy、DubboFilter、RocketMQFilter、NacosMcpfunction、SpringCloudAlibaba、Sentinel等。目前流行各种服务框架，如何基于不同的框架开发互操作的服务？服务框架就像铁路的铁轨，是互通的基础。只有解决了服务框架的互通，才有可能完成更高层次的业务互通。所以，同一个标准统一起来，两者结合起来构建新一代的服务。框架是必然趋势。Dubbo和HSF都是阿里巴巴内部使用的微服务RPC框架。这些框架在阿里巴巴业务不断迭代发展的过程中，提供了坚实的底层微服务能力支持，保障了一场又一场的双十一大促。随着云原生浪潮、整体资源成本优化、DevOps等背景，原有微服务框架Dubbo和HSF的一些不足逐渐暴露出来，比如多语言支持、配置和代码逻辑分离等。SDK版本需要推动业务方，收购的业务使用不同的框架进行互通。阿里巴巴集团内部的一些业务已经开始尝试使用服务网格技术改造底层的微服务框架。在对Dubbo框架进行网格化的过程中，阿里云服务网格团队贡献了EnvoyDubboFilter，实现了原有Dubbo业务的网格化。,获取服务网格带来的新的增量价值。另一方面，Dubbo社区本身也在向云原生领域迭代。Dubbo从Dubbo2.7.8开始讨论Dubbo的云原生演进计划。为了更好的适应云原生场景（基础设施的变化，Kubernetes已经成为资源调度编排的事实标准），Dubbo团队目前正在对Dubbo2.0向Dubbo3.0做技术演进，并提出ProxylessMesh的设计.随着业务逐渐上云，由于上云路径的多样性以及从现有架构到云原生架构的转变，部署应用的设施灵活多变，云上微服务也呈现出向云化的趋势。多样化。跨语言、跨厂商、跨环境的调用，必然会产生基于开放标准的统一协议和框架，以满足互操作性需求。这些正式服务网格擅长的场景，给了服务网格很好的发挥空间；目前，Dubbo3.0社区版已经发布。核心变化包括：应用级服务发现。Dubbo2.0协议已经演进为基于gPRC的Triple协议。没有Sidecar的ProxylessMeshMesh不是一蹴而就的。对于原有存量业务和类似业务上云，有一个中间过渡阶段，传统微服务框架，如：Dubbo、SpringCloud等存量业务使用Nacos、Eureka、Zookeeper服务注册中心，我们需要做兼容适配它;基于Istio控制面开放的McpOverXDS协议，在Nacos中率先实现了该协议的支持，允许Istiod直接连接到Nacos注册中心。开源产品往往不能直接用于大规模生产环境，需要进行一些适配和调优，以及对产品化能力的一些封装；例如：Intel的mTLS加速方案。Intel提交了Envoy的Upstream的实现，但是Istiod还没有支持。作为云产品，我们希望为客户提供开箱即用的能力。服务网格ASM基于Intel开源的mTLS加速方案，实现了对控制面Istiod的扩展支持，同时由于mTLS加速方案依赖于底层资源的实际CPU。类型（icelake），ASM已经根据用户业务的实际部署开启和关闭了自适应加速功能。开启multiBuffer加速功能后，使用阿里云g7代ecs作为node节点，QPS提升近80%。说到ServiceMesh，一个经常被提起的话题：“它和Dapr有什么区别？”Dapr采用Sidecar架构，与应用程序作为一个单独的进程运行，包括服务调用、网络安全、分布式追踪等功能。.这常常引出一个问题：Dapr与Istio等服务网格解决方案相比如何？虽然Dapr和服务网格确实有一些重叠的功能，但与专注于网络问题的服务网格不同，Dapr专注于提供构建块，使开发人员更容易将应用程序构建为微服务。Dapr以开发人员为中心，而服务网格以基础设施为中心。此外，Dapr不提供路由或分流等流控相关功能。当然，两者可以一起部署。此时，Dapr和服务网格的sidecar都运行在应用环境中。在阿里服务网格的实现和实践前面，我们可以看到阿里巴巴已经开源了一些微服务生态的产品。其实这些产品最初都是基于内部业务场景，基于这些内部业务场景的孵化和规模化业务。检查，内部感觉外部客户有类似的需求，所以这些内部实现都是开源的。IstioMesh也是如此。集团内部业务很早就开始了Mesh的业务探索。我们详细看一下：从整体架构图可以看出，阿里集团提供了一套控制台供Mesh用户操作。从应用的角度，集成CICD、权限管理、安全生产、SRE运维系统等其他平台，应用接入Mesh后提供统一的Portal，让用户基于DevOps理念，通过Mesh方式提供应用服务治理、全链路灰度、安全生产能力，达到应用拥有者自救自愈运维的效果。其中，Mesh的核心能力支持Dubbo、MetaQ（RocketMQ）、LWP等RPC协议，扩展实现全链路染色、路由策略、插件市场等Mesh能力。同时，阿里集团还支持通过OpenAPI和KubernetesAPI提供第三方系统集成的能力。阿里集团在社区Istio架构的基础上，与内部中间件（Diamond、ConfigServer）进行了深度集成，兼容原有预留业务的使用方式，让业务与Mesh无缝对接，这就是为什么我们考虑一些Mesh业务如果有使用Nacos的需求，在ASM产品层面支持Nacos等多注册中心场景；同时抽象运维面，通过UI控制台实现服务流量治理规则（virtualservice、destinationrule等）的配置。Pod级Sidecar的集成可以启用、禁用和热升级。通过在集团内部集成Prometheus、Grafana和报警ARMS，实现微服务的可观察和监控。阿里巴巴集团服务网格的演进路径阿里巴巴集团服务网格的演进分为三个阶段：无入侵局部扩容、无入侵全面扩容、云原生终态。目前，集群业务的网格化处于第二阶段。第一阶段：现有服务的Meshization中有一个过渡阶段，需要保证这个过渡阶段是相对非侵入性的，让业务开发者感知不到；这是我们需要采用非侵入式解决方案的背景和前提；并且我们需要用Mesh来覆盖现有的一些微服务治理能力，同时提供Mesh的增量价值；第二阶段：综合扩容，在解决扩容带来的资源开销和性能问题的同时，通过Sidecarcrd实现服务配置的懒加载，实现配置隔离，通过对Metrics的优化剪枝，减少sidecar内存开销，同时通过优化Dubbo/HSFFilter实现惰性编解码，提升数据面处理性能，降低延迟。随着内部业务Dubbo2.0/HSF向Dubbo3.0演进，最终演进为云原生终态方案。第三阶段：云原生终态。随着基础设施向Kubernetes演进，在云原生场景下，服务发现和服务治理能力降低。通过Mesh可以将业务逻辑和服务治理解耦，实现配置和代码逻辑的分离。为了更好的DevOps，享受Mesh带来的丰富的、可扩展的流量调度能力和可观察性。Dubbo/HSFRPC支持多种序列化方式，而Mesh对一些序列化方式没有提供友好的支持，比如Java序列化。所以Mesh第一阶段，对于Java序列化，Sidecar不编解码，采用Passthrough流量透传；对于Hessian2序列化，Mesh实现了完整的编解码支持，基于性能考虑实现了惰性Codec。基于此，我们可以对这类流量进行流量标记（着色），通过扩展VirtualService实现标签路由和Fallback能力。也可以实现一些特定的业务场景，比如金丝雀发布、全链路灰度等场景；内部业务MeshSDK层将逐步升级为Dubbo3.0SDK。在启用Mesh的场景下，Dubbo3.0SDK只提供RPC，其他能力对应ThinSDK模式。Mesh之后，sidecar协议支持更加友好，一定程度上降低了资源开销成本；当sidecar出现故障时，可快速读取并切换回FatSDK模式，业务无感知；对于集群内部业务，流量调度有一些复杂的场景，尤其是一些规模较大的业务。比如多机房、多地域部署，也有单地域多版本、多环境的路由，涉及到不同维度的路由和后端集群选择。这些维度可能包括：区域路由、机房路由单元化路由环境路由多版本路由组电子商务场景尤为典型。基于此，Istio内部扩展通过引入新的CRD：RouteChain、TrafficLable以及VirtualService的扩展，实现了标记流量和根据标记路由的能力。商业产品阿里云服务网格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在控制面和控制面的打磨，可以为运行在异构计算基础设施上的服务提供统一的网格治理能力（AnywhereServiceMesh），从入口网关到数据面Sidecar注入，支持容器服务ACK、Serverlesskubernetes、边缘集群和外部注册的Kubernetes集群，以及ECS虚拟机等各种基础设施。服务网格ASM的功能设计是基于ASM的流量标记和标签路由实现全链路灰度化。在微服务软件架构下，在新的业务功能上线前，搭建一套完整的测试系统进行验证，是相当费时费力的工作。随着拆分微服务数量的不断增加，难度越来越大。基于“流量标记”和“按标记路由”能力，是一个通用的解决方案，可以更好地解决测试环境治理、在线全链路灰度发布等相关问题。并且基于服务网格技术，可以独立于开发语言。该方案适用于不同的7层协议。目前的服务网格ASM已经支持HTTP/gRpc和Dubbo协议。ASM中引入了一个新的TrafficLabelCRD，定义Sidecar需要的透传流量标签从哪里获取，逻辑上隔离全链路流量控制，并根据标记对流量进行标记（着色）和路由。通过服务网络GridASM不需要每个技术研发人员部署一套完整的环境，实现多环境治理，大大降低研发成本。服务网格ASM支持实施金丝雀发布。发布是整个功能在线更新的最后一个环节。一些在研发过程中积累的问题，只会在最后的发布环节才会被触发。同时，出版本身也是一个复杂的过程。在发布过程中，经常容易出现一些误操作或漏键操作。金丝雀发布配置灵活，策略可定制。可根据流量或具体内容（如不同账号、不同参数）进行灰度化，出现问题不会影响全网用户。图中为应用打上了环境标签，通过TrafficLabel将http-header:user-id%100==20等用户流量用灰色标签标注。同时标签流量路由规则通过VirtualService下发，所以userId为120的用户流量会被阻断。路由到grey灰度环境，将userId为121的用户流量路由到normal正常环境。服务网格ASM实现的金丝雀发布支持基于流量百分比和请求特征（如http头、方法参数等）的路由，与服务网格入口网关完美集成，支持HTTP/gRPC/Dubbo协议。除了使用流量标记和标签路由实现全链路灰度和金丝雀发布外，服务网格ASM还支持结合KubeVela进行渐进式发布。KubeVela是一个开箱即用的现代应用程序交付和管理平台，可简化混合环境的应用程序交付过程；同时，足够灵活，随时应对持续快速的业务变化带来的迭代压力。KubeVela之后的应用交付模型，OpenApplicationModel(OAM)，在设计和实现上是一个高度可扩展的模型，具有完全以应用为中心、可编程交付工作流、独立于基础设施的特点。阿里云服务网格ASM结合KubeVela支持复杂的金丝雀发布流程，可以将KubeVela定义的相关配置转化为流量治理规则下发到数据面。阿里云服务网格ASM实现了零信任安全能力。在微服务网络中使用HTTP通信的交互是不安全的。一旦内部服务被攻破，攻击者就可以利用该机器作为跳板攻击内网。ServiceMeshASM可以减少云原生环境下的攻击区域，提供零信任应用网络所需的基础框架。通过ASM管理服务到服务的安全性，确保服务网格的端到端加密、服务级别身份验证和细粒度授权策略。与应用代码中内置的传统安全机制相比，ASM零信任安全体系具有以下优势：ASMsidecaragent的策略生命周期与应用程序保持独立，因此可以更轻松地管理这些sidecaragent。ASM支持策略的动态配置，更容易更新策略，更新立即生效，无需重新部署应用。ASM提供了对附加到请求的最终用户凭据进行身份验证的能力，例如JWT。ASM的集中控制架构使企业的安全团队能够构建、管理和部署企业范围的安全策略。将身份验证和授权系统部署为网格中的服务。与网格中的其他服务一样，这些安全系统也可以从网格自身获得安全保障，包括传输中的加密、标识、策略执行点、最终用户凭证的认证和授权等。策略控制平面定义和管理多个身份验证策略的类型；网格控制平面为网格中的工作负载分配身份并自动轮换证书；数据平面的sidecar代码执行策略。图中的用户配置规则只允许交易服务调用订单服务，拒绝购物车服务调用订单服务。由于服务网格ASM是控制面托管，支持多个数据面集群的管控，而流量治理CR有控制面，允许用户通过控制面的KubeAPI操作治理规则。在新版本的服务网格中，为了：1.支持用户在非托管模式下的操作习惯，能够在数据平面上读写Kubernetes集群中的Istio资源；2.支持Helm常用命令工具；3、兼容其他开源软件对于单集群addon模式下的API操作，阿里云ServiceGridASM支持数据面集群KubeAPI访问Istio资源。两者同时对外提供，用户可根据实际场景按需使用。ASM兼容社区标准，提供控制平面的平滑升级。数据平面的升级有两种方式：滚动升级和热升级。关于滚动升级能力，需要将升级策略设置为RollingUpdate。当注入Sidecar的Pod发布时，Envoy镜像会自动升级到新版本。图中主要介绍第二种方式，阿里云ServiceGridASM结合OpenKruise项目实现的热升级功能，在升级数据平面时不会中断服务，实现数据平面无应用感知的升级。应用发布和更新自动生成SidecarSet配置，并更新SidecarSet配置完成数据平面的升级。目前，该能力在新版本灰度中。服务网格ASM配合阿里云应用高可用服务AHAS对服务网格中部署的应用进行流量控制。目前支持单机限流、集群限流、自适应限流。同时服务网格ASM也原生支持Istio的全局和局部限流。全局限流使用全局gRPC服务为整个网格提供速率限制。本地限流用于限制每个服务实例的请求速率。本地限流可以和全局限流结合使用。服务网格ASM还支持通过MCPoverXDS协议连接到微服务引擎MSE的注册中心，将服务信息同步到网格中。MSE的Nacos原生支持MCP协议。用户只需要在创建或更新ASM实例时开启Nacos注册中心对接功能，即可将注册中心的服务同步到服务网格中，可以轻松支持Dubbo和SpringCloud服务的网格化，用户端无需修改任何业务代码。最后分享几个客户案例，客户如何使用服务网格ASM来缩短服务网格技术的实施周期，降低异常排查成本，节省控制面资源成本。1、随着东风日产业务的发展，早先创建的“十二生肖”（十二个完整的测试环境）已经不能满足很多并发需求，甚至需要一个摇号分配环境。通过引入阿里云服务网格ASM，构建了基于流量管理的“无限生肖”系统，满足自动按需提供环境的需求。基于ASM提供的免费运维、轻松升级和丰富的产品支持能力，产研团队可以享受到ServiceMesh带来的价值。2.为应对业务的全球化扩张和一体化运营，您基于阿里云服务网格ASM和容器服务ACK跨区域部署业务应用，通过按需访问服务的策略优化客户访问体验到最近的地区。有效降低服务访问延迟，提高服务响应速度。3、商米科技引入阿里云服务网格ASM构建智能数字商业智能POS软硬件一体化系统解决方案，利用服务网格ASM解决gRPC服务负载均衡、链路跟踪、统一流量管理等核心问题。本文分享了阿里服务网格技术三合一战略背后的思考和实践，以及阿里云服务网格ASM的部分产品功能，包括最近发布的一些功能，如Istio资源历史版本管理、数据平面支持等clusterKubernetesAPI访问Istio资源，支持跨区域故障转移和跨区域流量分发，支持控制面日志收集和日志告警，支持基于KubeVela的渐进式发布，更多关于流量管理、可观察性、零信任安全、解决方案等产品功能，请点击阅读原文访问阿里云服务网格ASM产品文档。如果您对服务网格ASM感兴趣，欢迎来到钉钉扫描下方二维码或搜索群号（30421250）加入服务网格ASM用户交流群，共同探索服务网格技术。点此查看更多服务网格ASM相关信息~版权声明：本文内容由阿里云实名注册用户投稿，版权归原作者所有。阿里云开发者社区不拥有自己的版权，也不承担相应的法律责任。具体规则请参考《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如发现本社区涉嫌抄袭内容，请填写侵权投诉表进行举报，一经查实，本社区将立即删除涉嫌侵权内容。
