RPC核心原理：组件与调用流程
RPC核心原理：组件与调用流程
RPC（Remote Procedure Call，远程过程调用）的核心价值是屏蔽网络通信的底层复杂性，让开发者调用远程服务的方法时，体验与调用本地方法完全一致。其实现可拆解为5个核心组件和1个完整调用流程。
一、RPC的5个核心组件
1. 客户端（Consumer）
发起远程方法调用的一方，即业务代码中“像调用本地方法一样”调用远程服务的主体。
2. 服务端（Provider）
提供远程方法实现的一方，即实际执行业务逻辑的主体。
3. 客户端Stub（Client Stub）
也称为“客户端代理”，是RPC框架在客户端的核心封装：
- 接收客户端的方法调用请求（方法名、参数等）；
- 将调用信息序列化为可网络传输的二进制数据；
- 负责服务发现（通过注册中心获取服务端地址）；
- 将序列化后的消息发送给服务端。
4. 服务端Stub（Server Stub）
RPC框架在服务端的核心封装：
- 接收客户端发送的二进制消息；
- 将消息反序列化为Java对象（包含方法名、参数等）；
- 根据反序列化后的信息，调用服务端本地的业务方法；
- 将方法执行结果序列化后返回给客户端。
5. 网络传输层
负责客户端与服务端之间的二进制数据传输：
- 底层可基于Socket实现，但主流RPC框架（如Dubbo、gRPC）通常使用Netty（高性能NIO网络框架），以提升传输效率和稳定性。
二、RPC的完整调用流程
- 客户端发起调用：业务代码像调用本地方法一样，调用远程服务的接口方法。
- 客户端Stub处理请求：
- 拦截调用请求，提取方法名、参数等信息；
- 将信息组装为可传输的结构体，并序列化为二进制数据；
- 通过注册中心（如Nacos、Zookeeper）获取服务端的IP和端口。
- 网络传输：客户端Stub通过Netty等网络框架，将序列化后的消息发送给服务端。
- 服务端Stub处理请求：
- 接收二进制消息，反序列化为包含方法名、参数的Java对象；
- 根据对象信息，调用服务端本地的业务方法。
- 服务端返回结果：
- 服务端Stub将方法执行结果组装为结构体，并序列化为二进制数据；
- 通过网络传输层将结果发送回客户端。
- 客户端获取结果：
- 客户端Stub接收二进制消息，反序列化为Java对象；
- 将结果返回给业务代码，完成整个远程调用。
补充：为什么需要Stub？
Stub的核心作用是**“解耦业务代码与网络细节”**：
- 对客户端而言，无需关心序列化、服务发现、网络传输等底层逻辑，只需关注业务调用；
- 对服务端而言，无需关心网络接收、反序列化等逻辑，只需专注于业务方法的实现。
这正是RPC能让远程调用像本地调用一样简单的关键。