RPC 服务总结

本节主要弄明白后台内部服务之间为什么通常使用 RPC，以及 RPC 如何让远程调用像本地方法调用一样简单。

核心主线

在大型互联网后台中，业务服务层通常会分为两类：

1
2
3
4
5
6
7
8
9

客户端请求
  ↓
Nginx
  ↓
HTTP 服务：面向外部请求，负责参数校验、响应组装、网关逻辑
  ↓ RPC 调用
RPC 服务：面向后台内部，负责核心业务逻辑
  ↓
存储层 / 消息中间件 / 其他服务

HTTP 服务更像业务网关，RPC 服务才是微服务内部核心业务逻辑的承载者。

1. HTTP 服务与 RPC 服务的定位区别

HTTP 服务

HTTP 服务主要面对后台外部，也就是来自客户端、Nginx 转发过来的请求。

它通常负责：

• 接收 HTTP / HTTPS 请求；
• 校验请求参数；
• 做简单的鉴权或上下文处理；
• 调用内部 RPC 服务；
• 打包并返回 HTTP 响应。

HTTP 服务更偏“入口层”或“网关层”。

RPC 服务

RPC 服务主要面对后台内部，是微服务架构中真正执行核心业务逻辑的服务。

它通常负责：

• 实现核心业务逻辑；
• 调用其他内部服务；
• 访问数据库、缓存、消息中间件等存储与基础组件；
• 对内部服务暴露 RPC 接口。

所谓微服务，主要指的就是 RPC 服务。

2. 什么是 RPC

RPC 全称是 Remote Procedure Call，远程过程调用。

它的目标是：

屏蔽网络通信细节，让调用远程服务像调用本地方法一样简单。

在单体应用中，接口和实现类都在同一个进程内，调用方法就是普通本地调用：

1

Calculator.add(1, 2)

但在分布式系统中，调用方和被调用方位于不同服务、不同进程，甚至不同机器上。此时调用方要执行远程服务的方法，就必须通过网络通信完成。

如果没有 RPC 框架，开发者需要手写大量网络通信代码，例如：

• 建立 TCP / HTTP 连接；
• 构造请求包；
• 序列化参数；
• 发送请求；
• 接收响应；
• 解析响应；
• 处理超时、失败等异常。

RPC 框架的价值就是：把这些网络通信细节封装起来，让开发者只关注方法调用本身。

3. RPC 的核心思想：代理模式

RPC 框架通常通过代理模式屏蔽远程调用细节。

对调用方来说，调用的是一个本地代理对象：

1

calculator.add(1, 2)

但代理对象背后会完成：

1
2
3
4
5
6
7
8
9
10
11
12
13

方法名 + 参数
  ↓
序列化
  ↓
编码成网络请求包
  ↓
通过网络发送给远程服务
  ↓
远程服务执行真实方法
  ↓
返回结果
  ↓
反序列化为本地对象

因此，调用方感知不到底层网络通信的存在。

4. RPC 通信流程

RPC 的本质是：

调用方把“要调用的方法”和“方法参数”发送给被调用方，被调用方执行后把结果返回。

完整流程可以概括为：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

调用方
  ↓ 构造请求对象
序列化器：对象 → 二进制数据
  ↓
编解码器：二进制数据 → 请求包
  ↓
网络通信
  ↓
被调用方收到请求包
  ↓
编解码器：请求包 → 方法名 + 参数数据
  ↓
反序列化：二进制数据 → 参数对象
  ↓
执行目标方法
  ↓
序列化返回结果
  ↓
编码为响应包
  ↓
网络返回
  ↓
调用方解码、反序列化得到响应对象

核心环节有两个：

5. 序列化与编解码

序列化

方法的输入参数和输出结果通常是对象，但网络传输只能传输字节数据。

所以需要序列化：

1
2

对象 → 二进制数据
二进制数据 → 对象

编解码

被调用方收到网络数据包后，需要知道：

• 调用的是哪个方法；
• 参数数据在哪里；
• 请求 ID 是什么；
• 如何解析请求体；
• 如何返回响应。

因此，双方必须约定协议格式，并按协议进行编码和解码。

1
2

二进制数据 → 按协议组织成请求包
请求包 → 按协议解析出方法名和参数

6. RPC 与 HTTP 不是对立关系

一个常见误区是：认为 RPC 和 HTTP 是互斥的。

实际上它们不是同一层面的概念：

• RPC 是一种远程调用设计思想；
• HTTP 是一种应用层通信协议。

RPC 底层可以基于不同网络协议实现：

所以，RPC 并不限制底层必须使用 TCP，也不排斥 HTTP。

区分 HTTP 服务和 RPC 服务，重点并不是说 HTTP 与 RPC 对立，而是强调：

1
2

HTTP 服务：服务于后台外部
RPC 服务：服务于后台内部

7. RPC 框架的作用

常见 RPC 框架包括：

• gRPC；
• Thrift；
• 其他公司自研 RPC 框架。

这些框架通常会基于协议定义文件生成脚手架代码。

开发者只需要：

1. 定义服务接口和数据结构；
2. 使用框架生成客户端和服务端代码；
3. 在服务端补充具体方法实现；
4. 调用方像调用本地方法一样调用远程接口。

这样可以显著降低分布式服务通信的开发成本。

8. RPC 与服务发现的关系

RPC 服务不是孤立存在的，它通常会结合服务发现一起使用。

完整调用链路是：

1
2
3
4
5
6
7
8
9
10
11
12
13

HTTP 服务收到用户请求
  ↓
通过服务注册中心获取 RPC 服务可用地址列表
  ↓
选择一个可用 RPC 实例
  ↓
通过 RPC 协议发起调用
  ↓
RPC 服务处理核心业务逻辑
  ↓
返回结果给 HTTP 服务
  ↓
HTTP 服务组装响应返回客户端

其中：

• 服务发现解决“RPC 服务在哪里”的问题；
• RPC 框架解决“如何像本地方法一样调用远程服务”的问题。

二者结合，构成微服务内部通信的基础。

9. 本节最重要的架构思想

1. 业务服务层通常分为 HTTP 服务和 RPC 服务：HTTP 服务面向外部请求，RPC 服务面向内部业务逻辑。
2. RPC 的目标是屏蔽网络通信细节：让远程调用像本地方法调用一样自然。
3. RPC 框架通常基于代理模式实现透明调用。
4. RPC 通信的关键是序列化、反序列化、编码、解码和网络传输。
5. RPC 与 HTTP 不是对立关系：RPC 是调用方式，HTTP 是通信协议，RPC 可以基于 HTTP 实现。
6. gRPC、Thrift 等框架可以根据协议文件生成脚手架代码，提高开发效率。
7. 服务发现与 RPC 配合使用：服务发现提供可用地址，RPC 负责完成远程调用。
8. 后台内部通信使用 RPC 形式，可以让微服务之间的调用更规范、更高效、更易维护。

一句话总结

RPC 服务承担后台内部核心业务逻辑，RPC 框架通过代理、序列化、编解码和网络通信封装，让调用方像调用本地方法一样调用远程服务；HTTP 服务面向外部请求，RPC 服务面向内部微服务通信，二者结合服务发现共同构成大型互联网后台的业务服务层。