Dubbo 3.0 前瞻系列：服务发现支持百万集群，带来可伸缩微服务架构

做者 | 刘军（陆龟）
来源|阿里巴巴云原生公众号

本文是一篇关于 Dubbo 地址推送性能的压测文章，咱们指望经过对比的方式展示 Dubbo3 在性能方面的提高，尤为是新引入的应用级地址模型。但要注意，这并非官方正式版本的性能参考基线，而且因为环境和时间缘由，部分对比数据咱们并无采集，但只要记住咱们只是在定性的检测阶段成果，这些限制整体上并不会有太大影响。

摘要

本文主要围绕下一代微服务框架 Dubbo 3.0 在地址推送链路的性能测试展开，也是在性能层面对 Dubbo 3.0 在阿里落地过程当中的一个阶段性总结，本轮测试了 Dubbo2 接口级地址发现、Dubbo3 接口级地址发现、Dubbo3 应用级地址发现。压测数据代表，在百万实例地址的压测场景下：

• 基于接口级地址发现模型，Dubbo3 与 Dubbo2 对比，有超过 50% 常驻内存降低，Full GC 间隔更是明显拉长。

• Dubbo3 新引入的应用级服务发现模型，能够进一步实如今资源占用方面的大幅降低，常驻内存比 Dubbo3 接口级地址进一步降低 40%，应用实例扩缩容场景增量内存分配基本为零，相同周期内（1 小时） Full GC 减小为 2 次。

Dubbo 3.0 做为将来支撑业务系统的核心中间件，其自身对资源占用率以及稳定性的提高对业务系统毫无疑问将带来很大的帮助。

背景介绍

1. 下一代服务框架 Dubbo 3.0 简介

一句话归纳 Dubbo 3.0：它是 HSF & 开源 Dubbo 后的融合产品，在兼容两款框架的基础上作了全面的云原生架构升级，它将成为将来面向阿里内部与开源社区的主推产品。

Dubbo 3.0 诞生的大背景是阿里巴巴在推进的全站业务上云，这为咱们中间件产品全面拥抱云上业务，提供内部、开源一致的产品提出了要求也提供了契机，让中间件产品有望完全摆脱自研体系、开源体系多线做战的局面，有利于实现价值最大化的局面。一方面阿里电商系统大规模实践的经验能够输出到社区，另外一方面社区优秀的开发者也能参与到项目贡献中。以服务框架为例，HSF 和 Dubbo 都是很是成功的产品：HSF 在内部支撑历届双十一，性能优异且久经考验；而在开源侧，Dubbo 坐稳国内第一开源服务框架宝座，用户群体很是普遍。

同时维护两款高度同质化的产品，对研发效率、业务成本、产品质量与稳定性都是很是大的考验。举例来讲，首先，Dubbo 与 HSF 体系的互通是一个很是大的障碍，在阿里内部的一些生态公司如考拉、饿了么等都在使用 Dubbo 技术栈的状况下，要实现顺利平滑的与 HSF 的互调互通一直以来都是一个很是大的障碍；其次，产品不兼容致使社区输出成本太高、质量验收等成本也随之增加，内部业务积累的服务化经验与成果没法直接赋能社区，二次改造适配 Dubbo 后功能性、稳定性验收都要从新投入验证。为完全解决以上问题，结合上文提到的阿里集团业务总体上云、开源以及云产品输出战略，咱们制定了全面发展 Dubbo 3.0 的计划。

2. Dubbo 不一样版本在地址推送链路上的性能压测与对比

下图是服务框架的基本工做原理，橙色路径即为咱们这次重点压测的地址推送链路，咱们重点关注在百万地址实例推送的状况下，Dubbo 不一样版本 Consumer 间的差别，尤为是 Dubbo 3.0 的实际表现。

做为对比，咱们选取了如下场景进行压测：

• Dubbo2，这次压测的参考基线
• Dubbo3 接口级地址发现模型，与 Dubbo2 采用的模型相同
• Dubbo3 应用级地址发现模型，由云原生版本引入，详细讲解请参见这篇文章

压测环境与方法

• 压测数据

本次压测模拟了 220w（接口级）集群实例地址推送的场景，即单个消费端进程订阅 220w 地址。

• 压测环境

8C16G Linux，JVM 参数中堆内存设置为 10G。

• 压测方法

Consumer 进程订阅 700 个接口，ConserverServer 做为注册中心按必定比例持续模拟地址变动推送，持续时间 1 hour+，在此过程当中统计 Consumer 进程以及机器的各项指标。

优化结果分析与对比

1. GC 耗时与分布

Dubbo2 接口级地址模型

Dubbo3 接口级地址模型

Dubbo3 应用级地址模型

2. 增量内存分配状况

Dubbo2 接口级地址模型

Dubbo 3.0 接口级地址模型

Dubbo3 应用级地址模型

3. OLD 区与常驻内存

Dubbo2 接口级模型

Dubbo3 接口级模型

Dubbo3 应用级模型

4. Consumer 负载

Dubbo3 接口级模型

Dubbo3 应用级模型

详细对比与分析

1. Dubbo2 接口模型 VS Dubbo3 接口模型

在 200w 地址规模下，Dubbo2 很快吃满了整个堆内存空间，而且大部分都没法获得释放，而由此触发的频繁的 GC，使得整个 Dubbo 进程已没法响应，所以咱们压测数据采集也没有持续很长时间。

一样保持接口级地址模型不变，通过优化后的 Dubbo3 ，在 1 个小时以内只有 3 次 Full GC，而且持续推送期间不可释放内存大概降低在 1.7G。

2. Dubbo3 接口模型 VS Dubbo3 应用模型

当切换到 Dubbo3 应用级服务发现模型后，整个资源占用状况又出现了明显降低，这体如今：

• 应用进程上下线场景，增量内存增加很小 (接口级的 MetadataData 基本获得彻底复用，新增部分仅来自新扩容机器或部分服务的配置变动)。

• 常驻内存相比 Dubbo3 接口级又降低了近 40%，维持在 900M 左右。

值得一提的是，当前的应用级地址推送模型在代码实现还有进一步优化的空间，好比 Metadata 复用、URL 对象复用等，这部分工做将是咱们后续探索的重点。

总结

Dubbo 3.0 目前已经实现了 Dubbo&HSF 的全面融合，云原生方案也在全面推动中。在刚刚过去的双十一中，Dubbo 3.0 平稳支撑了考拉业务，而且也已经经过阿里其余一些电商应用的部分线上试点。后续咱们将专一在推进 Dubbo 3.0 的进一步完善，一方面兑现应用级服务发现、全新服务治理规则、下一代 Triple 协议等，另外一方面兑现咱们立项之初设定的资源占用、性能、集群规模等非功能性目标。

这次推送链路的性能压测，是落地/研发过程当中的一次阶段性验收，应用级服务发如今资源占用方面大幅降低，让咱们看到了新架构对将来构建真正可伸缩集群的可行性，这更坚决了咱们对应用级服务发现架构的信心。后续迭代中，在继续完善接口级、应用级两种模型并实现 Dubbo 3.0 的全面性能领前后，咱们将专一在迁移方案的实现上，以支持老模型到新模型的平滑、透明迁移。