Dubbo底层原理：一次RPC请求到底经历了什么？

Dubbo是大型架构核心，下面我详解Dubbo RPC调用过程@mikechen

Dubbo RPC

在微服务架构中，一个业务请求往往不会只调用一个服务。

例如一个电商订单请求：

用户
 ↓
订单服务
 ↓
用户服务
 ↓
库存服务
 ↓
支付服务

这些服务可能部署在不同服务器、不同容器甚至不同集群中。

那么问题来了：代码里看起来只是一次Java方法调用，底层到底发生了什么？

 

Dubbo RPC调用过程

假设业务代码：

User user = userService.getUser(1001);

看起来只是普通Java方法调用。

但实际上背后经历了：

业务代码
   ↓
动态代理 Proxy
   ↓
Invoker
   ↓
Cluster
   ↓
LoadBalance
   ↓
Filter
   ↓
Protocol
   ↓
Exchange
   ↓
Transport
   ↓
Netty
   ↓
Provider
   ↓
业务方法

我们拆开来看。

第一步：动态代理
Consumer拿到的userService通常不是Provider真正的实现对象，而是Dubbo生成的代理对象。

所以：

userService.getUser(1001);

实际上会进入代理逻辑。

 

第二步：Cluster
Dubbo会经过Cluster层。

Cluster负责处理集群相关逻辑，例如：

• 集群容错
• 失败重试
• 服务降级
• Provider选择

第三步：LoadBalance
如果当前有多个Provider：

UserService
 ├── Provider1
 ├── Provider2
 └── Provider3

就需要进行负载均衡。

Dubbo根据配置的负载均衡策略选择一个Provider。

 

第四步：Protocol Transport
选定Provider之后，Dubbo进入RPC协议和网络传输层。

请求需要完成：

Java对象
 ↓
序列化
 ↓
RPC协议
 ↓
网络传输
 ↓
Provider

Provider收到请求后，再进行反序列化，最终调用真正的业务实现。

陈睿|mikechen

10年+大厂架构经验，资深技术专家，就职于阿里等一线大厂。