自 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 之前版本的紧张问题进行重构改造，降落了掩护本钱，进一步提高了稳定性和性能。HSF2.0 办理了通讯协议支持不透明，序列化协议支持不透明等框架扩展性问题。基于 HSF2.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 的品牌和号召力对阿里云有巨大的商业代价。在 2017 年重启开源时，HSF 的作者毕玄就曾说过：“Dubbo 的品牌我们必须武断不移的培植下去，这不仅是我们阿里技能内外统一的第一步，也是从技能栈到品牌延伸的主要里程碑”。Dubbo 在集团内大规模落地后，会产生良好的原厂品牌示范效应，外部用户也会有更多的信心在进行微做事框架选型时选择 Dubbo。同时，目前已经利用 Dubbo 的用户也有更充分的情由不断追随版本演进，享受阿里巴巴开源带来的技能红利。
工程实践上，利用 Dubbo 重构 HSF 这种从内部重新统一的可行性更高，迁移的繁芜度可控，能够逐步地有序实现。内部完善的测试流程和丰富的场景是对 Dubbo 最好的功能回归测试。内外统一也是兼顾商业化和内部支持的最好办法。在重构的过程中，不断完善功能，提高性能，拥抱更新的更云原生的技能栈，这也是提升集团内部用户体验的最佳办法。
因此，HSF 和 Dubbo 的领悟是大势所趋。为了能更好地做事内外用户，也为了两个框架更好发展，Dubbo3 和以 Dubbo3 为内核适配集团内根本架构生态的 HSF3 应运而生。
下一代云原生微做事首先总体上先容一下 Dubbo3 。
Dubbo 3 支持全新的做事创造模型，Dubbo 3 考试测验从运用模型入手，优化存储构造，对齐云原生主流设计模型，避免在模型上带来的互通问题。新模型在数据组织上高度压缩，能有效提高性能和集群的可伸缩性。Dubbo 3 提出了下一代 RPC 协议 —— Triple。这是一个基于 HTTP/2 设计的完备兼容 gRPC 协议的开放性新协议，由于是基于 HTTP/2 设计的，具有极高的网关友好型和穿透性；完备兼容 gRPC 协议是的天然在多措辞互通方面上具有上风。Dubbo 3 面向云原生流量管理，提出了一套能够覆盖传统 SDK 支配、Service Mesh 化支配、VM 虚拟机支配、Container 容器支配等场景的统一管理规则，支持一份规则管理大部分场景，大大降落流量管理本钱，使得异构体系下全局流量管理成为可能。Dubbo 3 将供应接入 Service Mesh 的办理方案，面向 Mesh 场景，Dubbo 3 提出了两种接入办法，一种是 Thin SDK 模式，支配模型和当前 Service Mesh 主流支配场景完备一样，而 Dubbo 将进行瘦身，屏蔽掉与 Mesh 相同的管理功能，仅保留核心的 RPC 能力；第二种是 Proxyless 模式，Dubbo 将接替 Sidecar 的事情职责，主动与掌握面进行通信，基于 Dubbo 3 的统一管理规则运用云原生流量管理功能。运用级注册创造模型运用级注册创造模型的原型最早在 Dubbo 2.7.6 版本提出，经由数个版本的迭代终极形成了 Dubbo 3 中的稳定模型。 在 Dubbo 2.7 及以前版本中，运用进行做事注册和创造时，都因此接口为粒度，每个接口都会对应在注册中央上的一条数据，不同的机器会注册上属于当前机器的元数据信息或者接口级别的配置信息，如序列化、机房，单元、超时配置等。 所有供应此做事的做事端在进行重启或者发布时，都会在接口粒度独立的变更。举个例子，一个网关类运用依赖了上游运用的 30 个接口，当上游运用在发布时，就有 30 个对应的地址列表在进行机器上线和下线。以接口作为注册创造第一公民的模型是最早的 SOA 或微做事的拆分办法，供应了灵巧的根据单一做事、单一节点独立动态变更的能力。随着业务的发展，单一运用依赖的做事数在不断增多，每个做事供应方的机器数量也由于业务或容量缘故原由不断增长。客户端依赖的总做事地址数上涨迅速，注册中央等干系依赖组件的压力倍增。我们把稳到了微做事模型发展的两个趋势： 首先，随着单体运用拆分为多微做事运用的基本完成，大规模的做事拆分和重组已经不再是痛点，大部分接口都只被一个运用供应或者固定几个运用供应；其次，大量用于标志地址信息的 URL 都是存在极大冗余的，如超时时间，序列化，这些配置变更频率极低，却在每个 URL 中都涌现。以是，运用级注册创造应运而生。
运用级做事创造以运用作为注册创造的基本维度。和接口级的紧张差异是，一个运用供应了 100 个接口，按照接口级粒度须要在注册中央上注册 100 个节点，如果这个运用有 100 台机器，那每次发布对付它的客户端都是 10000 个虚拟节点的变更。 而运用级注册创造则只须要 1 个节点， 每次发布只变更 100 个虚拟节点。 对付依赖做事数多、机器多的运用而言，是几十到上百分之一数量级的规模低落，内存占用上也会至少低落一半。
末了，由于新的做事创造与 Spring Cloud、Service Mesh 等体系下的做事创造模型同等，因此 Dubbo 可以从注册中央层面与其他体系下的节点实现互创造，实现异构微做事体系的互联互通。
下一代 RPC 协议——Triple作为 RPC 框架最根本的能力还是完成跨业务进程的做事调用，将做事组成链、组成网，这个中最核心的载体便是协议。 Dubbo2 供应了 RPC 的核心语义，包括协议头、标志位、要求 ID 以及要求/相应数据，他们被按照一定的顺序以二进制数据的办法组合在一起。
在云原生时期，Dubbo2 协议紧张面临两个寻衅。一是生态不互通，用户很难直接理解二进制的协议。二是对 Mesh 等网关型组件不足友好，须要完全的解析协议才能获取到所须要的调用元数据，如一些 RPC 高下文，从性能到易用性方面都会面临寻衅。 同时，老版本 Dubbo2 RPC 协议的设计与实现，已在实践中被证实在⼀些⽅面限定了业务架构的发展，⽐如从终端设备到后端做事的交互、微做事架构中多措辞的采取、做事间的数据传输模型等。 那么，在支持已有的功能和解决存在的问题的条件下，下一代协议须要有哪些特性呢？ 首先，新协议该当易扩展，包括但不限于 Tracing/ Monitoring 等支持，也该当能被各层设备识别，降落用户理解难度。 其次，协议须要办理跨措辞互通的问题，传统的多措辞、多 SDK 模式和 Mesh 化跨措辞模式都须要一种更通用易扩展的数据传输格式。末了，协议该当供应更完善的要求模型，除了 Request/Response 模型，还该当支持 Streaming 和 Bidirectional 等模型。 基于这些需求，HTTP2/protobuf 的组合是最符合的。提到这两个，大家可能很随意马虎想到 gRPC 协议，那新一代协议和 gRPC 的关系是什么呢？
首先，Dubbo 新协议是基于 GRPC 扩展的协议，这也担保了在生态系统上新协议和 gRPC 是能够互通和共享的。其次，在这个根本上，Dubbo 新协议将更原生支持 Dubbo 的做事管理，供应更大的灵巧性。在序列化方面，由于目前大多数运用方还没有利用 Protobuf ，以是新协议会在序列化方面给予足够的支持，平滑的适配现有序列化，方便迁移到 Protobuf。 在要求模型上，新协议将原生支持端到真个全链路 Reactive，这也是 gRPC 协议所不具备的。
原生接入 Service Mesh如何让 Dubbo 在 Service Mesh 体系着落地，社区开拓团队调研浩瀚方案，终极确定了最适宜 Dubbo3 的两种形态的 Mesh 方案。⼀种是经典的基于 Sidecar 的 Service Mesh，另⼀种是无 Sidecar 的 Proxyless Mesh。对付 Sidecar Mesh 方案，其支配办法和当前主流 Service Mesh 支配方案同等，Dubbo3 的重点是只管即便给业务运用供应完备透明的升级体验，这不止是编程视角的无感升级，还包括通过 Dubbo3 轻量化、Triple 协议等，让全体调用链路上的损耗与运维本钱也降到最低。这个方案也被称为 Thin SDK 方案，而 Thin 的地方便是在去除所有不须要的组件。 Proxyless Mesh 支配方案则是 Dubbo3 方案的另⼀种 Mesh 形态，目标是不须要启动 Sidecar，由传统 SDK 直接与掌握面交互。
我们设想这对以下⼏种场景会⾮常适用 Proxyless Mesh 支配方案： 一是业务方期望升级 Mesh 方案，但却无法接管由于 Sidecar 进行流量挟制所带来的性能损耗，这种情形常见于核心业务场景；二是期望降落由于支配 Sidecar 带来的运维本钱，降落系统繁芜度；三是遗留系统升级缓慢，迁移过程漫长，多种支配架构⻓期共存；末了是多种支配环境，这里的多种支配环境包括了如 VM 虚拟机、Container 容器等多种支配办法，也包括了多种类型运用稠浊支配，例如 Thin SDK 与 Proxyless 方案稠浊支配，对性能敏感运用支配 Proxyless 模式，对付周边运用采取 Thin SDK 支配方案，多种数据面共同由统一掌握面进行调度。 将这两种形态统筹来看，在不同的业务场景、不同的迁移阶段、不同的根本举动步伐保障情形下， Dubbo 都会有 Mesh ⽅案可供选择。
柔性做事增强云原生带来了技能标准化的重大变革，如何让运用在云上更大略地创建和运行，并具备可弹性扩展的能力，是所有云原生根本组件的核心目标。借助云原生技能带来的弹性能力，运用可以在极短韶光内扩容出一大批机器以支撑业务须要。 比如为了应对零点秒杀场景或者突发事宜，运用本身每每须要数千乃至数万的节点数以知足用户须要，但是在扩容的同时也带来了许多在云原生场景下集群大规模支配的问题。比如由于集群节点极多导致的节点非常频发、做事容量受多种客不雅观成分影响导致节点做事能力不均等。
Dubbo 期待基于一种柔性的集群调度机制来办理这些问题。这种机制紧张办理的问题有两个方面：一是在节点非常的情形下，分布式做事能够保持稳定，不涌现雪崩等问题；二是对付大规模的运用，能够以最佳态运行，供应较高的吞吐量和性能。 从单一做事视角看，Dubbo 期望的目标是对外供应一种压不垮的做事，即是在要求数特殊高的情形下，可以通过选择性地谢绝一些要求来担保总体业务的精确性、时效性。
从分布式视角看，要尽可能降落由于繁芜的拓扑、不同节点性能不一导致总体性能的低落，柔性调度机制能够以最优的办法动态分配流量，使异构系统能够根据运行时的准确做事容量合理分配要求，从而达到性能最优。
业务收益对业务而言，可能更关心的是升级到 Dubbo3 能带来哪些收益。总结提炼出两大关键点，分别是运用自身的性能稳定性提升以及云原生的原生接入。
性能与稳定性方面，Dubbo3 会着力关注大规模集群支配的场景，通过优化数据存储办法，来降落单机资源损耗，同时可以在应对超大规模集群的水平扩容的时候，担保全体集群的稳定性。其余，在 Dubbo3 提出了柔性做事的观点，也能够在一定程度上有效担保和提高全链路总体可靠性和资源的利用率。第二是关于云原生方面，Dubbo3 是 Dubbo 全面拥抱云原生的里程碑版本，当前 Dubbo 在国内外有基数巨大的用户群体，随着云原生时期的到来，这些用户上云的需求越来越强烈，Dubbo3 将供应完端赖得住的办理方案、迁移路径与最佳实践帮助企业实现云原生转型，享受云原生带来的红利。从已经落地的结果上看，Dubbo3 能⼤幅降落框架带来的额外资源花费，提升系统资源利用率。 从单机视⻆，Dubbo3 能节省约 50% 的内存占⽤；从集群视角，Dubbo3 能⽀持百万实例数的大规模集群，为未来更大规模的业务扩容打下根本；Dubbo3 对 Reactive Stream 等通信模型的支持，在大文件传输、流式等业务场景下能带来整体吞吐量的⼤幅提升。
架构方面，Dubbo3 给业务架构升级带来了更多可能性。 Dubbo 原来的协议在⼀定程度上束缚了微做事接⼊⽅式的，举个例子，移动端、前端业务要接入 Dubbo 后端做事，须要经由网关层的协议转换，再比如，Dubbo 只⽀持 request-response 模式的通信，这使得⼀些须要流式传输或反向通信的场景⽆法得到很好的支持。
在云原生转型过程中，业务最关心的便是改动和稳定性，能不能不改代码或者少改代码就能升级到云原生环境，在业务上云过程的选型中至关主要。Dubbo3 给业务侧云原⽣生升级带来了整体的办理方案。不论是底层根本举动步伐升级带动业务升级，还是为办理业务痛点而进行的主动升级，Dubbo3 所供应的云原生办理方案都能帮助产品快速升级，进入云原生时期。
现状和 Roadmap内部利用上，Dubbo3 已经在考拉业务的数百运用的数万节点中全面落地，大量运用利用 Dubbo3 轻松完成运用上云，目前正在电商核心运用中大规模试点和逐步落地，以及开启运用级注册创造、Triple 协议等新特性。开源用户和商业化运用目前也在从原有的 HSF2 或 Dubbo2 迁移至 Dubbo3 ，做事框架团队和社区正在整理和编写干系迁移的最佳实践，一段韶光后这些文档就会和大家见面。
Dubbo3 作为捐给 Apache 后的一个里程碑版本已经在今年 6 月份正式发布了，这也代表着 Apache Dubbo 全面拥抱云原生的一个节点。 在 2021 年 11 月我们会发布 Dubbo 3.1 版本，届时会带来 Dubbo 在 Mesh 场景下支配的最佳实践。2022 年 3 月会发布 Dubbo 3.2 版本，这个版本将带来做事柔性的全面支持，在大规模运用支配下实现智能流量调度，提高系统稳定性与资源利用率。
回顾过去，Dubbo 和 HSF 在阿里巴巴和微做事框架的发展的不同阶段都起到了至关主要的浸染。立足现在，放眼未来，Dubbo3 和基于 Dubbo3 内核的 HSF 正在外部和内部齐头并进，做最稳定高性能的微做事框架，给用户最好的利用体验，连续在云原生时期引领微做事的发展。
作者先容：
郭浩，阿里巴巴做事框架卖力人，Dubbo3.0 架构师，专注分布式系统架构
