关于阿里云开发者:Dubbo-和-HSF-在阿里巴巴的实践携手走向下一代云原生微服务

8次阅读

共计 8335 个字符，预计需要花费 21 分钟才能阅读完成。

简介：HSF 和 Dubbo 的交融是大势所趋。为了能更好的服务内外用户，也为了两个框架更好倒退，Dubbo 3.0 和以 Dubbo 3.0 为内核适配团体内基础架构生态的 HSF 3 应运而生。

作者 | 郭浩

Dubbo 和 HSF 都是阿里巴巴目前在应用的微服务 RPC 框架。HSF 在阿里巴巴应用更多，承接了外部从单体利用到微服务的架构演进，撑持了阿里历年双十一的安稳运行；Dubbo 则在 2011 年开源后，迅速成为业界广受欢迎的微服务框架产品，在国内外均有着广泛应用。
自 2008 年 5 月公布第一个版本 1.1 后，经验数年迭代，HSF 从一个根底的 RPC 框架逐步演变成为日撑持十万亿级别调用的易于扩大的微服务框架。外部场景中，用户既能够抉择大量配置轻松接入微服务体系，获取高性能的稳固服务调用。也能够依照本身业务需要，对 HSF 进行扩大，获取整条链路的能力加强。

Dubbo 我的项目诞生于 2008 年，起初只在一个阿里外部的零碎应用；2011 年，阿里 B2B 决定将整个我的项目开源，仅用了一年工夫就播种了来自不同行业的少量用户；2014 年，因为外部团队调整，Dubbo 暂停更新；2017 年 9 月，Dubbo 3 重启开源，在 2019 年 5 月由 Apache 孵化毕业，成为第二个由阿里巴巴募捐至 Apache 毕业的我的项目。

2008 年的时候，团体外部淘系次要应用的服务框架是 HSF，而 B2B 应用的则是 Dubbo。二者独立，各行其道，彼此不通。随着业务飞速发展，跨语言、跨平台、跨框架的需要日益显著，不同业务间彼此互联互通的呼声越来越高，而且很快演变成为简直整个团体的需要。即淘系能够调用 B2B 的服务，反之亦然。

服务框架就像铁路的铁轨一样，是互通的根底，只有解决了服务框架的互通，才有可能实现更高层的业务互通，所以用雷同的规范对立，共建新一代的服务框架是必然趋势。也就是最终的框架须要同时兼容 HSF1.x 和 Dubbo (包含 1.x 和 2.x) 的协定。对于团体内的需要而言，稳固和性能是外围，因而，过后选型了在电商这种高并发场景久经考验的 HSF 做为新一代服务框架外围。随后，HSF 推出了 2.0 的版本，并针对 HSF 之前版本的次要问题进行重构革新，升高了保护老本，进一步提高了稳定性和性能。HSF 2.0 解决了通信协定反对不通明，序列化协定反对不通明等框架扩展性问题。基于 HSF 2.0 的 Java 版本，团体内也演进出了 CPP/NodeJs/PHP 等多语言的客户端。

因为兼容了 Dubbo 的协定，原有的 Dubbo 用户能够平滑地迁徙到新版本上，所以 HSF 推出后很快就在团体全面铺开，部署的 server 数量达到数十万，根本实现了阿里巴巴外部微服务框架的对立，并经验了多年双十一零点流量洪峰的验证。

然而，业务的倒退和框架本身的迭代使得两个框架从协定层的简略兼容曾经无奈满足需要。随着云计算的一直倒退和云原生理念的广泛传播，微服务的倒退有着以下趋势：

1、K8s 成为资源调度的事实标准，Service Mesh 从提出到倒退至今曾经逐步被越来越多用户所承受。屏蔽底层基础设施成为软件架构的一个外围演进指标，无论是阿里巴巴还是其余企业用户，所面临的问题都曾经从是否上云变为如何平滑稳固地低成本迁徙上云。

2、因为上云门路的多样以及由现有架构迁徙至云原生架构的过渡态存在，部署利用的设施灵便异变，云上的微服务也呈现出多元化的趋势。跨语言、跨厂商、跨环境的调用必然会催生基于凋谢规范的对立协定和框架，以满足互通需要。

