课程库 › 技术雷达 › 网络与通信 › 第 1 课

RPC —— 把「调用远程函数」伪装成「调用本地函数」

普通课约 40 分钟

本课导读

你写过 fetch("/api/notes")——那是 REST 风格的 API。RPC（Remote Procedure Call，远程过程调用）是设计网络接口的另一种世界观，而且比 REST 古老得多。本课讲清两种世界观的分野、亲手跑一个 20 行的 mini-RPC（浏览器里真能运行），然后盘点 RPC 家族三大明星——其中一个你正在用而不自知：VS Code 的红波浪线和 Claude 的 MCP，底下都是 JSON-RPC。预计 40 分钟。

两种世界观：资源 vs 函数

前后端隔着网络怎么对话？两套隐喻：

REST 的世界观：一切是「资源」。 把后端想象成一堆名词（用户、笔记、订单），操作 = HTTP 动词 + 资源地址：

GET    /api/notes/42      读 42 号笔记
POST   /api/notes         创建笔记
DELETE /api/notes/42      删除 42 号笔记

RPC 的世界观：一切是「函数调用」。 后端就是一堆函数，前端"假装"直接调用它们，网络传输被藏起来：

getNote(42)
createNote({ title: "..." })
deleteNote(42)

提示

类比：REST 像图书馆——万物皆藏品，按统一规则（索书号 + 借/还/查几个标准动作）操作任何藏品；RPC 像打电话给客服——"帮我办 X 业务，参数是 Y"，想办什么业务就开什么口，不必把业务翻译成"对某个资源的增删改查"。真实世界里很多操作（"给这篇笔记点赞并通知作者"）本来就更像业务而不像资源，硬套 REST 反而别扭——这就是 RPC 的立足点。

RPC 其实是更古老的思想（1980 年代就有），本质四步从未变过：① 把函数名和参数序列化成字节 → ② 网络传到远端 → ③ 远端执行真函数 → ④ 结果序列化传回来。所有 RPC 框架都只是这四步的不同包装。

亲手写一个：20 行的 mini JSON-RPC

最直观的理解方式是造一个玩具。下面这段可以直接点运行（本课特批的浏览器可运行块）——我们把"网络"省略成一次字符串传递，只看 RPC 的骨架：

TypeScript

// ── 服务端：一张「可被远程调用的函数」注册表 ──
const handlers: Record<string, (...args: any[]) => unknown> = {
add: (a: number, b: number) => a + b,
getNote: (id: number) => ({ id, title: "第 " + id + " 号笔记" }),
};

// 服务端的全部工作：收到请求字符串 → 查表执行 → 返回结果字符串
function serve(requestJson: string): string {
const req = JSON.parse(requestJson);          // ② 反序列化
const fn = handlers[req.method];
if (!fn) return JSON.stringify({ error: "没有这个方法: " + req.method });
const result = fn(...req.params);             // ③ 执行真函数
return JSON.stringify({ result });            // ④ 序列化结果
}

// ── 客户端：把「函数调用」打包成请求字符串 ──
function call(method: string, ...params: unknown[]) {
const requestJson = JSON.stringify({ method, params });  // ① 序列化
console.log("→ 请求：" + requestJson);
const responseJson = serve(requestJson);      // 真实世界这里是一次网络传输
console.log("← 响应：" + responseJson);
return JSON.parse(responseJson).result;
}

// ── 见证时刻：调用「远程」函数，手感和本地函数一样 ──
console.log("add 结果：", call("add", 1, 2));
console.log("getNote 结果：", call("getNote", 42));
console.log("调不存在的方法：", call("selfDestruct"));

// ── 服务端：一张「可被远程调用的函数」注册表 ──
const handlers: Record<string, (...args: any[]) => unknown> = {
add: (a: number, b: number) => a + b,
getNote: (id: number) => ({ id, title: "第 " + id + " 号笔记" }),
};

// 服务端的全部工作：收到请求字符串 → 查表执行 → 返回结果字符串
function serve(requestJson: string): string {
const req = JSON.parse(requestJson);          // ② 反序列化
const fn = handlers[req.method];
if (!fn) return JSON.stringify({ error: "没有这个方法: " + req.method });
const result = fn(...req.params);             // ③ 执行真函数
return JSON.stringify({ result });            // ④ 序列化结果
}

