作者：李斌、邱炜

布景

咱们公司从 2015 年开端就使⽤ Dubbo 作为微服务结构，当社区推出 Dubbo 3 时，咱们也⽴刻跟进并做了深⼊调研，发现 Dubbo 3 的应⽤/实例级服务注册和发现形式能够在必定程度上处理咱们当时注册中⼼⾯临的压⼒，处理稳定性和安全性问题。一起 Dubbo 3 在服务办理上也做了晋级，契合云原⽣架构，⽽且 Dubbo 3 能够向下兼容 Dubbo 2，这也将下降晋级的本钱和⻛险。

晋级项目有了阶段性的发展，目前仍然在进行中。经过本⽂，咱们对公司内部的 Dubbo 3 晋级进程及收益等做了深⼊总结。

社区关于 Dubbo 3 的中心功用介绍

Dubbo 社区关于 Dubbo 3 的文档和材料越来越完善，以下是咱们从社区引用的一些内容。

下一代云原生服务结构

平安健康 Dubbo 3 升级、迁移和验证之路

Dubbo 3 被社区寄予厚望，将其视为下一代云原生服务结构打造，Dubbo 3 供给的中心特性列表，首要包括四部分。

  1. 全新服务发现模型。运用粒度服务发现，面向云原生规划，适配根底设施与异构体系；功用与集群伸缩性大幅提高。

  2. 下一代RPC协议 Triple。根据 HTTP/2 的 Triple 协议，兼容 gRPC；网关穿透性强、多语言友好、支撑 Reactive Stream。

  3. 一致流量办理模型。面向云原生流量办理，SDK、Mesh、VM、Container 等一致办理规矩；能够支撑更丰厚的流量办理场景。

  4. Service Mesh。在最新的3.1.0的版别中支撑Sidecar Mesh 与 Proxyless Mesh，供给更多架构挑选，下降搬迁、落地本钱。

平安健康 Dubbo 3 升级、迁移和验证之路

首要是功用、资源利用率的提高。社区材料显现，晋级 Dubbo 3 的运用预期能完结单机内存 50% 的下降，关于越大规模的集群作用将越显着，Dubbo 3 从架构上支撑百万实例等级的集群横向扩展，一起依赖运用级服务发现、Triple 协议等能够大大供给运用的服务办理功率和吞吐量。

其次，Dubbo 3 让事务架构晋级变得更容易、更合理，尤其是 RPC 协议，在 2.x 版别中，web、移动端与后端的通信都要经过网关代理，完结协议转换、类型映射等作业，Dubbo 3 的 Triple 协议让这些变得更容易与自然；并经过流式通信模型满意更多的运用场景。

终究，得益于 Dubbo 3 的完善云原生处理计划，Dubbo 3 的 Mesh 架构能够帮助事务屏蔽底层云原生根底设施细节，让事务更专注于事务，这也是 Mesh 的最根本的优势。

运用级服务发现中心原理

平安健康 Dubbo 3 升级、迁移和验证之路

咱们从Dubbo 最经典的作业原理图说起，Dubbo 从规划之初就内置了服务地址发现的才能，Provider 注册地址到注册中心，Consumer 经过订阅实时获取注册中心的地址更新，在收到地址列表后，Consumer 根据特定的负载均衡战略发起对 Provider 的 RPC 调用。

在这个进程中：

  1. 每个 Provider 经过特定的 key 向注册中心注册本机可拜访地址；
  2. 注册中心经过这个 key 对 Provider 实例地址进行聚合；
  3. Consumer 经过相同的 key 从注册中心订阅，以便及时收到聚合后的地址列表；

平安健康 Dubbo 3 升级、迁移和验证之路

再来看一下 Provider 向注册中心注册的 URL 地址的具体格式，这儿把 URL 地址数据区分成了几份：

  1. 首要是实例可拜访地址，首要信息包括 ip port，是消费端将根据这条数据生成 tcp 网络链接，作为后续 RPC 数据的传输载体。
  2. 其次是 RPC 元数据，元数据用于界说和描述一次 RPC 请求，标明这条地址数据是与某条具体的 RPC 服务有关的，它的版别号、分组以及办法相关信息。
  3. 下一部分是 RPC 装备数据，部分装备用于操控 RPC 调用的行为，还有一部分装备用于同步 Provider 进程实例的状况，典型的如超时时刻、数据编码的序列化办法等。
  4. 终究一部分是自界说的元数据，这部分内容差异于以上结构预界说的各项装备，给了用户更大的灵活性，用户可任意扩展并添加自界说元数据，以进一步丰厚实例状况。