3、端上对后盾服务的拜访呈爆炸性的趋势增长，利用的规模和整个微服务体系的规模都随之增长。

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

第一，上云对外部闭源组件带来了冲击。微服务框架是根底组件，大部分公司在晚期选型或业务倒退到肯定规模的时候都须要确定应用某一个框架。而一个稳固高效的自研框架通常须要较长时间的迭代来打磨优化。所以，大部分公司初期都会偏向于应用开源组件。对阿里云而言，这就带来了一个问题：外部应用的是 HSF 框架，而云上的用户大部分都是应用的开源 Dubbo 框架，两种框架在协定、外部模块形象、编程接口和性能反对上都存在差别。如何能让应用了 HSF 的阿里团体外部组件的最优实际和前沿技术更简略间接地输入到云上，这是每一个做技术商业化的同学都会遇到和必须解决的问题。

第二，原有部门或公司的技术栈如何更快地融入到现有技术体系是一个绕不开的问题。一个典型的例子就是 2019 年退出阿里巴巴的考拉。考拉之前始终应用 Dubbo 作为微服务框架，基于 Dubbo 构建了大规模的微服务利用，迁徙的老本高，危险也大。须要团体和考拉的基础架构部门消耗较长的工夫进行迁徙前调研、方案设计，确保根本可行后再开始改变。从分批灰度上线，再到最终全量上线。这种换血式的改变不仅须要消耗大量人力，时间跨度也很长，会影响到业务的倒退和稳定性。

第三，因为历史起因，团体外部始终存在着肯定数量的 Dubbo 用户。为了更好的服务这部分用户，HSF 框架对 Dubbo 进行了协定层和 API 层的兼容。但这种兼容仅限于互通，随着 Dubbo 开源社区的多年倒退，这种根底的兼容在容灾、性能和可迭代性方面，都有着较大的劣势，同时很难对齐 Dubbo 的服务治理体系。在稳定性方面也存在危险，更无奈享受到团体技术倒退和 Dubbo 社区演进的技术红利。

产生这些问题的根本原因是闭源的 HSF 无奈间接用于宽广云上用户和内部其余用户，而开源产品对闭源产品的挑战会随着开源和云的一直倒退愈演愈烈。越早解决这个问题，阿里巴巴和内部企业用户的云原生迁徙老本越低，产生的价值也就越大。

最简略间接的形式是将 HSF 也开源进来。但这又会面临两个新问题。第一，Dubbo 是阿里较早开源的明星产品，如果 HSF 也开源，这两个同类框架的关系和实用场景如何划分，不仅内部用户会有纳闷，反复开源也不利于品牌建设。第二，国内外现有的 Dubbo 用户如果想上阿里云，则须要应用基于 HSF 的现有解决方案，须要破费微小精力将所有用到 Dubbo 的利用迁徙到 HSF，老本和稳定性都是不得不思考的问题。以上两点起因阐明目前曾经不是开源 HSF 的最好机会。

既然 HSF 不能走进来，那剩下的解决形式就是让 Dubbo 走进来。外部采纳外围交融的形式，基于 Dubbo 内核从新构建 HSF 框架。

品牌建设上，交融能够使 Dubbo 现有的宽泛影响力得以继续倒退，Dubbo 在团体内大规模落地后，会产生良好的原厂品牌示范效应，内部用户也会有更多的信念在进行微服务框架选型时抉择 Dubbo。同时，目前曾经应用 Dubbo 的用户也有更充沛的理由一直追寻版本演进，享受阿里巴巴开源带来的技术红利。

工程实际上，应用 Dubbo 重构 HSF 这种从外部从新对立的可行性更高，迁徙的复杂度可控，可能逐渐地有序实现。外部欠缺的测试流程和丰盛的场景是对 Dubbo 最好的性能回归测试。内外对立也是兼顾商业化和外部反对的最好形式。在重构的过程中，不断完善性能，进步性能，拥抱更新的更云原生的技术栈，这也是晋升团体外部用户体验的最佳形式。

