作者:刘军,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