Dubbo3.0｜阿里巴巴服务框架三位一体的选择与实践

Dubbo3.0｜阿里巴巴服务框架三位一体的选择与实践

作者|泮圣伟、董建凯 服务框架就像铁路的铁轨一样，是互通的基础，只有解决了服务框架的互通，才有可能完成更高层的业务互通，所以用相同的标准统一，合二为一并共建新一代的服务框架是必然趋势。 Dubbo3.0 是 Dubbo2.0 与 HSF 融合而来，是阿里经济体面向内部业务、商业化、开源的唯一标准服务框架。

阿里巴巴服务框架的选择与实践

Dubbo 和 HSF 在阿里巴巴的实践

下一代微服务的挑战和机遇

然而，业务的发展和框架自身的迭代使得两个框架从协议层的简单兼容已经无法满足需要。随着云计算的不断发展和云原生理念的广泛传播，微服务的发展有着以下趋势：

K8s 成为资源调度的事实标准，Service Mesh 从提出到发展至今已经逐渐被越来越多用户所接受。屏蔽底层基础设施成为软件架构的一个核心演进目标，无论是阿里巴巴还是其他企业用户，所面临的问题都已经从是否上云变为如何平滑稳定地低成本迁移上云。 由于上云路径的多样以及由现有架构迁移至云原生架构的过渡态存在，部署应用的设施灵活异变，云上的微服务也呈现出多元化的趋势。跨语言、跨厂商、跨环境的调用必然会催生基于开放标准的统一协议和框架，以满足互通需求。 端上对后台服务的访问呈爆炸性的趋势增长，应用的规模和整个微服务体系的规模都随之增长。

这些趋势也给 HSF 和 Dubbo 带来了新的挑战。

HSF 和 Dubbo 面临的挑战

微服务框架是基础组件，大部分公司在早期选型或业务发展到一定规模的时候都需要确定使用某一个框架。而一个稳定高效的自研框架通常需要较长时间的迭代来打磨优化。所以大部分公司初期都会倾向于使用开源组件。对阿里云而言，这就带来了一个问题：内部使用的是 HSF 框架，而云上的用户大部分都是使用的开源 Dubbo 框架，两种框架在协议、内部模块抽象、编程接口和功能支持上都存在差异。 如何能让使用了 HSF 的阿里集团内部组件的最优实践和前沿技术更简单直接地输出到云上，这是每一个做技术商业化的同学都会遇到和必须解决的问题。其实我们也有过一些探索，云上微服务最早推的是 HSF 框架，闭源组件在云上输出的时候，对于许多用户而言，遇到问题后无从排查，整个服务框架对于他们来说是一个黑盒的组件。我们发现这并不是一个很好的产品化方向，在云上输出的时候，我们必须选择拥抱开源的方式，主推 Dubbo 与 Spring Cloud 框架。 同时在集团内也因为同时存在 HSF 与 Dubbo 框架而导致的不少问题。原有部门或公司的技术栈如何更快地融入到现有技术体系是一个绕不开的问题。一个典型的例子就是 2019 年加入阿里巴巴的考拉。考拉之前一直使用 Dubbo 作为微服务框架，基于 Dubbo 构建了大规模的微服务应用，迁移的成本高，风险也大。需要集团和考拉的基础架构部门耗费较长的时间进行迁移前调研、方案设计，确保基本可行后再开始改动。从分批灰度上线，再到最终全量上线。这种换血式的改动不仅需要耗费大量人力，时间跨度也很长，会影响到业务的发展和稳定性。同时由于历史原因，集团内部始终存在着一定数量的 Dubbo 用户。为了更好的服务这部分用户，HSF 框架对 Dubbo 进行了协议层和 API 层的兼容。但这种兼容仅限于互通，随着 Dubbo 开源社区的多年发展，这种基础的兼容在容灾、性能和可迭代性方面，都有着较大的劣势，同时很难对齐 Dubbo 的服务治理体系。在稳定性方面也存在风险，更无法享受到集团技术发展和 Dubbo 社区演进的技术红利。 产生这些问题的根本原因是闭源的 HSF 无法直接用于广大云上用户和外部其他用户，而开源产品对闭源产品的挑战会随着开源和云的不断发展愈演愈烈。越早解决这个问题，阿里巴巴和外部企业用户的云原生迁移成本越低，产生的价值也就越大。 因此，HSF 和 Dubbo 的融合是大势所趋。为了能更好的服务内外用户，也为了两个框架更好发展，Dubbo3.0 和以 Dubbo3.0 为内核适配集团内基础架构生态的 HSF3.0 应运而生。

三位一体战略下服务框架的最终选择 Dubbo3.0

Dubbo3.0 在原有功能集与 API 完全兼容的前提下，同时具备了以下几大面临云原生挑战下的新特性