因而，HSF 和 Dubbo 的交融是大势所趋。为了能更好的服务内外用户，也为了两个框架更好倒退，Dubbo 3.0 和以 Dubbo 3.0 为内核适配团体内基础架构生态的 HSF 3 应运而生。

首先总体上介绍一下 Dubbo 3.0。

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 的对立治理规定利用云原生流量治理性能。

利用级注册发现模型的原型最早在 Dubbo 2.7.6 版本提出，通过数个版本的迭代最终造成了 Dubbo 3.0 中的稳固模型。在 Dubbo 2.7 及以前版本中，利用进行服务注册和发现时，都是以接口为粒度，每个接口都会对应在注册核心上的一条数据，不同的机器会注册上属于以后机器的元数据信息或者接口级别的配置信息，如序列化、机房，单元、超时配置等。所有提供此服务的服务端在进行重启或者公布时，都会在接口粒度独立的变更。

举个例子，一个网关类利用依赖了上游利用的 30 个接口，当上游利用在公布时，就有 30 个对应的地址列表在进行机器上线和下线。以接口作为注册发现第一公民的模型是最早的 SOA 或微服务的拆分形式，提供了灵便的依据繁多服务繁多节点独立动静变更的能力。随着业务的倒退，繁多利用依赖的服务数在一直增多，每个服务提供方的机器数量也因为业务或容量起因一直增长。客户端依赖的总服务地址数上涨迅速，注册核心等相干依赖组件的压力倍增。

咱们留神到了微服务模型倒退的两个趋势：首先，随着单体利用拆分为多微服务利用的根本实现，大规模的服务拆分和重组曾经不再是痛点，大部分接口都只被一个利用提供或者固定几个利用提供。其次，大量的用于标记地址信息的 URL 都是存在极大冗余的，如超时工夫，序列化，这些配置变更频率极低，却在每个 URL 中都呈现。所以利用级注册发现应运而生。

利用级服务发现以利用作为注册发现的根本维度。和接口级的次要区别是，一个利用提供了 100 个接口，依照接口级粒度须要在注册核心上注册 100 个节点，如果这个利用有 100 台机器，那每次公布，对于它的客户端都是 10000 个虚构节点的变更。而利用级注册发现则只须要 1 个节点，每次公布只变更 100 个虚构节点。对于依赖服务数多、机器多的利用而言，是几十到上百分之一数量级的规模降落。内存占用上也会至多降落一半。

最初，因为这个新的服务发现与 Spring Cloud、Service Mesh 等体系下的服务发现模型是统一的，因而 Dubbo 能够从注册核心层面与其余体系下的节点实现互发现，实现异构微服务体系的互联互通。

作为 RPC 框架最根底的能力还是实现跨业务过程的服务调用，将服务组成链、组成网，这其中最外围的载体就是协定。Dubbo 2.0 提供了 RPC 的外围语义，包含协定头、标记位、申请 ID 以及申请 / 响应数据，他们被依照肯定的程序以二进制数据的形式组合在一起。

在云原生时代，Dubbo 2.0 协定次要面临两个挑战。一是生态不互通，用户很难间接了解二进制的协定。第二是对 Mesh 等网关型组件不够敌对，须要残缺的解析协定能力获取到所须要的调用元数据，如一些 RPC 上下文，从性能到易用性方面都会面临挑战。同时，老版本 Dubbo 2.0 RPC 协定的设计与实现，已在实践中被证实在⼀些⽅面限度了业务架构的倒退，⽐如从终端设备到后端服务的交互、微服务架构中多语言的采纳、服务间的数据传输模型等。那么，在反对已有的性能和解决存在的问题的前提下，下一代的协定须要有哪些个性呢？

首先，新协定应该易扩大，包含但不限于 Tracing/ Monitoring 等反对，也应该能被各层设施辨认，升高用户了解难度。

其次，协定须要解决跨语言互通的问题，传统的多语言多 SDK 模式和 Mesh 化跨语言模式都须要一种更通用易扩大的数据传输格局。

最初，协定应该提供更欠缺的申请模型，除了 Request/Response 模型，还应该反对 Streaming 和 Bidirectional 等模型。

基于这些需要，HTTP2/protobuf 的组合是最合乎的。提到这两个，大家可能很容易想到 gRPC 协定。那新一代的协定和 gRPC 的关系是什么呢。

