共计 2581 个字符，预计需要花费 7 分钟才能阅读完成。
作者 | 刘军（陆龟）
起源 | 阿里巴巴云原生公众号
本文是一篇对于 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 的全面性能当先后，咱们将专一在迁徙计划的实现上，以反对老模型到新模型的平滑、通明迁徙。