Dubbo 3.0 支持全新的服务发现模型，Dubbo 3.0 尝试从应用模型入手，优化存储结构，对齐云原生主流设计模型，避免在模型上带来的互通问题。新模型在数据组织上高度压缩，能有效提高性能和集群的可伸缩性。 Dubbo 3.0 提出了下一代 RPC 协议 —— Triple。这是一个基于 HTTP/2 设计的完全兼容 gRPC 协议的开放性新协议，由于是基于 HTTP/2 设计的，具有极高的网关友好型和穿透性；完全兼容 gRPC 协议是的天然在多语言互通方面上具有优势。 Dubbo 3.0 面向云原生流量治理，提出了一套能够覆盖传统 SDK 部署、Service Mesh 化部署、VM 虚拟机部署、Container 容器部署等场景的统一治理规则，支持一份规则治理大部分场景，大大降低流量治理治理成本，使得异构体系下全局流量治理变得可能。 Dubbo 3.0 将提供接入 Service Mesh 的解决方案，面向 Mesh 场景，Dubbo 3.0 提出了两种接入方式，一种是 Thin SDK 模式，部署模型和当前 Service Mesh 主流部署场景完全一样，而 Dubbo 将进行瘦身，屏蔽掉与 Mesh 相同的治理功能，仅保留核心的 RPC 能力；第二种是 Proxyless 模式，Dubbo 将接替 Sidecar 的工作职责，主动与控制面进行通信，基于 Dubbo 3.0 的统一治理规则应用云原生流量治理功能。

服务框架在阿里云商业化方向上的演进思路

服务治理无缝支持 Dubbo3.0

如何将一个 HSF 应用无缝升级成 Dubbo 3.0 应用

三位一体是阿里巴巴“自研”、“开源”、“商业化”采用统一技术体系，在此技术方向下，Dubbo3.0 的设计与落地实现了 HSF/Dubbo 的技术统一，在集团内也正在快速推广落地中。同时 EDAS Container 4.x版本，正是 Dubbo3.0 的商业化输出形式之一。 如果您的应用在 EDAS 或者 SAE 上，使用的是 HSF + EDAS Container 这一套的架构，用户只需升级容器版本至 4.x 就可以便捷的将 HSF 应用升级为 Dubbo 3.0 应用。升级之后，HSF 应用可沿用原有开发方式，还可以使用 EDAS/SAE 为 Dubbo 应用提供的更加完善的服务治理功能。同时您的HSF应用也将会具备 Dubbo 3.0 的各种新特性、应用级服务发现、Triple 协议等。

Java 微服务 Proxyless Mesh 架构

在异构微服务场景下，随着 ServiceMesh 方案的普及，原先微服务应用如何在 Service Mesh 微服务架构中与其他 Mesh 节点进行互通以及治理能力对齐成了困扰用户的问题。开源 Spring Cloud / Dubbo 框架在MSE微服务引擎上无需增加 Envoy，同时也无需修改任何一行代码就可以与 Mesh 架构互通。

Dubbo3.0 的大规模生产实践案例

Dubbo3.0 在落地的过程中，我们具备许多大规模的实践，考拉、钉钉等。 下面以钉钉为例介绍

背景

为了拥抱容器化、享受云上的福利，钉钉文档在 2020 年启动了上云战役。目前已有 50% 的流量，跑在公有云集群。

业务挑战

落地方案

1、双集群

2、单元化路由

弹内服务，对到来的 HSF 请求进行拦截。如果解析出需要将请求路由到云上，则对云上服务发起一次 triple 调用。否则，继续将请求交给弹内的服务。

3、下游依赖

4、服务治理

服务互通完成了之后，就是开始看如何进行服务治理了。包括服务查询、服务测试、服务压测、服务限流、服务监控等。

4.1 MSE

服务查询、服务测试、服务路由等，都是通过接入 MSE 完成的。这里要特别提一下 MSE 的服务测试。业务同学最开始是在本机 curl hsf 的 端口进行测试，非常麻烦，但是在接入 MSE 服务治理之后，就可以直接用 MSE 平台的服务测试功能。服务测试即为用户提供一个云上私网 Postman ，让用户能够轻松调用自己的服务。用户无需感知云上复杂的网络拓扑结构，无需关系服务的协议，无需自建测试工具，只需要通过控制台即可实现服务调用。支持 Dubbo 3.0 框架，以及 Dubbo 3.0 主流的 Triple 协议。

4.2 其他

总结

钉钉文档借助三位一体的红利实现三个月内快速上云，通过云产品方式产品化标准化地解决了上云过程中遇到的问题，借助 Dubbo3.0 的云原生特性，以及 MSE 服务治理能力的快速接入与支持，快速完成服务框架从互通到治理的落地。

尾

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。