首先，Dubbo 新协定是基于 GRPC 扩大的协定，这也保障了在生态系统上新协定和 GRPC 是可能互通和共享的。其次，在这个根底上，Dubbo 新协定将更原生的反对 Dubbo 的服务治理，提供更大的灵活性。在序列化方面，因为目前大多数利用方还没有应用 Protobuf，所以新协定会在序列化方面给予足够的反对，平滑的适配现有序列化，不便迁徙到 Protobuf。在申请模型上，新协定将原生反对端到端的全链路 Reactive，这也是 gRPC 协定所不具备的。

如何让 Dubbo 在 Service Mesh 体系着落地，社区开发团队调研泛滥计划，最终确定了最适宜 Dubbo 3.0 的两种状态的 Mesh 计划。

⼀种是经典的基于 Sidecar 的 Service Mesh，另⼀种是无 Sidecar 的 Proxyless Mesh。对于 Sidecar Mesh 计划，其部署形式和以后支流 Service Mesh 部署计划统一，Dubbo 3.0 的重点是尽量给业务利用提供齐全通明的降级体验，这不止是编程视角的无感降级，还包含通过 Dubbo 3.0 轻量化、Triple 协定等，让整个调用链路上的损耗与运维老本也升高到最低。这个计划也被称为 Thin SDK 计划，而 Thin 的中央就是在去除所有不须要的组件。Proxyless Mesh 部署计划则是 Dubbo 3.0 布局的另⼀种 Mesh 状态，指标是不须要启动 Sidecar，由传统 SDK 间接与管制面交互。

咱们构想这对以下⼏种场景会⾮常实用 Proxyless Mesh 部署计划：

一是业务方冀望降级 Mesh 计划，但却无奈承受因为 Sidecar 进行流量劫持所带来的性能损耗，这种状况常见于外围业务场景；

二是冀望升高因为部署 Sidecar 带来的运维老本，升高零碎复杂度；三是遗留系统升级迟缓，迁徙过程漫长，多种部署架构⻓期共存。

最初是，多种部署环境，这里的多种部署环境包含了如 VM 虚拟机、Container 容器等多种部署形式，也包含了多种类型利用混合部署，例如 Thin SDK 与 Proxyless 计划混合部署，对性能敏感利用部署 Proxyless 模式，对于周边利用采纳 Thin SDK 部署计划，多种数据面独特由对立管制面进行调度。

将这两种状态兼顾来看，在不同的业务场景、不同的迁徙阶段、不同的基础设施保障状况下，Dubbo 都会有 Mesh ⽅案可供选择。

云原生带来了技术标准化的重大改革，如何让利用在云上更简略地创立和运行，并具备可弹性扩大的能力，是所有云原生根底组件的外围指标。借助云原生技术带来的弹性能力，利用能够在极短时间内扩容出一大批机器以撑持业务须要。比方为了应答零点秒杀场景或者突发事件，利用自身往往须要数千甚至数万的节点数来以满足用户的须要，然而在扩容的同时也带来了许多在云原生场景下集群大规模部署的问题。比方因为集群节点极多导致的节点异样频发、服务容量受多种客观因素影响导致节点服务能力不均等。

Dubbo 期待基于一种柔性的集群调度机制来解决这些问题。这种机制次要解决的问题有两个方面：一是在节点异样的状况下，分布式服务可能保持稳定，不呈现雪崩等问题；二是对于大规模的利用，可能以最佳态运行，提供较高的吞吐量和性能。从繁多服务视角看，Dubbo 冀望的指标是对外提供一种压不垮的服务，即是在申请数特地高的状况下，能够通过选择性地回绝一些的申请来保障总体业务的正确性、时效性。

从分布式视角看，要尽可能升高因为简单的拓扑、不同节点性能不一导致总体性能的降落，柔性调度机制可能以最优的形式动态分配流量，使异构零碎可能依据运行时的精确服务容量正当调配申请，从而达到性能最优。

对业务而言，可能更关怀的是降级到 Dubbo 3.0 能带来哪些收益。总结提炼出两大关键词，别离是利用本身的性能稳定性的晋升以及云原生的原生接入。

