服务框架就像铁路的铁轨一样，是互通的基础，只有解决了服务框架的互通，才有可能完成更高层的业务互通，所以用相同的标准统一，合二为一并共建新一代的服务框架是必然趋势。
Dubbo3.0是Dubbo2.0与HSF融合而来，是阿里经济体面向内部业务、商业化、开源的唯一标准服务框架。
阿里巴巴服务框架的选择与实践
Dubbo和HSF在阿里巴巴的实践
Dubbo和HSF都是阿里巴巴目前在使用的微服务RPC框架。
Dubbo则在年开源后，迅速成为业界广受欢迎的微服务框架产品，在国内外均有着广泛应用。Dubbo项目诞生于年，起初只在一个阿里内部的系统使用；年，阿里B2B决定将整个项目开源，仅用了一年时间就收获了来自不同行业的大批用户；年，由于内部团队调整，Dubbo暂停更新；年9月，Dubbo3.0重启开源，在年5月由Apache孵化毕业，成为第二个由阿里巴巴捐献至Apache毕业的项目。
HSF在阿里巴巴使用更多，承接了内部从单体应用到微服务的架构演进，支撑了阿里历年双十一的平稳运行；自年5月发布第一个版本1.1后，经历数年迭代，HSF从一个基础的RPC框架逐渐演变成为日支撑十万亿级别调用的易于扩展的微服务框架。内部场景中，用户既可以选择少量配置轻松接入微服务体系，获取高性能的稳定服务调用。也可以按照自身业务需求，对HSF进行扩展，获取整条链路的能力增强。
对于集团内的需求而言，稳定和性能是核心，因此，当时选型了在电商这种高并发场景久经考验的HSF做为新一代服务框架核心。随后，HSF推出了2.0的版本，并针对HSF之前版本的主要问题进行重构改造，降低了维护成本，进一步提高了稳定性和性能。HSF2.0解决了通讯协议支持不透明，序列化协议支持不透明等框架扩展性问题。基于HSF2.0的Java版本，集团内也演进出了CPP/NodeJs/PHP等多语言的客户端。由于HSF还兼容了Dubbo的协议，原有的Dubbo用户可以平滑地迁移到新版本上，所以HSF推出后很快就在集团全面铺开，部署的server数量达到数十万，基本完成了阿里巴巴内部微服务框架的统一，并经历了多年双十一零点流量洪峰的验证。
下一代微服务的挑战和机遇
然而，业务的发展和框架自身的迭代使得两个框架从协议层的简单兼容已经无法满足需要。随着云计算的不断发展和云原生理念的广泛传播，微服务的发展有着以下趋势：
K8s成为资源调度的事实标准，ServiceMesh从提出到发展至今已经逐渐被越来越多用户所接受。屏蔽底层基础设施成为软件架构的一个核心演进目标，无论是阿里巴巴还是其他企业用户，所面临的问题都已经从是否上云变为如何平滑稳定地低成本迁移上云。由于上云路径的多样以及由现有架构迁移至云原生架构的过渡态存在，部署应用的设施灵活异变，云上的微服务也呈现出多元化的趋势。跨语言、跨厂商、跨环境的调用必然会催生基于开放标准的统一协议和框架，以满足互通需求。端上对后台服务的访问呈爆炸性的趋势增长，应用的规模和整个微服务体系的规模都随之增长。
这些趋势也给HSF和Dubbo带来了新的挑战。
HSF和Dubbo面临的挑战
微服务框架是基础组件，大部分公司在早期选型或业务发展到一定规模的时候都需要确定使用某一个框架。而一个稳定高效的自研框架通常需要较长时间的迭代来打磨优化。所以大部分公司初期都会倾向于使用开源组件。对阿里云而言，这就带来了一个问题：内部使用的是HSF框架，而云上的用户大部分都是使用的开源Dubbo框架，两种框架在协议、内部模块抽象、编程接口和功能支持上都存在差异。
如何能让使用了HSF的阿里集团内部组件的最优实践和前沿技术更简单直接地输出到云上，这是每一个做技术商业化的同学都会遇到和必须解决的问题。其实我们也有过一些探索，云上微服务最早推的是HSF框架，闭源组件在云上输出的时候，对于许多用户而言，遇到问题后无从排查，整个服务框架对于他们来说是一个黑盒的组件。我们发现这并不是一个很好的产品化方向，在云上输出的时候，我们必须选择拥抱开源的方式，主推Dubbo与SpringCloud框架。
同时在集团内也因为同时存在HSF与Dubbo框架而导致的不少问题。原有部门或公司的技术栈如何更快地融入到现有技术体系是一个绕不开的问题。一个典型的例子就是年加入阿里巴巴的考拉。考拉之前一直使用Dubbo作为微服务框架，基于Dubbo构建了大规模的微服务应用，迁移的成本高，风险也大。需要集团和考拉的基础架构部门耗费较长的时间进行迁移前调研、方案设计，确保基本可行后再开始改动。从分批灰度上线，再到最终全量上线。这种换血式的改动不仅需要耗费大量人力，时间跨度也很长，会影响到业务的发展和稳定性。同时由于历史原因，集团内部始终存在着一定数量的Dubbo用户。为了更好的服务这部分用户，HSF框架对Dubbo进行了协议层和API层的兼容。但这种兼容仅限于互通，随着Dubbo开源社区的多年发展，这种基础的兼容在容灾、性能和可迭代性方面，都有着较大的劣势，同时很难对齐Dubbo的服务治理体系。在稳定性方面也存在风险，更无法享受到集团技术发展和Dubbo社区演进的技术红利。
产生这些问题的根本原因是闭源的HSF无法直接用于广大云上用户和外部其他用户，而开源产品对闭源产品的挑战会随着开源和云的不断发展愈演愈烈。越早解决这个问题，阿里巴巴和外部企业用户的云原生迁移成本越低，产生的价值也就越大。
因此，HSF和Dubbo的融合是大势所趋。为了能更好的服务内外用户，也为了两个框架更好发展，Dubbo3.0和以Dubbo3.0为内核适配集团内基础架构生态的HSF3.0应运而生。
三位一体战略下服务框架的最终选择Dubbo3.0
Dubbo3.0在原有功能集与API完全兼容的前提下，同时具备了以下几大面临云原生挑战下的新特性
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.0的统一治理规则应用云原生流量治理功能。
服务框架在阿里云商业化方向上的演进思路
对于微服务框架来说，由于关联到客户的业务代码，要做商业化还是有非常大的挑战的。
首先，迁移成本上来说，希望把降低迁移成本为0，最开始我们在云上售卖的是HSF+EDASContainer这一套的架构，因此客户在上云的时候，不得不对自己的业务代码进行改造，另外，由于代码不开源，排查问题也是一个非常头疼的问题，后来，我们发现客户大多数的微服务框架都会选择开源的Dubbo/SpringCloud，但是客户有自建的注册中心，如果要上云还需要把自己的注册中心迁移到MSE注册中心上，这个过程需要用户对代码做改造才行，一般来说会采用双注册的方案，在云上我们发现推动客户做代码改造，包括SDK的升级是一件非常难的事情，很多客户的Dubbo版本还停留在4-5年的版本，不仅需要研发、测试、运维都来