结合以上关于 Dubbo 2 接口级地址模型的剖析，以及最开端的 Dubbo 根本原理图，能够得出这么几条定论：

  1. 地址发现聚合的 key 便是 RPC 粒度的服务。
  2. 注册中心同步的数据不止包括地址，还包括了各种元数据以及装备。
  3. 得益于 1 与 2 ，Dubbo 完结了支撑运用、RPC 服务、办法粒度的服务办理才能。

这便是一直以来 Dubbo 2 在易用性、服务办理功用性、可扩展性上强于许多服务结构的真实原因。

面对这样的地址数量级放大的问题，在 Dubbo 3 架构下，社区认真考虑了两个问题：

  1. 如何在保存易用性、功用性的一起，重新组织 URL 地址数据，防止冗余数据的呈现，让 Dubbo 3 能支撑更大规模集群水平扩容？
  2. 如何在地址发现层面与其他的微服务体系如 Kubernetes、Spring Cloud 打通？

平安健康 Dubbo 3 升级、迁移和验证之路

终究，社区给出的计划也是十分奇妙和经典。Dubbo 3 的运用级服务发现计划规划的根本思路是：地址发现链路上的聚合元素也便是之前提到的 Key 由服务调整为运用，这也是其称号叫做运用级服务发现的由来,与 Kubernetes 和 Spring Cloud 的服务注册发现处于同一粒度，能够滑润打通；别的，经过注册中心同步的数据内容上做了大幅精简，只保存最中心的 ip、port 地址数据。经过上述调整，运用等级服务发现在坚持接口级地址模型易用性的一起，完结了地址单条数据巨细和总数量的下降。

元数据、装备数据以及自界说数据等经过元数据中心或许 MetadataService 进行同步，且将所有的数据生成一个 Metadata Revision，假如 Metadata Revision 相同则以为元数据等信息相同，经过这种办法来下降元数据中心或 MetadataService 的拜访频次。

前期调研

了解了 Dubbo 3 的中心功用以及运用级服务发现的作业原理后，咱们开端进入前期作业阶段。

功用压测

从社区的材料来看，Dubbo 3 各方面都十分不错，可是咱们还得自己查验一次，所以咱们运用当时在用的 Dubbo 2 内部定制版和 Dubbo 3 的功用压测，压测的首要场景在于同步调用，异步场景只做了 Dubbo 3 的压测，以下压测数据和定论仅供参阅。

结果标明 Dubbo 3 在功用上面确实做了许多的优化，在相同 CPU 运用率的状况下，Dubbo 3 的 TPS 是要高于 Dubbo 2 的；TPS 适当的状况下，Dubbo 3 的 CPU 运用率要低于 Dubbo 2 。尤其是 Dubbo 2 的接口级与 Dubbo 3 的实例级，在 TPS 适当的状况下， Dubbo 3 的 CPU 运用率要较定制版的 Dubbo 2 低 20% 左右。

压测环境：

类别 版别 机器装备
Provider Dubbo 3.0.4 4C8G
Consumer Dubbo 3.0.4 4C8G
Provider Dubbo 2.5.3.22 （根据 2.5.3 版别定制） 4C8G
Consumer Dubbo 2.5.3.22 （根据 2.5.3 版别定制） 4C8G

测验场景：

运用的是 Dubbo 协议，接口没有其它逻辑，直接将输入回来给顾客，接口数据包巨细 500B ，每个场景压 30 分钟。

测验数据 (仅供参阅)：

平安健康 Dubbo 3 升级、迁移和验证之路

晋级前调研

做了压测得到 Dubbo 2 和 Dubbo 3 的压测数据后，咱们开端计划将 Dubbo 3 引进公司进行试点，此时，咱们需求考虑 Dubbo 3 与 Dubbo 2 的兼容和搬迁重构问题，晋级方针，以及 Dubbo 3 供给有哪些才能支撑晋级和搬迁。

  • 晋级的兼容和搬迁重构问题

