# RPC 核心概念 01：什么是 RPC？为什么需要 RPC？

## 一、从函数调用说起

我们写代码的最基本动作就是调用函数：

```go
result := add(1, 2)
```

这种调用发生在**同一个进程**内，CPU 直接跳转到函数地址执行。但当业务越来越大，单个进程容纳不下所有功能，我们就要把不同模块拆到不同进程、不同机器上。问题来了：**A 机器上的代码如何调用 B 机器上的函数？**

这就是 RPC（Remote Procedure Call，远程过程调用）要解决的核心问题——**让远程函数调用看起来像本地函数调用一样简单**。
![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-10730009/593d6a287b2edae881eea14cb1c85bbd.png)

## 二、RPC 的定义

> **RPC：一种让程序透明地调用另一个地址空间（通常是远程服务器）函数的协议与技术。**

调用方（Client）的代码长这样：

```go
result, err := userClient.GetUser(ctx, &GetUserReq{ID: 1})
```

被调方（Server）的代码长这样：

```go
func (s *UserService) GetUser(ctx context.Context, req *GetUserReq) (*GetUserResp, error) {
    return &GetUserResp{Name: "Tom"}, nil
}
```

中间发生的网络通信、序列化、连接管理等细节全部被框架隐藏。

## 三、为什么需要 RPC？

### 3.1 微服务架构的必然需求

随着业务复杂度提升，单体应用面临：
- 编译部署慢；
- 任意模块出 bug 影响全局；
- 团队协作冲突；
- 难以按模块独立扩缩容。

拆分成多个微服务后，**服务间通信**就是头等大事。HTTP+JSON 当然可以，但有诸多缺点（后述），RPC 框架是更合适的方案。

### 3.2 性能与开发效率的平衡

| 维度 | HTTP/JSON | RPC |
| --- | --- | --- |
| 协议开销 | 较大（HTTP 头、JSON 文本） | 小（二进制协议） |
| 序列化效率 | 慢（文本） | 快（Protobuf 等） |
| 接口契约 | 弱（依赖文档） | 强（IDL 强约束） |
| 开发体验 | 手写客户端 | 代码自动生成 |
| 服务治理 | 自行实现 | 框架内置 |

## 四、RPC 的本质：本地调用 + 网络通信

一次 RPC 调用的完整流程：

```
Client                                                 Server
  │                                                      │
  │ 1. 调用 stub (生成的客户端代码)                          │
  │                                                      │
  │ 2. 参数序列化 (Marshal)                                │
  │                                                      │
  │ 3. 通过网络发送 (TCP / HTTP/2 / QUIC)                  │
  ├─────────────────────────────────────────────────────►│
  │                                                      │ 4. 接收并反序列化
  │                                                      │
  │                                                      │ 5. 路由到具体方法
  │                                                      │
  │                                                      │ 6. 执行业务逻辑
  │                                                      │
  │                                                      │ 7. 序列化结果
  │◄─────────────────────────────────────────────────────┤
  │ 8. 反序列化得到返回值                                    │
```

可以发现 RPC 框架要解决的核心问题：
1. **接口约定**（IDL）
2. **序列化协议**（如 Protobuf）
3. **传输协议**（TCP、HTTP/2 等）
4. **服务发现与负载均衡**
5. **错误处理与超时**
6. **可观测性**（日志、监控、链路追踪）

## 五、RPC 的发展历程

| 年代 | 代表技术 | 特点 |
| --- | --- | --- |
| 1980s | Sun RPC、CORBA | 早期跨平台尝试，复杂笨重 |
| 2000s | XML-RPC、SOAP | 文本协议，性能差但跨语言好 |
| 2010s | Thrift（Facebook）、Dubbo（阿里） | 二进制协议，性能跃升 |
| 2015+ | **gRPC**（Google） | HTTP/2 + Protobuf，事实标准 |
| 国内 | **tRPC**（腾讯）、**Kitex**（字节） | 业务定制 + 多协议互通 |

## 六、与其他通信方式的对比

### 6.1 RPC vs REST

REST 是**资源导向**的设计风格，基于 HTTP 语义；RPC 是**动作导向**的远程调用。

- 对外暴露的开放 API：建议 REST（生态、调试方便）；
- 内部微服务通信：建议 RPC（性能、强契约）。

### 6.2 RPC vs 消息队列（MQ）

- RPC：**同步、点对点**；
- MQ：**异步、解耦、广播**。

复杂业务往往两者结合：核心链路同步 RPC，旁路通知用 MQ。

### 6.3 RPC vs GraphQL

- RPC：客户端直接调用具体方法；
- GraphQL：客户端按需查询字段。

GraphQL 适合面向多端 BFF 场景，RPC 适合内部微服务。

## 七、一个最小 RPC 示例（伪代码）

### 服务端

```go
type Calculator struct{}

func (c *Calculator) Add(req AddReq) AddResp {
    return AddResp{Sum: req.A + req.B}
}

server := rpc.NewServer()
server.Register(&Calculator{})
server.Listen(":8000")
```

### 客户端

```go
client := rpc.Dial("127.0.0.1:8000")
defer client.Close()

resp, err := client.Call("Calculator.Add", AddReq{A: 1, B: 2})
fmt.Println(resp.Sum) // 3
```

看起来就像本地调用，但底层经历了序列化、网络、反序列化等一系列步骤。

## 八、RPC 不是银弹

引入 RPC 的代价：
1. **网络不可靠**：超时、抖动、断连必须处理；
2. **延迟变大**：本地调用 ns 级，RPC 至少 ms 级；
3. **可观测性复杂**：跨进程调用要做链路追踪；
4. **版本兼容**：服务升级要考虑客户端旧版本。

经典理论：**Fallacies of Distributed Computing**（分布式计算谬误）告诫我们网络不是 100% 可靠。

## 九、什么时候不该用 RPC？

- 单进程内：直接函数调用；
- 极高吞吐 + 异步处理：用 MQ；
- 数据流式传输：考虑 gRPC streaming 或专用协议；
- 与浏览器直连：用 REST/WebSocket 更兼容。

## 十、小结

- RPC 让远程调用像本地调用一样简单；
- RPC 框架解决：IDL、序列化、传输、治理、观测；
- 内部微服务首选 RPC，对外开放接口可用 REST；
- 享受便利的同时要尊重网络不可靠的事实。

下一篇我们将深入 RPC 的"骨架"：**IDL 与 Protobuf**。


这种调用发生在同一个进程内，CPU 直接跳转到函数地址执行。但当业务越来越大，单个进程容纳不下所有功能，我们就要把不同模块拆到不同进程、不同机器上。问题来了：A 机器上的代码如何调用 B 机器上的函数？

RPC 核心概念 01：什么是 RPC？为什么需要 RPC？

服务端开发

网络与通信

架构设计

后端

本文深入解析RPC核心概念，阐述其作为实现远程函数调用如同本地调用的关键技术。文章对比了RPC与HTTP、MQ等方案的差异，详解其在微服务架构中的必要性、完整调用流程及核心组件（如IDL、序列化）。指出了RPC的性能优势与引入的分布式复杂性，并指导了其适用场景，是理解现代分布式系统通信基础的必读内容。

微服务架构

分布式计算

消息队列

负载均衡

服务器

数据流

GraphQL

路由

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

RPC 核心概念 01：什么是 RPC？为什么需要 RPC？-腾讯云开发者社区-腾讯云

RPC 核心概念 01：什么是 RPC？为什么需要 RPC？

RPC 核心概念 01：什么是 RPC？为什么需要 RPC？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