小编点评

Dubbo 是一款高性能、轻量级的开源 RPC 框架，主要用于构建分布式服务和微服务架构。它的核心组件包括服务提供者、服务消费者和注册中心。服务提供者将服务接口及实现注册到注册中心，服务消费者从注册中心订阅所需服务并进行远程调用。 Dubbo 的运行流程包括服务提供者将实例注册到注册中心，注册中心负责数据聚合和健康检测。消费者从注册中心获取地址列表并订阅变更，每当地址列表发生变化，注册中心将最新列表通知到所有订阅的消费者实例。消费者得到服务实例后，通过负载均衡策略选择其中一个节点进行连接和通讯。 Dubbo 支持多种通讯协议，如 HTTP/2 的 Triple 协议、TCP 的 Dubbo2 协议以及多种第三方协议。这些协议可以通过自定义扩展实现，使得 Dubbo 框架具有很高的灵活性。 Dubbo 提供了多种负载均衡策略，包括加权随机、加权轮询、最少活跃优先、最短响应优先、一致性哈希等。这些策略可以根据实际需求进行选择和配置。 总之，Dubbo 框架通过其核心组件和丰富的功能特性，为构建高性能、可扩展的分布式系统和微服务架构提供了有力支持。

正文

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

1.核心组件

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

Dubbo 核心组件有以下几个：

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

2.运行流程

Dubbo 运行流程如下图所示：

它的执行流程如下：

1. 服务提供者会将实例（URL 地址）注册到注册中心，注册中心负责对数据进行聚合（健康检测）。
2. 消费者从注册中心读取地址列表并订阅变更，每当地址列表发生变化，注册中心将最新的列表通知到所有订阅的消费者实例。
3. 消费者得到服务实例之后，通过 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）内置了如下负载均衡策略：

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

课后思考

具体说说 RPC 调用的执行流程？

本文已收录到我的面试小站 www.javacn.site，其中包含的内容有：Redis、JVM、并发、并发、MySQL、Spring、Spring MVC、Spring Boot、Spring Cloud、MyBatis、设计模式、消息队列等模块。