Dubbo 运行原理

最新推荐文章于 2025-06-02 15:04:56 发布

weixin_34278711

最新推荐文章于 2025-06-02 15:04:56 发布

阅读量1.1k

点赞数 26

CC 4.0 BY-SA版权

文章标签： dubbo

本文链接：https://blog.youkuaiyun.com/weixin_34278711/article/details/141677749

Dubbo 是一款高性能、轻量级的开源 RPC（远程过程调用）框架，主要用于构建分布式服务和微服务架构。那 Dubbo 又是如何运行的呢？让我们一起来看。

# 1.核心组件

要说 Dubbo 运行流程就不得不先来了解一下 Dubbo 的核心组件了，因为 Dubbo 的交互流程是和核心组件息息相关的。

Dubbo 核心组件有以下几个：

服务提供者（Provider）：暴露服务的应用，通过 Dubbo 框架将自身的服务接口及实现注册到注册中心。
服务消费者（Consumer）：调用远程服务的应用，从注册中心订阅所需的服务，然后通过远程调用消费服务。
注册中心（Registry）：集中管理服务的地址信息，服务提供者和服务消费者均在此注册或订阅服务信息。常见的注册中心有 ZooKeeper、Nacos 等。

# 2.运行流程

Dubbo 运行流程如下图所示：

它的执行流程如下：

服务提供者会将实例（URL 地址）注册到注册中心，注册中心负责对数据进行聚合（健康检测）。
消费者从注册中心读取地址列表并订阅变更，每当地址列表发生变化，注册中心将最新的列表通知到所有订阅的消费者实例。
消费者得到服务实例之后，通过 Dubbo 内置的负载均衡策略，选择其中的一个节点，之后使用 RPC 的方式与服务提供者建立连接，并进行通讯和服务调用。

更详细的调用流程如下：

# 3.支持的通讯协议

Dubbo 框架提供了自定义的高性能 RPC 通信协议：基于 HTTP/2 的 Triple 协议和基于 TCP 的 Dubbo2 协议。除此之外，Dubbo 框架支持任意第三方通信协议，如官方支持的 gRPC、Thrift、REST、JsonRPC、Hessian2 等，更多协议可以通过自定义扩展实现。这对于微服务实践中经常要处理的多协议通信场景非常有用。

Dubbo 框架不绑定任何通信协议，在实现上 Dubbo 对多协议的支持也非常灵活，它可以让你在一个应用内发布多个使用不同协议的服务，并且支持用同一个 port 端口对外发布所有协议。

通过 Dubbo 框架的多协议支持，你可以做到：

将任意通信协议无缝地接入 Dubbo 服务治理体系。Dubbo 体系下的所有通信协议，都可以享受到 Dubbo 的编程模型、服务发现、流量管控等优势。比如 gRPC over Dubbo 的模式，服务治理、编程 API 都能够零成本接入 Dubbo 体系。
兼容不同技术栈，业务系统混合使用不同的服务框架、RPC 框架。比如有些服务使用 gRPC 或者 Spring Cloud 开发，有些服务使用 Dubbo 框架开发，通过 Dubbo 的多协议支持可以很好的实现互通。
让协议迁移变的更简单。通过多协议、注册中心的协调，可以快速满足公司内协议迁移的需求。比如如从自研协议升级到 Dubbo 协议，Dubbo 协议自身升级，从 Dubbo 协议迁移到 gRPC，从 HTTP 迁移到 Dubbo 协议等。

# 4.Dubbo负载均衡策略

目前 Dubbo（3.X）内置了如下负载均衡策略：

Weighted Random LoadBalance（加权随机）：默认负载均衡算法，默认权重相同。按权重设置随机概率。缺点：存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
RoundRobin LoadBalance（加权轮询）：借鉴于 Nginx 的平滑加权轮询算法，默认权重相同，按公约后的权重设置轮询比率，循环调用节点。缺点：同样存在慢的提供者累积请求的问题。
LeastActive LoadBalance（最少活跃优先+加权随机）：背后是能者多劳的思想，活跃数越低，越优先调用，相同活跃数的进行加权随机。活跃数指调用前后计数差（针对特定提供者：请求发送数 - 响应返回数），表示特定提供者的任务堆积量，活跃数越低，代表该提供者处理能力越强。使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大；相对的，处理能力越强的节点，处理更多的请求。
Shortest-Response LoadBalance（最短响应优先+加权随机）：更加关注响应速度，在最近一个滑动窗口中，响应时间越短，越优先调用。相同响应时间的进行加权随机。使得响应时间越快的提供者，处理更多的请求。缺点：可能会造成流量过于集中于高性能节点的问题。
ConsistentHash LoadBalance（一致性哈希）：确定的入参，确定的提供者，适用于有状态请求。当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
P2C LoadBalance（随机选择两个节点+连接数较小）：随机选择两个节点后，继续选择“连接数”较小的那个节点。对于每次调用，从可用的 provider 列表中做两次随机选择，选出两个节点 providerA 和 providerB，比较 providerA 和 providerB 两个节点，选择其“当前正在处理的连接数”较小的那个节点。
Adaptive LoadBalance（自适应负载均衡）：在 P2C 算法基础上，选择二者中 load 最小的那个节点，是一种能根据后端实例负载自动调整流量分布的算法实现，它总是尝试将请求转发到负载最小的节点。