作者：刘军，Github账号Chickenlj，Apache Dubbo PMC，项目核心维护者。现任职阿里云云原生应用平台团队，参与服务框架、微服务相关工作，目前主要在推动 Dubbo 3.0 项目演进。
背景
Dubbo 3.0 已于近期发布首个正式 Release 版本，在保持低版本兼容的同时，提供了包括应用级服务发现、Triple 协议、统一路由规则等新特性。
Dubbo 3.0 的新特性、新架构，总的来说，都是围绕两个主要设计原则或是为解决两类问题：
（1）提升 Dubbo 3.0 在大规模集群实践中的性能与稳定性。解决 HSF2 在应用中单机内存占比过高、可支持集群规模达到上限的问题，以更少的资源支持现有集群规模，新架构支撑未来更大规模的集群实例。
（2）给出云原生微服务解决方案、迁移路径与最佳实践。整个技术栈都面临云原生升级，尤其是一些基础设施已经完成云原生升级，而我们的业务和产品在现在或未来也会面临云原生升级诉求，Dubbo 3.0 作为微服务体系的重要一环，需要给出云原生解决方案、迁移路径与最佳实践。
Dubbo 3.0 在大规模集群方面的表现得到了很多社区用户的关注，尤其是一些超大规模的集群实践用户，他们期望通过 Dubbo 3.0 的新特性来解决遇到的集群伸缩与资源利用率问题。工商银行是我们社区合作的典型用户，在试点 3.0 应用级服务发现的过程中，我们联合工商银行发布了一套针对应用级服务发现的 Benchmark 数据，从结果来看，应用级服务发现很好的解决了大规模集群实践中的资源占用问题。
下文将着重介绍应用级服务发现的 Benchmark 情况。
Benchmark 结论
对比 2.x 版本，Dubbo 3.0 版本的服务发现资源利用率显著提升。
- 对比接口级服务发现，单机常驻内存下降 50%，地址变更期 GC 消耗下降一个数量级 (百次 -> 十次)
- 对比应用级服务发现，单机常驻内存下降 75%，GC 次数趋零
应用级服务发现简介
Dubbo 3.0 引入一套全新的服务发现模型 - 应用级服务发现，该模型主要有以下量大优势
- 适配云原生微服务变革。云原生时代的基础设施能力不断向上释放，像 Kubernetes 等平台都集成了微服务概念抽象，Dubbo 3.0 的应用级服务发现是适配各种微服务体系的通用模型。
- 提升性能与可伸缩性。支持超大规模集群的服务治理一直以来都是 Dubbo 的优势，通过引入应用级服务发现模型，从本质上解决了注册中心地址数据的存储与推送压力，相应的 Consumer 侧的地址计算压力也成数量级下降；集群规模也开始变得可预测、可评估（与 RPC 接口数量无关，只与实例部署规模相关）。
应用级服务发现并未改变 Dubbo 地址发现的基本流程，仍旧是 Provider 注册地址到 Registry，Consumer 通过 Registry 感知地址列表变化，变化的地方在于 Provider、Consumer 与 Registry 交互过程中的数据组织格式与力度，简单来说，就是由原来的接口级别切换到了应用级别。
应用级服务发现从设计上可大幅降低资源消耗，支持百万规模实例的横向扩容，从设计层面分析，预期可降低注册中心 90% 存储与推送压力，降低单机至少 50% 以上的资源消耗。
这里先举个简单的例子，来直观的对比 Dubbo 2.0 与 Dubbo 3.0 在地址发现流程上的数据流量变化：
假设一个微服务应用定义了 100 个接口（Dubbo 中的服务）， 则需要往注册中心中注册 100 个服务，如果这个应用被部署在了 100 台机器上，那这 100 个服务总共会产生 100 * 100 = 10000 个虚拟节点；而同样的应用， 对于 Dubbo 3.0 来说，新的注册发现模型只需要 1 个服务（只和应用有关和接口无关）， 只注册和机器实例数相等的 1 * 100 = 100 个虚拟节点到注册中心。
在这个简单的示例中，Dubbo 所注册的地址数量下降到了原来的 1 / 100，对于注册中心、订阅方的存储压力都是一个极大的释放。更重要的是， 地址发现容量彻底与业务 RPC 定义解耦开来，整个集群的容量评估对运维来说将变得更加透明：部署多少台机器就会有多大负载，不会像 Dubbo2 一样， 因为业务 RPC 重构就会影响到整个集群服务发现的稳定性。
详细压测环境
此部分压测数据是由工商银行 Dubbo 团队基于内部生产数据给出，压测过程模拟了“生产环境地址+zookeeper”的服务发现架构。
4.1 环境
压测数据 |
提供者 500运行实例✖️8interface✖️5protocol，即每个提供者向注册中心注册40个URL，总计20000个URL，每个URL字符长度约1k。 注册中心 2个独立zookeeper注册中心，服务提供者消费者采用并行配置。 消费者 配置1c2g，xmx=768，开启GC，从2个注册中心订阅，每5秒调用一次服务。运行20小时。 |
压测环境 |
Java version "1.8.0" Java(TM) SE Runtime Enviroment (build pxa6480sr3fp12-20160919_01(SR3 FP12)) IBM J9 VM (Build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796, JIT enabled, AOT enabled) |
4.2 压测架构
以下是此次压测的两种基本架构，我们通过模拟一定规模的 Provider 实例集群，分别统计 Consumer 端：
- Provider 实例变更过程中 Consumer 实例的 GC 与资源消耗，这部分体现应用级服务发现模型在地址推送过程中的资源消耗下降。
- 在 provider 集群达到稳态后，Consumer 实例的常驻内存消耗，这部分体现应用级服务发现模型在节省最终内存占用方面的优势。
Dubbo 2.0 接口级服务发现模型，压测架构
Dubbo 3.0 应用级服务发现模型，压测架构
4.3 数据分析
图一 服务发现模型内存占用变化
- Dubbo 3.0 接口级服务发现模型，常驻内存较 2.x 版本下降约 50%；
- Dubbo 3.0 应用级服务发现模型，常驻内存较 2.x 版本下降约 75%。
图二 服务发现模型 GC 变化
- Dubbo 3.0 接口级服务发现模型，YGC 次数 2.x 版本大幅下降，从数百次下降到十几次；
- Dubbo 3.0 应用级服务发现模型，FGC 次数 2.x 版本大幅下降，从数百次下降到零次。
总结
Benchmark 印证了 Dubbo 3.0 在超大规模集群实践层面的巨大优势，单机常驻内存下降达 75%，注册中心总体数据量下降超 90%。后续我们还将联合社区用户发布更多的 benchmark 数据，如 Triple 协议等，敬请关注。
更多 Dubbo 相关内容，欢迎进群讨论~钉钉群号：21976540