// ── 客户端：把「函数调用」打包成请求字符串 ──
function call(method: string, ...params: unknown[]) {
const requestJson = JSON.stringify({ method, params });  // ① 序列化
console.log("→ 请求：" + requestJson);
const responseJson = serve(requestJson);      // 真实世界这里是一次网络传输
console.log("← 响应：" + responseJson);
return JSON.parse(responseJson).result;
}

// ── 见证时刻：调用「远程」函数，手感和本地函数一样 ──
console.log("add 结果：", call("add", 1, 2));
console.log("getNote 结果：", call("getNote", 42));
console.log("调不存在的方法：", call("selfDestruct"));

运行后对照输出看：call("add", 1, 2) 的手感和本地函数没区别，但中间实际发生了"序列化 → 传输 → 查表执行 → 传回"。把 serve(requestJson) 那行换成 fetch() 发到真服务器，这就是一个能用的 RPC 系统——你刚才打印出的请求格式（method + params 的 JSON），几乎就是 JSON-RPC 协议本身。

RPC 家族三大明星

JSON-RPC —— 极简派，协议就一页纸（JSON 里写 method/params/id）。它是本地进程间通信的事实标准：VS Code 和 tsserver 之间（你的红波浪线、自动补全就是编辑器每敲一个字就 JSON-RPC 问语言服务器"这里有没有错"，此协议叫 LSP）、Claude 与 MCP 服务器之间、各种插件系统——全是 JSON-RPC。你以为没用过，其实每天用几千次。

gRPC —— Google 的工业重炮，微服务圈的统治者。两大特征：① 参数不用 JSON 而用 protobuf（预先在 .proto 文件里声明接口和类型，编码成紧凑二进制，比 JSON 小几倍快几倍）；② 跑在 HTTP/2 上，支持双向流。公司内部几百个服务互相调用时，性能和强类型契约都是刚需——大厂后端岗位说的 RPC 基本指这个。

tRPC —— TypeScript 全栈圈的新贵，和你的技术栈直接相关。核心卖点：前后端共享 TS 类型，零代码生成——后端定义函数时写的类型，前端调用时自动获得补全和类型检查，改接口忘了改前端会直接编译报错。相当于把你在 TS 课学的类型安全从"一个文件内"扩展到"跨越网络的前后端之间"。Next.js 生态常客。

那我写 API 该用哪个？

场景	选择	原因
对外公开的 API（第三方要接）	REST	通用、自描述、谁都会调，HTTP 缓存白送
公司内部微服务互调	gRPC	性能 + 强类型契约
TS 全栈项目自己前后端	tRPC（或继续 REST）	类型打通，改接口不怕漏
编辑器/AI 工具/插件通信	JSON-RPC	极简、双向、不挑传输层

说明

注意 REST 并没有输：接口越「对外」越 REST，越「对内」越 RPC。对外要的是谁都能懂的通用语，对内要的是效率和类型安全——没有银弹，只有场景。另外你迟早会撞见 GraphQL：第三种世界观（前端自己声明要什么数据），本课先给它占个雷达坑位。

够用判断线

一句话总结：REST 把后端抽象成「资源 + 标准动词」，RPC 把后端抽象成「可远程调用的函数」；JSON-RPC 统治工具间通信（LSP、MCP），gRPC 统治微服务，tRPC 给 TS 全栈把类型打通。值得深入的信号：你的 Next.js 项目前后端接口多到开始对不上类型时，认真看 tRPC；聊后端岗位 JD 看到 gRPC 时，你已经知道它是什么了。

随堂测验

随堂测验0 / 4 题正确

1. REST 和 RPC 两种世界观的本质区别是？

2. 任何 RPC 框架都绕不开的四步骨架是？

3. 「我从没用过 JSON-RPC」——为什么这句话对你大概率不成立？

4. tRPC 对 TS 全栈项目（比如你的 Next.js 网站）的核心卖点是？

划选正文任意文字可高亮、批注或加入复习卡

讨论

载入中…