介绍：HSF与Dubbo融合是大势所趋。为了更好的服务内外部用户，更好的发展两大框架，以Dubbo3.0为核心适应集团基础设施生态的Dubbo3.0和HSF3应运而生。作者|郭浩Dubbo和HSF都是阿里巴巴目前使用的微服务RPC框架。HSF在阿里巴巴使用较多，承担了内部从单体应用到微服务的架构演进，支撑了阿里历年双十一的平稳运行；Dubbo在2011年开源后迅速成为业界流行的微服务，Frame产品在国内外得到广泛应用。在2008年5月第一个1.1版本发布后，经过几年的迭代，HSF已经从一个基础的RPC框架，逐渐演变成一个易扩展的、支持每天十万亿次调用的微服务框架。在内部场景下，用户可以选择少量配置，轻松接入微服务系统，获取高性能稳定的服务调用。也可以根据自己的业务需要扩展HSF，增强获取全链路的能力。Dubbo项目诞生于2008年，最初只在阿里内部的一个系统中使用；2011年，阿里B2B决定将整个项目开源，仅用了一年的时间就收获了大量不同行业的用户；2014年，由于内部团队调整，Dubbo暂停更新；2017年9月，Dubbo3重启开源，并于2019年5月从Apache孵化毕业，成为阿里巴巴捐赠给Apache毕业的第二个项目。Dubbo和HSF是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上线后很快就在集团内全面铺开，部署的服务器数量达到数十万台。统一服务架构，经历了多年双十一零点流量高峰的验证。下一代微服务的挑战与机遇然而，业务的发展和框架本身的迭代，使得两个框架从协议层简单的兼容已经不能满足需求。随着云计算的不断发展和云原生概念的广泛传播，微服务的发展有以下几个趋势：1.K8s已经成为资源调度的事实标准，ServiceMesh逐渐被越来越多的用户所接受自从它被提出和开发以来。.屏蔽底层基础设施成为软件架构的核心演进目标。阿里巴巴和其他企业用户面临的问题，已经从要不要上云，转变为如何低成本、平稳、平稳地上云。2、由于上云路径的多样性以及从现有架构向云原生架构的过渡，部署应用的设施灵活多变，云上的微服务也呈现出多样化的趋势。跨语言、跨厂商、跨环境的调用，必然会产生基于开放标准的统一协议和框架，以满足互操作性需求。3、终端接入后台服务呈爆发式增长，应用规模和整个微服务体系的规模也相应增长。这些趋势也给HSF和Dubbo带来了新的挑战。首先，上云对内部闭源组件产生了影响。微服务框架是一个基础组件，大部分公司在前期选型或者业务发展到一定规模的时候，都需要确定使用某个框架。一个稳定高效的自研框架，通常需要经过长时间的迭代打磨和优化。因此，大多数公司最初倾向于使用开源组件。对于阿里云来说，这带来了一个问题：内部使用的是HSF框架，而云端大部分用户使用的是开源的Dubbo框架。两种框架在协议、内部模块抽象、编程接口和功能支持等方面存在差异。如何更简单直接地将阿里巴巴集团内部组件使用HSF的最佳实践和前沿技术输出到云端，这是每个做技术商业化的同学都会遇到和必须解决的问题。其次，如何将原有部门或公司的技术栈快速融入现有技术体系，是一个无法回避的问题。一个典型的例子是2019年加入阿里巴巴的考拉，考拉此前一直在使用Dubbo作为微服务框架，并基于Dubbo构建了一个大型的微服务应用。迁移成本高，风险也大。集团和考拉的基础设施部门需要花很长时间进行迁移前的研究和方案设计，确保基本可行后再做改动。从批量灰度上线，到最后全量上线。这种翻天覆地的变化，不仅需要大量人力，而且耗时较长，会影响业务的发展和稳定。第三，由于历史原因，群内始终存在一定数量的Dubbo用户。为了更好的服务这些用户，HSF框架在协议层和API层兼容Dubbo。但这种兼容仅限于互通。随着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的融合是大势所趋。为了更好的服务内外部用户，更好的发展两大框架，以Dubbo3.0为核心适应集团基础设施生态的Dubbo3.0和HSF3应运而生。下一代云原生微服务首先全面引入Dubbo3.0。Dubbo3.0支持新的服务发现模型。Dubbo3.0试图从应用模型入手，优化存储结构，向云原生主流设计模型看齐，避免模型带来的互操作性问题。新模型在数据组织上高度压缩，可以有效提高集群的性能和可扩展性。Dubbo3.0提出了下一代RPC协议——Triple。这是一个基于HTTP/2设计的完全兼容gRPC协议的开放式新协议。因为它是基于HTTP/2设计的，所以对网关非常友好和穿透；完全兼容gRPC协议，自然在多语言互操作性方面有优势。Dubbo3.0面向云原生流量治理，提出了一套可以覆盖传统SDK部署、ServiceMesh部署、VM虚拟机部署、Container容器部署等场景的统一治理规则，支持一条规则治理大部分场景，大大降低了流量治理成本，使得异构系统下的全局流量治理成为可能。Dubbo3.0将提供接入ServiceMesh的解决方案。针对Mesh场景，Dubbo3.0提出了两种接入方式。一种是ThinSDK模式。部署模型与目前主流的ServiceMesh部署场景如出一辙，Dubbo将瘦身，屏蔽与Mesh相同的治理功能，只保留核心的RPC能力；二是Proxyless模式，Dubbo将接管Sidecar的职责，主动与控制面沟通，基于Dubbo3.0Governance功能的统一治理规则应用云原生流量。1.应用级注册发现模型应用级注册发现模型的雏形最早是在Dubbo2.7.6版本中提出的。经过多次迭代，最终形成了Dubbo3.0中稳定的模型。在Dubbo2.7及之前的版本中，应用在注册和发现服务时，是以接口为粒度的。每个接口都会对应注册中心的一条数据。不同机器会注册属于本机的元数据信息或接口层面的Configuration信息，如序列化、机房、单位、超时配置等，所有提供该服务的服务器在重启或发布时都会在接口粒度上独立变化.例如，一个网关应用程序依赖于上游应用程序的30个接口。上游应用发布时，对应的30个地址列表正在上线下线。接口作为第一公民注册和发现的模型是最早的SOA或微服务拆分方式，它提供了基于单个服务和单个节点的独立动态灵活变化的能力。随着业务的发展，单个应用所依赖的服务数量越来越多，由于业务或容量原因，每个服务提供者的机器数量也越来越多。客户端依赖的服务地址总数快速增长，注册中心等相关依赖组件的压力成倍增加。我们注意到微服务模型发展的两个趋势：一是随着单体应用拆分为多微服务应用的基本完成，大规模的服务拆分重组不再是痛点，大部分接口只被由一个应用程序提供或由多个应用程序修复。其次，大量用于标记地址信息的URL极其冗余，如超时、序列化等。这些配置更改的频率极低，但它们出现在每个URL中。于是应用级注册发现应运而生。应用层服务发现以应用为注册发现的基本维度。与接口层的主要区别在于，一个应用提供100个接口，需要按照接口层粒度在注册中心注册100个节点。如果应用有100台机器，每次发布，它的客户端就是10000个虚拟节点变化。而应用级注册发现只需要1个节点，每次发布只改变100个虚拟节点。对于依赖大量服务和多台机器的应用程序，规模减少了百分之几十到百分之几百。内存使用量也将减少至少一半。最后，由于这种新的服务发现与SpringCloud、ServiceMesh等系统下的服务发现模型是一致的，因此Dubbo可以从注册中心层面实现与其他系统下节点的相互发现，实现异构微服务系统的互联互通。2.下一代RPC协议——Triple，作为RPC框架最基础的能力，完成跨业务流程的服务调用，将服务形成链和网络。这其中的核心载体就是协议。Dubbo2.0提供了RPC的核心语义，包括协议头、标志、请求ID和请求/响应数据，它们按照一定的顺序组合成二进制数据。在云原生时代，Dubbo2.0协议主要面临两大挑战。一是生态不互通，用户很难直接理解二进制协议。二是对Mesh等网关组件不友好，需要完整的解析协议才能得到需要的调用元数据，比如一些RPC上下文，在性能和易用性上都会面临挑战。同时，老版本Dubbo2.0RPC协议的设计与实现在实践中被证明在某些方面限制了业务架构的发展，例如终端设备与后端服务的交互、多语言支持等。在微服务架构的采用、服务间的数据传输模型等方面。那么，在支持现有功能、解决现有问题的前提下，下一代协议应该具备哪些特性呢？首先，新的协议应该易于扩展，包括但不限于Tracing/Monitoring等支持，还应该被各级设备所认可，降低用户的理解难度。其次，协议需要解决跨语言互通的问题。无论是传统的多语言多SDK模式，还是Mesh跨语言模式，都需要一种更通用、可扩展的数据传输格式。最后，协议应该提供更完整的请求模型。除了Request/Response模型，它还应该支持Streaming和Bidirectional等模型。基于这些要求，HTTP2/protobuf组合是最合适的。提到这两个，你可能很容易想到gRPC协议。新一代协议和gRPC有什么关系？首先，新的Dubbo协议是基于GRPC的扩展协议，这也保证了新协议与GRPC在生态中的互通共享。其次，在此基础上，新的Dubbo协议将更加原生支持Dubbo的服务治理，提供更大的灵活性。在序列化方面，由于大部分应用还没有使用Protobuf，新协议将在序列化方面提供足够的支持，平滑适配现有序列化，方便迁移到Protobuf。在请求模型方面，新协议将原生支持端到端的全链路Reactive，这是gRPC协议所不具备的。3、如何通过原生接入ServiceMesh，在ServiceMesh体系中实现Dubbo？社区开发团队调研了很多方案，最终确定了两个最适合Dubbo3.0的Mesh方案。一种是经典的基于Sidecar的ServiceMesh，另一种是没有Sidecar的ProxylessMesh。对于SidecarMesh方案，其部署方式与目前主流的ServiceMesh部署方案一致。Dubbo3.0的重点是尽可能为业务应用提供完全透明的升级体验。、三重协议等，让整个调用链路上的损耗和运维成本也降到最低。该方案也称为ThinSDK方案，Thin的地方在于去掉所有不需要的组件。ProxylessMesh部署方案是Dubbo3.0规划的另一种Mesh形式。目标是在不启动Sidecar的情况下，直接通过传统SDK与控制面进行交互。我们设想这将非常适用于以下场景下的ProxylessMesh部署方案：第一，业务方期望升级Mesh方案，但不能接受核心业务场景常见的sidecar流量劫持带来的性能损失;二是有望降低部署Sidecar带来的运维成本和系统复杂度；三是遗留系统升级缓慢，迁移过程漫长，多种部署架构长期并存。最后，各种部署环境。这里的各种部署环境包括VM虚拟机、Container容器等各种部署方式，以及各类应用的混合部署，如ThinSDK和Proxyless方案的混合部署。敏感应用采用Proxyless方式部署，周边应用采用ThinSDK部署方案部署，多个数据面由统一控制面联合调度。将这两种形态作为一个整体来看，在不同的业务场景、不同的迁移阶段、不同的基础设施保障下，Dubbo都会有Mesh方案可供选择。4.灵活的服务增强云原生带来了技术标准化的重大变革。如何让应用更容易在云端创建和运行，并具备弹性扩展的能力，是所有云原生基础组件的核心目标。借助云原生技术带来的弹性能力，应用可以在极短的时间内扩展大量的机器来支撑业务需求。例如，为了应对零点秒杀场景或突发事件，应用本身往往需要数千甚至数万个节点来满足用户的需求，但扩容也带来了很多集群在云端的大规模部署-本地场景。问题。例如，由于集群节点数量多，节点异常频繁发生，服务能力受各种客观因素影响，导致节点服务能力参差不齐。Dubbo期待基于灵活的集群调度机制来解决这些问题。该机制主要解决两个问题：一是在节点异常的情况下，分布式服务能够保持稳定，不会出现雪崩等问题；另一个是对于大型应用程序，它可以运行在最佳状态并提供高吞吐量和性能。从单体服务的角度来看，Dubbo预期的目标是对外提供一个牢不可破的服务，即在请求量特别多的时候，可以选择性的拒绝部分请求，保证整体业务的正确性和时效性性别。从分布式的角度来看，需要尽可能的减少由于复杂的拓扑结构和不同节点的不同性能而导致的整体性能下降。灵活的调度机制可以动态优化分配流量，使得异构系统可以根据运行时提供准确的服务容量，合理分配请求，达到性能最优。5.业务收益对于业务来说，可能更关心升级到Dubbo3.0能够带来的收益。综上，提炼出两个关键词，即应用本身性能稳定性的提升和云原生的原生接入。在性能和稳定性方面，Dubbo3.0将专注于大规模集群部署场景，通过优化数据存储方式减少单机资源消耗，在应对超大规模水平扩展时保证整个集群的稳定性规模集群。另外，在Dubbo3.0中提出了弹性服务的概念，也能在一定程度上有效保证和提高全链路的整体可靠性和资源利用率。第二个是关于云原生的。Dubbo3.0是Dubbo全面拥抱云原生的里程碑版本。目前，Dubbo在国内外拥有庞大的用户群。随着云原生时代的到来，这些用户对上云的需求越来越强烈，Dubbo3.0将提供完整可靠的解决方案、迁移路径和最佳实践，帮助企业实现云原生转型，享受云原生带来的红利。从已经实现的结果来看，Dubbo3.0可以大大减少框架带来的额外资源消耗，提高系统资源的利用率。从单机的角度来看，Dubbo3.0可以节省大约50%的内存使用；从集群的角度来看，Dubbo3可以支持百万级实例的大规模集群，为未来更大规模的业务扩展打下基础；Dubbo3支持ReactiveStream等，通信模型的支持可以在大文件传输、流式传输等业务场景中大幅提升整体吞吐量。在架构方面，Dubbo3.0为业务架构升级带来了更多可能。Dubbo原有的协议在一定程度上约束了微服务的访问方式。比如移动端和前端服务需要访问Dubbo后端服务，需要在网关层进行协议转换。再比如，Dubbo只支持request-response方式的通信，这使得一些需要流式或者反向通信的场景无法很好的支持。在云原生转型过程中，业务最关心的是变化和稳定性。能否在不改代码或者最少改代码的情况下升级到云原生环境，在业务上云流程的选择上非常重要。Dubbo3.0带来了业务端云原生升级的整体解决方案。无论是底层基础设施升级带动业务升级，还是主动升级解决业务痛点，Dubbo3.0提供的云原生解决方案都可以帮助产品快速升级，进入云原生时代。6、从Roadmap的现状和内部使用来看，Dubbo3.0已经在考拉业务上百个应用的上万个节点全面落地。大量应用使用Dubbo3.0轻松完成应用上云。目前，它正在核心电子商务应用中进行大规模试点和应用。逐步实现应用级注册发现、三重协议等新特性。开源用户和商业应用目前正在从原来的HSF2或Dubbo2.0迁移到Dubbo3.0。服务框架团队和社区正在整理和编写迁移相关的最佳实践，这些文档将在一段时间后提供给大家。Dubbo3.0作为捐赠给Apache后的里程碑版本于今年6月正式发布，这也代表了ApacheDubbo全面拥抱云原生的一个节点。2021年11月，我们将发布Dubbo3.1版本，带来Mesh场景下Dubbo部署的最佳实践。Dubbo3.2版本将于2022年3月发布，该版本将带来对服务弹性的全面支持，实现大规模应用部署下的智能流量调度，提升系统稳定性和资源利用率。回过头来看，无论是Dubbo还是HSF，在阿里巴巴和微服务框架发展的不同阶段都起到了至关重要的作用。立足现在，放眼未来，Dubbo3.0和基于Dubbo3.0内核的HSF，内外兼修，做最稳定、高性能的微服务框架，给用户最好的体验，继续引领云原生时代微服务的发展。作者介绍：郭昊，阿里巴巴服务框架负责人，Dubbo3.0架构师，专注于分布式系统架构原文链接本文为阿里云原创内容，未经允许不得转载。