考虑到公司的体系规模，要将 Dubbo 2 晋级到 Dubbo 3 却不是一个简单的进程，尤其是公司的 Dubbo 2 版别在原开源版别根底之上做了不少优化和扩展，涵盖了 OPS 服务办理、Monitor 数据方针监控、服务注册和发现、RPC 灰度路由、链路剖析、序列化编解码、作为其他根底结构的底层支撑等多个方面。一起 Dubbo 3 社区也处于活跃的状况，咱们也期望能够继续享受 Dubbo 社区的技术红利，在这样的布景下不得不考虑三个问题：

  1. 需求处理公司版别的 Dubbo 2 与 Dubbo 3 的兼容问题
  2. 原有功用的搬迁重构问题
  3. 不在 Dubbo 3 的源码上做改动，坚持和社区版别一致

得益于 Dubbo 良好的扩展才能，咱们能够经过 Dubbo 的 SPI 和 IoC 模块在 Dubbo 3 的根底之上高雅的兼容公司版别的 Dubbo 2 ，不必改动 Dubbo 3 源码，只需研制 Dubbo 3 扩展包跟从 Dubbo 3 版别的 API 晋级即可，这个晋级改动的本钱和从社区获取红利相比是比较小的。

  • 晋级方针

已然前史包袱的处理计划已经有了，那么就要考虑晋级的方针了。首要确认的是，终究咱们将会选用实例级的服务注册和服务发现，其次咱们目前运用的注册中心是 Zookeeper，而 Dubbo 社区更引荐运用的注册中心是 Nacos，而且咱们在验证阶段时也露出过几个在 Zookeeper 上呈现而在 Nacos 上没有呈现的问题，这也使得咱们开端考虑将来是否将注册中心终究也搬迁到 Nacos 上。

一起，咱们也期望整个搬迁进程是滑润、可控的，咱们整体计划也要将危险把控作为中心关键考虑，尽可能的做到失利降级、实时可控。

综上，咱们将晋级的方针概括为下面几点：

  1. 滑润的从 Dubbo 2 晋级到 Dubbo 3
  2. 将接口级服务注册和发现形式滑润的搬迁到运用级服务注册和发现形式为
  3. 后边滑润搬迁注册中心做好预备
  4. 搬迁进程可监控、可观测。
  5. 搬迁进程要可灰度、可实时管控
  6. 一致 Dubbo 3 的通用装备标准，尽量适配原 Dubbo 2 的 Export 和 Refer 办法。
  • Dubbo 3 关于搬迁的支撑才能

前面介绍的是咱们的方针，可是如何把 Dubbo 3 的原生规划理念融入到现实状况中呢？以下是咱们的相关考虑，并在验证进程中。

首要 Dubbo 3 能够支撑在 RegistryUrl 上经过参数办理 Provider 和 Consumer 以不同的形式进行服务注册和服务发现，其中中心参数名有: registry-type, registry-protocol-type, register-mode。

其次，Dubbo 3 能够支撑运用多个注册中心，不同的注册中心经过上面的 RegistryUrl 参数操控注册中心的服务注册形式和服务发现形式。而且还能够经过 ProviderConfig 和 ConsumerConfig 这两个这两个 Config 类别离办理 Provider 侧和 Consumer 侧运用的注册中心。在 Consumer 侧，假如有运用多个注册中心，默许会运用 ZoneAwareCluster 创建的 ZoneAwareClusterInvoker 来进行负载均衡，从类名上能够看出，该 ClusterInvoker 是有供给区域感知的才能，查看源码时发现它还供给了 preferred 的功用，只在相应的 registryUrl 中添加了 preferred=true，这个registryUrl 创建的 ClusterInvoker 就会被优先调用。

在同一注册中心进行接口级搬迁到实例级的场景中， Dubbo 3 的 MigrationInvoker 也供给了相应的支撑，MigrationInvoker 能够根据 MigrationRule 来操控实例级的 RPC 流量，并且根据 MigrationRuleListener 能够实时监听到指定运用的 MigrationRule 的改变。

