共计 6645 个字符，预计需要花费 17 分钟才能阅读完成。
简介：服务框架就像铁路的铁轨一样，是互通的根底，只有解决了服务框架的互通，才有可能实现更高层的业务互通，所以用雷同的规范对立，合二为一并共建新一代的服务框架是必然趋势。Dubbo3.0 是 Dubbo2.0 与 HSF 交融而来，是阿里经济体面向外部业务、商业化、开源的唯一标准服务框架。
服务框架就像铁路的铁轨一样，是互通的根底，只有解决了服务框架的互通，才有可能实现更高层的业务互通，所以用雷同的规范对立，合二为一并共建新一代的服务框架是必然趋势。
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 服务治理能力的疾速接入与反对，疾速实现服务框架从互通到治理的落地。
尾
自研、商用、开源的“三位一体”，使得咱们在 双 11 中积淀的核心技术能够间接给到客户应用，省略了通过云上积淀再输入的过程，升高了客户获取“双 11 同款技术引擎”的门槛和老本，可帮忙客户疾速迈入数字原生时代。Dubbo3.0 正是在这个策略下的抉择，Dubbo3.0 和基于 Dubbo3.0 内核的 HSF 正在内部和外部齐头并进，为阿里云上、团体内、以及开源的用户提供最佳的用户体验，一起参加来打造最稳固的服务框架，在云原生时代下引领微服务的倒退。
原文链接
本文为阿里云原创内容，未经容许不得转载。
