电子商务|阿里巴巴服务网格技术三位一体战略背后的思考与实践( 二 ) 广州市

拥抱服务网格开源技术
阿里云内部很早就开始调研并实践 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% 的提升。