关于 RPC 的监控在 Dubbo 中一直由 MonitorFilter 和 DubboMonitor 供给 RPC 监控数据的搜集和上报，搜集的数据有顾客的 ip 端口、供给者的 ip 端口、运用称号、DubboService、Method、以及成功数、失利数、输入字节数、输出字节数、耗时、并发数等。

这些才能能够满意根本的搬迁作业，结合咱们的现状来看，相对晋级方针要求的滑润搬迁，搬迁流量可观测、可灰度、可管控还有一些距离，不过在梳理 Dubbo 3 这块才能的时分，也找到了相对简单的扩展计划。到此，关于整体的搬迁计划也有了一个大致的雏形。

晋级&搬迁计划规划

计划的规划要点放在 “滑润、可控” 两点，根据 Dubbo 3 的新架构，目前正在验证中的搬迁计划示意图如下：

平安健康 Dubbo 3 升级、迁移和验证之路

从上图能够看出，在整个晋级搬迁的进程中，运用域中会存在多个 Dubbo 版别，Dubbo 3 是能够兼容社区的 Dubbo 2 版别，而咱们公司内部的 Dubbo 2 版别是根据 Dubbo 2.5.3 开源版别深度定制过的，在 OPS 服务办理、Monitor 数据方针监控、服务注册和发现、 RPC 灰度路由、序列化编解码等方面都做了扩展定制，咱们的思路是由 Dubbo 3 根据 Dubbo 的 SPI 选用扩展的办法或许 ExtensionLoader 的 Wrapper 形式去兼容定制版的 Dubbo2。

除了运用外，在 Dubbo 3 的架构根底上区分了 3 个逻辑域，别离是注册域、装备管控域和监控域。

注册域首要服务于服务的注册和发现，例如 Provider 在 DubboService 露出时，将服务信息和元数据信息上签到注册域的注册中心和元数据中心，Consumer 经过注册中心和元数据中心来发现服务。装备管控域首要是办理运用装备和搬迁流量管控，Dubbo 3 供给的装备中心支撑自身才能的装备，所以流量规矩的装备由Dubbo 3 的装备中心进行保护，Dubbo 3 的 DynamicConfigration 供给了许多关于动态装备的办法能够直接运用。监控域除了原 RPC 流量的监控外，还细分了搬迁流量的监控，在搬迁进程中，能够经过监控直观的看到搬迁流量的现状，呈现问题时，也能够及时报警告诉相关人员介入。

整个晋级进程分为 3 个阶段：

  • 第一阶段：将 Dubbo 2 晋级到 Dubbo 3 的接口级，验证功用、兼容性、功用和稳定性
  • 第二阶段：接口级和运用级双注册，经过 MigrationRule 和 RegistryMigrationRule 办理RPC流量
  • 第三阶段：全面切换到运用级，撤掉MigrationRule 和 RegistryMigrationRule

Dubbo 3 扩展兼容 Dubbo 2 定制版别

考虑到 Dubbo 3 社区版别的迭代状况，终究决定 Dubbo 3 兼容 Dubbo 2 定制版别的插件以 SDK 的办法独自保护，完结兼容的扩展功用首要有如下内容：

  1. RPC 正向透递与反向透传

在 Consumer 侧和 Provider 侧扩展 Filter 接口完结类，为正向与反向透传数据完结其发送和接纳的功用。Dubbo 2 定制版是在序列化编解码层面对 RpcResult 进行了修正，要兼容这一逻辑也只能在序列化编解码层面去支撑，选用 Wrapper 形式对 Codec2 这个 SPI 进行增强，与其它扩展类同时完结该兼容功用。

  1. RPC 灰度路由

扩展 Dubbo 的 Router、 Cluster 和ConfiguratorFactory 等 SPI，与内部的 eunomia 灰度管控渠道集成完结 RPC 灰度路由，替换并兼容掉原 Dubbo 2 定制版在其源码层面修正完结的灰度路由功用。

  1. Monitor数据方针监控

扩展 Protocol、MonitorFilter、Monitor 等 SPI，与内部的监控中心完结对接，与 Dubbo 2 定制版的监控逻辑坚持一致。

  1. OPS 支撑实例级

在 OPS 层面，除了要兼容原接口级的服务管控外，还要添加实例级的服务管控。

  1. 其它中间件兼容

