Dubbo3.0 是 Dubbo2.0 与 HSF 领悟而来，是阿里经济体面向内部业务、商业化、开源的唯一标准做事框架。
阿里巴巴做事框架的选择与实践Dubbo 和 HSF 在阿里巴巴的实践
Dubbo 和 HSF 都是阿里巴巴目前在利用的微做事 RPC 框架。
Dubbo 则在 2011 年开源后，迅速成为业界广受欢迎的微做事框架产品，在国内外均有着广泛运用。Dubbo 项目出身于 2008 年，起初只在一个阿里内部的系统利用；2011 年，阿里 B2B 决定将全体项目开源，仅用了一年韶光就收成了来自不同行业的大批用户；2014 年，由于内部团队调度，Dubbo 停息更新；2017 年 9 月，Dubbo 3.0 重启开源，在 2019 年 5 月由 Apache 孵化毕业，成为第二个由阿里巴巴捐献至 Apache 毕业的项目。
HSF 在阿里巴巴利用更多，承接了内部从单体运用到微做事的架构演进，支撑了阿里历年双十一的平稳运行；自 2008 年 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 成为资源调度的事实标准，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 的统一管理规则运用云原生流量管理功能。做事框架在阿里云商业化方向上的演进思路对付微做事框架来说，由于关联到客户的业务代码，要做商业化还是有非常大的寻衅的。
首先，迁移本钱上来说，希望把降落迁移本钱为 0，最开始我们在云上售卖的是 HSF + EDAS Container 这一套的架构，因此客户在上云的时候，不得不对自己的业务代码进行改造，其余，由于代码不开源，排查问题也是一个非常头疼的问题，后来，我们创造客户大多数的微做事框架都会选择开源的 Dubbo/Spring Cloud，但是客户有自建的注册中央，如果要上云还须要把自己的注册中央迁移到 MSE 注册中央上，这个过程须要用户对代码做改造才行，一样平常来说会采取双注册的方案，在云上我们创造推动客户做代码改造，包括 SDK 的升级是一件非常难的事情，很多客户的 Dubbo 版本还勾留在 4-5 年的版本，不仅须要研发、测试、运维都来关注，还须要排期支持，这个动作会耗费大量的人力资源，同时面临许多稳定性的寻衅。光是这一步就会阻挡住许多的客户了，为理解决客户 SDK 升级的问题，我们在想，能不能不要迁移注册中央呢，最好是代码一行也不用改，支配到云上来，但我们又须要供应同等的做事管理能力，因此，我们提出了基于 Java Agent 字节码增强的技能，帮助用户不改一行代码利用云产品，对客户做到了随时可上可下，没有绑定，让客户比较放心的上云产品，同时我们还供应了能力更强的面运维的托管的注册中央。
对付商业化中微做事框架的选择，我们选择的态度一贯是拥抱开源。
我们还须要在开源微做事框架的根本上供应差异化的做事管理能力，传统开源微做事框架在 K8s 上的问题在上云的过程中逐步暴露出来。通过一系列和客户的互换，我们总结出了客户的云原生下进行微做事管理的几大痛点，紧张包括微做事发布过程中的无损高下线，标签路由，做事鉴权，离群实例摘除，全链路灰度等等，我们通过 Java Agent 技能实现了在用户不改代码的情形下，办理了上述问题，通过客户互换，网络需求，落到产品，给客户 demo 验证这个模式跑通了正向的循环，功能不断丰富中。除了Java Agent，对付多措辞的场景我们利用 Service Mesh、WASM 等技能，同样支持客户无需修正一行代码，就具备于 Java 运用同等的做事管理能力与体验。
同时在Java Agent 的选择上我们也有过一些考试测验跟选择，一开始我们利用闭源开拓的 Java Agent，每个云产品都有一个对应的 Java Agent，这样会导致 Java Agent 过多以及Agent冲突等问题，同时由于我们自己掩护的 Java Agent 又是闭源的。踩过一些坑后，我们决定利用 Arthas One Agent 重构做事管理体系的 Agent，将管理干系的 Agent 合成一个，同时我们底座的 Java Agent 也利用拥抱开源的策略，我们利用开源的 Arthas One Agent。
Dubbo3.0 顺应了这个方向，通过 Dubbo3.0 + Java Agent 将集团技能发展和 Dubbo 社区演进、以及商业化实践的技能红利不断且持续地输出给云上的客户。
做事管理无缝支持 Dubbo3.0
阿里云上微做事管理干系的三种办理方案：MSE(微做事引擎，供应微做事管理的能力)、EDAS(全生命周期托管的运用平台)、SAE(具备弹性伸缩能力的Serverless 运用平台)，EDAS 与 SAE 均深度集成了 MSE 做事管理能力；个中 MSE 所有的做事管理能力都是开箱即用，支持近五年来市情上所有开源 Dubbo、Spring Cloud 框架，包括 Dubbo 3.0 您无需修正一行代码与配置，您只需将您的 Dubbo 3.0 的运用接入 EDAS/MSE/SAE。包括微做事发布过程中的无损高下线能力，对齐了微做事与 K8S POD 的生命周期；标签路由能力弱化了对 IP 的绑定依赖，做事鉴权，离群实例摘除，全链路灰度，做事 Mock、做事监控、做事左券等等。
如何将一个 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% 的流量，跑在公有云集群。
业务寻衅
文档的上云，分成了两个阶段。
第一阶段，弹内（即阿里集团内网络）和云上各有一个文档集群：弹内集群承接存量业务；云上集群承接增量业务。弹内集群同时起了代理的功能：对弹内的上游做事来说，弹内集群代理了对文档云上集群的调用；对云上集群来说，弹内做事代理了集团内下贱的依赖。
第一阶段：弹内、云上各有一个集群
第二阶段，存量数据迁移到了云上，只保留云上集群。上游做事、下贱依赖，都是通过 triple 协议直接调用。
第二阶段：只有一个云上集群
目前我们处于第一阶段。
在第一阶段，我们有几个诉求：
1、希望利用一套代码，跑在弹内、云上两个集群；
2、希望弹内集群连续利用 HSF 协议；
3、希望云上利用开源的 RPC 协议；
4、希望云上、弹内集群，可以互通。
而 Dubbo 3.0，完美的契合我们的需求。
落地方案
1、双集群
文档目前有两个集群。弹内集群暴露了 triple、hsf 双协议，云上集群仅暴露 triple 协议。
弹内的版本号保持 1.0.0 不变，云上利用 1.0.0.ZJK 的版本号。
对上游做事来说，只有弹内一个集群，所有流量都是打到弹内集群。这样上游业务无需做任何改造。
2、单元化路由
弹内做事，对到来的 HSF 要求进行拦截。如果解析出须要将要求路由到云上，则对云上做事发起一次 triple 调用。否则，连续将要求交给弹内的做事。
3、下贱依赖
文档有一些对弹内做事的依赖，去除不掉。目前的做法，是文档自己把下贱做事做一次封装，暴露出 triple 协议，供云上调用。
4、做事管理
做事互通完成了之后，便是开始看如何进行做事管理了。包括做事查询、做事测试、做事压测、做事限流、做事监控等。
4.1 MSE
做事查询、做事测试、做事路由等，都是通过接入 MSE 完成的。这里要特殊提一下 MSE 的做事测试。业务同学最开始是在本机 curl hsf 的 http 端口进行测试，非常麻烦，但是在接入 MSE 做事管理之后，就可以直接用 MSE 平台的做事测试功能。做事测试即为用户供应一个云上私网 Postman ，让用户能够轻松调用自己的做事。用户无需感知云上繁芜的网络拓扑构造，无需关系做事的协议，无需自建测试工具，只须要通过掌握台即可实现做事调用。支持 Dubbo 3.0 框架，以及 Dubbo 3.0 主流的 Triple 协议。
4.2 其他
由于云上利用了标准的 Dubbo 协议，Ahas、Arms 等中间件，都可以无缝的接入。
总结钉钉文档借助三位一体的红利实现三个月内快速上云，通过云产品办法产品化标准化地办理了上云过程中碰着的问题，借助 Dubbo3.0 的云原生特性，以及 MSE 做事管理能力的快速接入与支持，快速完成做事框架从互通到管理的落地。
原文链接：http://click.aliyun.com/m/1000297796/
本文为阿里云原创内容，未经许可不得转载。
