本篇是 Apache Dubbo 的实践案例。感兴趣的朋友可以访问官网了解更多详情，或搜索关注官方微信公众号 Apache Dubbo 跟进最新动态。

1 背景

我们公司从15年开始就使?dubbo作为微服务框架，当社区推出dubbo3时，我们也?刻跟进并做了深?调研，发现dubbo3 的应?/实例级服务注册和发现模式能够在一定程度上解决我们当前注册中??临的压?，解决稳定性和安全性问题。同时dubbo3在服务治理上也做了升级，契合云原?架构，?且dubbo3能够向下兼容dubbo2，这也将降低升级的成本和?险。

升级项目有了阶段性的进展，目前仍然在进行中。通过本?，我们对公司内部的Dubbo3 升级过程及收益等做了深?总结。

2 Dubbo3 核?功能介绍

dubbo社区关于dubbo3的文档和资料越来越完善，以下是我们从社区引用的一些内容。

2.1 下一代云原生服务框架

Dubbo3被社区寄予厚望，将其视为下一代云原生服务框架打造，Dubbo3 提供的核心特性列表，主要包括四部分。

• 全新服务发现模型 。应用粒度服务发现，面向云原生设计，适配基础设施与异构系统；性能与集群伸缩性大幅提升。
• **下一代 **** RPC **协议 Triple 。基于 HTTP/2 的 Triple 协议，兼容 gRPC；网关穿透性强、多语言友好、支持 Reactive Stream。
• 统一流量治理模型 。面向云原生流量治理，SDK、Mesh、VM、Container 等统一治理规则；能够支持更丰富的流量治理场景。
• Service Mesh 。在最新的3.1.0的版本中支持Sidecar Mesh 与 Proxyless Mesh，提供更多架构选择，降低迁移、落地成本。

首先是性能、资源利用率的提升。社区资料显示，升级 Dubbo3 的应用预期能实现单机内存 50% 的下降，对于越大规模的集群效果将越明显，Dubbo3 从架构上支持百万实例级别的集群横向扩展,同时依赖应用级服务发现、Triple协议等可以大大提供应用的服务治理效率和吞吐量。

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

最后，得益于 Dubbo3 的完善云原生解决方案，Dubbo3的mesh架构可以帮助业务屏蔽底层云原生基础设施细节，让业务更专注于业务，这也是mesh的最根本的优势。

2.2 应用级服务发现核心原理

我们从 Dubbo 最经典的工作原理图说起，Dubbo 从设计之初就内置了服务地址发现的能力，Provider 注册地址到注册中心，Consumer 通过订阅实时获取注册中心的地址更新，在收到地址列表后，consumer 基于特定的负载均衡策略发起对 provider 的 RPC 调用。 在这个过程中

• 每个 Provider 通过特定的 key 向注册中心注册本机可访问地址；
• 注册中心通过这个 key 对 provider 实例地址进行聚合；
• Consumer 通过同样的 key 从注册中心订阅，以便及时收到聚合后的地址列表；

再来看一下Provider向注册中心注册的 URL 地址的详细格式，这里把 URL 地址数据划分成了几份：

• 首先是实例可访问地址，主要信息包含 ip port，是消费端将基于这条数据生成 tcp 网络链接，作为后续 RPC 数据的传输载体。
• 其次是 RPC 元数据，元数据用于定义和描述一次 RPC 请求，表明这条地址数据是与某条具体的 RPC 服务有关的，它的版本号、分组以及方法相关信息。
• 下一部分是 RPC 配置数据，部分配置用于控制 RPC 调用的行为，还有一部分配置用于同步 Provider 进程实例的状态，典型的如超时时间、数据编码的序列化方式等。
• 最后一部分是自定义的元数据，这部分内容区别于以上框架预定义的各项配置，给了用户更大的灵活性，用户可任意扩展并添加自定义元数据，以进一步丰富实例状态。

结合以上对于 Dubbo2 接口级地址模型的分析，以及最开始的 Dubbo 基本原理图，可以得出这么几条结论：

• 第一，地址发现聚合的 key 就是 RPC 粒度的服务。
• 第二，注册中心同步的数据不止包含地址，还包含了各种元数据以及配置。
• 得益于 1 与 2，Dubbo 实现了支持应用、RPC 服务、方法粒度的服务治理能力。

这就是一直以来 Dubbo2 在易用性、服务治理功能性、可扩展性上强于很多服务框架的真正原因。

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

• 如何在保留易用性、功能性的同时，重新组织 URL 地址数据，避免冗余数据的出现，让 Dubbo3 能支撑更大规模集群水平扩容？
• 如何在地址发现层面与其他的微服务体系如 Kubernetes、Spring Cloud 打通？

最终，社区给出的方案也是非常巧妙和经典。Dubbo3 的应用级服务发现方案设计的基本思路是：地址发现链路上的聚合元素也就是之前提到的 Key 由服务调整为应用，这也是其名称叫做应用级服务发现的由来,与kubernetes和spring cloud的服务注册发现处于同一粒度，能够平滑打通；另外，通过注册中心同步的数据内容上做了大幅精简，只保留最核心的 ip、port 地址数据。 经过上述调整，应用级别服务发现在保持接口级地址模型易用性的同时，实现了地址单条数据大小和总数量的下降。

元数据、配置数据以及自定义数据等通过元数据中心或者MetadataService进行同步，且将所有的数据生成一个metadata revision, metadata revision相同则认为元数据等信息相同，通过这种方式来降低元数据中心或MetadataService的访问频次。

3 前期调研

了解了 Dubbo3 的核心功能以及应用级服务发现的工作原理后，我们开始进入前期工作阶段。

3.1 性能压测

从社区的资料来看，dubbo3各方面都非常不错，但是我们还得自己检验一次，所以我们使用当前在用的dubbo2内部定制版和dubbo3的性能压测，压测的主要场景在于同步调用，异步场景只做了dubbo3的压测， 以下压测数据和结论仅供参考 。结果表明dubbo3在性能上面确实做了很多的优化，在相同cpu使用率的情况下，dubbo3的tps是要高于dubbo2的；tps相当的情况下，dubbo3的cpu使用率要低于dubbo2。尤其是dubbo2的接口级与dubbo3的实例级，在tps相当的情况下，dubbo3的cpu使用率要较定制版的dubbo2低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.222(基于2.5.3版本定制)	4C8G

测试场景：

使用的是Dubbo协议，接口没有其它逻辑，直接将输入返回给消费者, 接口数据包大小500B，每个场景压30分钟。

测试数据 (仅供参考)：

3.2 升级前调研

做了压测得到dubbo2和dubbo3的压测数据后，我们开始计划将 Dub