性能与稳定性方面，Dubbo 3.0 会着力关注大规模集群部署的场景，通过优化数据存储形式，来升高单机资源损耗，同时能够在应答超大规模集群的程度扩容的时候，保障整个集群的稳定性。另外，在 Dubbo 3.0 提出了柔性服务的概念，也可能在肯定水平上无效保障和进步全链路总体可靠性和资源的利用率。

第二是对于云原生方面，Dubbo 3.0 是 Dubbo 全面拥抱云原生的里程碑版本，以后 Dubbo 在国内外有基数微小的用户群体，随着云原生时代的到来，这些用户上云的需要越来越强烈，Dubbo 3.0 将提供残缺牢靠的解决方案、迁徙门路与最佳实际帮忙企业实现云原生转型，享受云原生带来的红利。

从曾经落地的后果上看，Dubbo 3.0 能⼤幅升高框架带来的额定资源耗费，晋升系统资源利用率。从单机视⻆，Dubbo 3.0 能节俭约 50% 的内存占⽤；从集群视角，Dubbo3 能⽀持百万实例数的大规模集群，为将来更大规模的业务扩容打下基础；Dubbo3 对 Reactive Stream 等通信模型的反对，在大文件传输、流式等业务场景下能带来整体吞吐量的⼤幅晋升。

架构方面，Dubbo 3.0 给业务架构降级带来了更多可能性。Dubbo 原来的协定在⼀定水平上解放了微服务接⼊⽅式的，举个例子，挪动端、前端业务要接入 Dubbo 后端服务，须要通过网关层的协定转换，再比方，Dubbo 只⽀持 request-response 模式的通信，这使得⼀些须要流式传输或反向通信的场景⽆法失去很好的反对。

在云原生转型过程中，业务最关怀的就是改变和稳定性，能不能不改代码或者少改代码就能降级到云原生环境，在业务上云过程的选型中至关重要。Dubbo 3.0 给业务侧云原⽣生降级带来了整体的解决方案。不论是底层基础设施降级带动业务降级，还是为解决业务痛点而进行的被动降级，Dubbo 3.0 所提供的云原生解决方案都能帮忙产品疾速降级，进入云原生时代。

外部应用上，Dubbo 3.0 曾经在考拉业务的数百利用的数万节点中全面落地，大量利用应用 Dubbo 3.0 轻松实现利用上云，目前正在电商外围利用中大规模试点和逐渐落地，以及开启利用级注册发现、Triple 协定等新个性。开源用户和商业化利用目前也在从原有的 HSF2 或 Dubbo 2.0 迁徙至 Dubbo 3.0，服务框架团队和社区正在整顿和编写相干迁徙的最佳实际，一段时间后这些文档就会和大家见面。

Dubbo 3.0 作为捐给 Apache 后的一个里程碑版本曾经在往年 6 月份正式公布了，这也代表着 Apache Dubbo 全面拥抱云原生的一个节点。在 2021 年 11 月咱们会公布 Dubbo 3.1 版本，届时会带来 Dubbo 在 Mesh 场景下部署的最佳实际。

2022 年 3 月会公布 Dubbo 3.2 版本，这个版本将带来服务柔性的全面反对，在大规模利用部署下实现智能流量调度，进步零碎稳定性与资源利用率。

回顾过去，Dubbo 和 HSF 在阿里巴巴和微服务框架的倒退的不同阶段都起到了至关重要的作用。立足当初，放眼将来，Dubbo 3.0 和基于 Dubbo 3.0 内核的 HSF 正在内部和外部齐头并进，做最稳固高性能的微服务框架，给用户最好的应用体验，持续在云原生时代引领微服务的倒退。

作者介绍：__郭浩，阿里巴巴服务框架负责人，Dubbo 3.0 架构师，专一分布式系统架构

﹀

2021 云原生编程挑战赛正式启动评测，选手报名后提交评测，后盾每周都将抽取 10 个获奖队伍赠送天猫精灵 1 个。点击 下方链接 立刻报名！

https://tianchi.aliyun.com/competition/entrance/531923/introduction

版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

正文完