除了 Dubbo 自身的兼容外，内部还有部分自研的中间件也是有依赖 Dubbo 或许跟 Dubbo 有相关的，还要对这些中间件进行改造晋级。

搬迁扩展

在 Dubbo 3 原有才能根底上，也要别的进行扩展以供给滑润搬迁的才能，咱们构想的规划计划如下：

  1. 扩展支撑注册中心的搬迁可灰度、可管控

在 Dubbo 3 中，当 Consumer 侧运用了多个注册中心时，默许会经过 ZoneAwareCluster 创建 ZoneAwareClusterInvoker 来进行负载均衡，参阅其完结能够扩展一个 Cluster 完结类和一个 ClusterInvoker 完结类将 ZoneAwareCluster 替换掉，注册中心搬迁的流量办理、灰度、降级等才能都在扩展的 ClusterInvoker 中去完结。

  1. 扩展支撑接口级到实例级搬迁规矩的全局装备办理

MigrationRule 由 MigrationRuleListener 经过 DynamicConfiguration 监听指定的运用的搬迁规矩，假如一个体系拥有成百上千个微服务运用时，由这种办法去办理，保护本钱将会变高，咱们学习这个办法完结了全局等级的 MigrationRule 办理才能。

  1. 扩展搬迁流量可观测、可报警

Dubbo RPC 的流量监控已经有 MonitorFilter 和 DubboMonitor 完结了，仅仅 MonitorFilter 不能识别本次 RPC 请求的 Invoker 对象是经过哪个注册中心进行服务发现的，以及该 Invoke 对象的服务发现形式是接口级还是实例级的；咱们在 Consumer 侧新增一个 ClusterFilter 接口和 Filter 接口去完结这个识别逻辑。

  1. 搬迁组件开关

在扩展的终究，要考虑搬迁组件下线的问题，即使要下线也不可能再次调整事务工程将搬迁组件全部从依赖中删除掉，所以需求经过开关操控搬迁组件的功用下线。

装备一致办理

在晋级和搬迁进程中，咱们可能会随时调整注册中心和搬迁规矩的装备参数，为削减犯错的危险以及事务工程晋级改动的作业量，这些公共的装备需求一致办理保护起来，Dubbo 3 的装备中心正常能够把这个任务较好的承接下来。

终究咱们又扩展了一个装备加载的组件，经过咱们公司内部的装备中心办理保护搬迁组件的开关和装备中心的衔接地址与超时等装备参数。有了这个组件后，新的运用能够不必担心 Dubbo 3 和搬迁的公共装备，老的运用也削减了这部分公共装备的调整作业量。

危险预案

Dubbo 作为一个供给底层支撑才能的微服务结构，咱们一直把稳定性的要求放在首位，晋级进程中任何一点意外，都可能导致线上问题，所以咱们整个计划都是在面向失利、面向危险规划的。除了在扩展的搬迁组件中完结了自动降级外，也侧重考虑了一些极端状况，一起为这些极端状况供给危险预案。线上环境可能会呈现各种意想不到的状况，在搬迁进程中需求预先考虑各种危险，预备完善的应对处理预案，确保体系快速康复。

小结

Dubbo 2 是一个优秀的微服务结构，供给的 SPI 以及 Extension 机制能够十分方便的让用户去扩展完结想要功用。Dubbo 3 在其根底之上，丰厚了不少新的 SPI ，咱们花了很长的时刻去规划搬迁计划，真实花在搬迁组件上的开发时刻较短。

Dubbo 3 整体架构晋级调整关于过去的服务注册压力也得到了处理。功用上也做了优化，架构晋级后的 Dubbo 3 也更习惯目前云原生的架构，Dubbo 3.1.x 版别支撑 Sidecar 和 Proxyless 的 Mesh 计划，而且社区也在预备开源 Java Agent 办法的 Proxyless，这样就能较好的将微服务架框的 Framework 与数据面解耦，下降微服务结构的保护本钱和晋级本钱。

社区协作

目前该项目仍然在继续晋级中，咱们跟社区坚持着严密的联系，期间碰到不少问题，都得到了社区开发同学耐⼼解答并终究给予处理。

关于要晋级 Dubbo3 的⽤户，能够在社区的 Github 置顶 Issue 进⾏挂号。