vivo 微服务架构实践之 Dubbo 性能优化-开发者社区

在Java技术栈场景，vivo主要基于 Apache Dubbo 框架来作为微服务之间的通信桥梁，在内部业务的大规模实践过程中，我们碰到了质量、性能和容量等方面的挑战，通过一系列的扩展与优化，较好的解决了相关问题，助力业务更好保障质量，节省算力成本，提升研发效率。

1分钟看图掌握核心观点👇

图1 VS 图2，您更倾向于哪张图来辅助理解全文呢？欢迎在评论区留言。

一、Dubbo 在 vivo 的演进历程

1.1 vivo 微服务现状

vivo自2015年通过微服务架构升级以赋能业务增长，通过全网治理，于2018年完成了全网Java技术栈RPC框架统一为Dubbo。目前，该架构高效支撑了5亿用户、覆盖60+地区的业务体量，实现了万级微服务在十万级机器上的稳定运行，日均RPC调用量高达8000亿次。

1.2 Dubbo在vivo的演进历史

Dubbo 是一款 RPC 服务开发框架，主要用于解决微服务架构中的通信与服务治理问题。它提供了服务定义，服务发现、负载均衡、流量管控等丰富能力。vivo在2015年，引入开源社区Dubbo作为Java技术栈RPC框架。而随业务规模发展，业务侧浮现框架版本碎片化现象，产生治理困难，维护成本高等问题。在19年，vivo引入开源社区2.7.* 版本发布作为第一个基线版本，对业务侧进行了版本收敛。随后发布两个大基线版本，分别为建设三中心分离能力，和应用级注册发现能力。

1.3 Dubbo执行核心链路（概要）

我们先简要介绍一下Dubbo的整体流程。流程可分为上下两部分。上半部分呈现了由提供方、消费方、注册中心和元数据中心，协同完成的服务注册与引入。下半部分为调用流程。Dubbo采用微内核与插件化设计，内部多个抽象层次。

总体而言，一次RPC流程可分为两类：

一是启动即就绪的静态过程（如代理生成、服务列表缓存）
二是每次调用均需动态计算的部分（如路由、负载均衡、序列化，编解码），这些常是性能热点。

二、Dubbo 路由扩展及优化

2.1 Dubbo路由简介

Dubbo路由是一套基于规则的精细化流量治理组件，其工作流程由服务治理侧向Dubbo下发路由策略，从而确保RPC请求能够被精准的路由至预期的服务实例列表。该机制是支撑灰度发布、机房容灾、环境隔离等流量治理能力的技术基石。开源版本的Dubbo提供了应用级标签路由、条件路由和脚本路由等核心路由能力。我们在其基础上，扩展实现了接口级标签路由与就近路由两种增强机制。

2.2 就近路由

2.2.1 就近路由背景说明

一般情况下，同机房内部的网络调用平均时延在0.1ms左右，而同城多机房间的平均时延在1ms-5ms，跨地域机房之间的网络时延则更大。假设内部服务存在大量跨机房调用，尤其针对rt敏感业务，可能因为请求延时的增加，影响服务质量用户体验。因此Dubbo就近路由应运而生，其可实现RPC过程优先使用同机房进行调用。可以看到上图，提供方在注册会上报机房信息，消费方调用经过就近路由，只匹配同机房的提供方节点列表。

2.2.2 就近路由场景分析

我们的理想方案如上方所示，是多机房共享注册中心，流量在就近路由的干涉下，在同机房内流转。但此方案面临下方两个问题：存在部分业务单机房部署现象，若强制进行同机房调用，会造成消费方无可用提供者。同时存在多机房非均匀部署现象，若机房间部署规模差异较大，同机房调用可能造成小规模部署机房的业务集群雪崩。

2.2.3 就近路由实践

为解决刚才的问题，我们最终实现如下：

中间件联合CI/CD侧，在提供方服务部署时上报机房信息。
消费方调用经过就近路由时会遍历提供方列表，优先筛选同机房提供方实例。
新增阈值判断，当同机房提供方机器规模低于阈值时，路由会自动降级进行全量访问。这样可以有效避免单机房部署的无提供者问题，以及降低非均匀部署时的集群雪崩风险。

用上边的三个请求举例，在就近路由阶段：

请求1 发现同机房提供者部署规模超过阈值，属于安全调用，直接过滤出01机房节点。
请求2 发现同机房无可用提供者，则直接触发降级规则，返回全量节点。
请求3 在就近路由阶段，发现同机房虽有可用提供者部署，但规模低于阈值，也直接触发降级规则，返回全量节点。

综上，就近路由通过简单的元数据标记和灵活的阈值规则，实现了流量的自动优化与隔离。其改造过程对业务代码无侵入，并带来延迟降低、网络带宽成本下降、稳定性提升的巨大收益。

2.3 标签路由能力说明

接下来是标签路由，标签路由是一种在微服务架构中用于实现流量精细控制的服务治理策略。

其核心思想是通过控制面为服务实例打上自定义标签，标签路由根据消费方调用时指定的标签，将请求流量路由到匹配这些标签的提供方实例。在Dubbo语义中，Dubbo标签分为动态标签与静态标签：如图所示，我们用通过配置中心下发动态标签，标记gray1包含a节点，标记gray2包含c节点，用于标识两个灰度环境。而提供方部署时可以自带静态标签，静态标签随Dubbo注册发现流程被消费方在内存缓存。

以三个请求举例：

请求1 指定了gray1，标签路由会遍历提供方列表与gray1对应的列表进行交集计算，最后过滤a节点。
请求2 指定gray3，标签路由发现无可用节点，则请求会降级到无标签的机器，最后过滤b,d,e节点。
请求3 未指定标签，说明是基线环境调用，标签路由会筛选未打标签的机器，最后过滤b,d,e节点。

2.4 我们发现的性能问题

在vivo大规模 Dubbo 提供方集群场景下，高峰期该业务消费方侧应用的整体 CPU 利用率约为60%，而其中负载均衡模块及路由模块的 CPU 占用率竟超过了30%！通过火焰图分析可以观察到这些问题存在共性：相关方法均涉及遍历操作，其时间复杂度与提供方节点数量成正相关。在大规模集群部署环境下，路由与负载均衡模块因遍历计算产生了明显的资源消耗。

2.4.1 路由优化实践--减少遍历运算

优化思路

降低消费方侧遍历次数：我们发现部分业务是完全不使用应用级标签路由的，而为了支持静态标签场景，应用级路由对于不带标签的请求，还是需要全量遍历，以筛选无静态标签的节点。这部分无效遍历会造成算力空转浪费。因此我们第一个优化是对此类业务关闭了应用级路由。

根据火焰图我们了解到，在负载均衡中，负载均衡器需要全量遍历节点以获取权重。那么这时我们可以试图降低参与负载均衡计算的节点数：在负载均衡前，我们新增了虚拟分组。当路由筛选后的实例规模超过阈值后，虚拟分组模块会将实例列表拆分成多个小规模分组，通过对分组随机选择，倍数级降低了进入负载均衡的节点数，降低了负载均衡遍历次数。