什么是 Remote Procedure Call（RPC）

Remote Procedure Call

定义

RPC 是一种使程序能够像调用本地子程序那样调用 远程地址空间（通常是另一台机器上的服务）中的过程或函数的通信机制。(维基百科)
其关键点包括：

• 调用者（客户端）像调用本地函数那样发起调用；

• 实际执行发生在远程服务器端；

• 底层隐藏了网络通信、序列化/反序列化（marshalling/unmarshalling）、传输、调用等细节。(GeeksforGeeks)

• 虽然看起来像本地调用，但实际上远程调用的延迟、失败率、网络因素都与本地调用不同。(维基百科)

为什么需要 RPC？

作为一名专注于微服务、分布式架构的开发者，你会看到 RPC 的以下几个优势：

• 抽象通信细节：开发者可以像调用本地接口那样调用远程服务，无需编写繁琐的网络通讯代码。(Medium)

• 语言／平台互通：使用 IDL（接口描述语言）+ 自动生成 Stub 的方式，使不同语言／平台的服务组件能够互操作。(TechTarget)

• 服务拆分与扩展：在微服务架构中，各服务部署在不同机器／容器中，通过 RPC 调用可实现模块化、可扩展。(Medium)

RPC 的工作流程（典型同步调用）

1. 客户端调用客户端 stub（就像调用本地函数）。(TechTarget)

2. 客户端 stub 将函数参数 “打包”（marshalling／序列化）成消息。(维基百科)

3. 客户端通过底层传输层（TCP/UDP/HTTP2等）将消息发送到服务器。(ibm.com)

4. 服务器收到后，由服务器 stub 拆包（unmarshalling）参数，调用真正的远程过程。(GeeksforGeeks)

5. 服务器执行逻辑，返回结果至服务器 stub，序列化结果、通过网络发送回客户端。(TechTarget)

6. 客户端 stub 接收响应，反序列化返回值，并将控制权还给客户端调用者，仿佛调用本地函数结束。(Medium)

RPC 的关键组件

组件	作用
客户端（Client）	发起远程调用请求
客户端 Stub	用于参数打包、发起网络请求、接收结果
服务器 Stub（Skeleton）	接收请求、参数拆包、调用实际服务逻辑、打包返回值
服务器（Server）	执行实际逻辑
接口定义语言（IDL）	描述远程接口的方法名称、参数、返回值类型，生成 Stub 所需
传输层/协议	承载RPC消息的网络层，如 TCP、HTTP/2、UDP等

常见 RPC 系列／框架

• gRPC：Google 开源，高性能 RPC 框架，基于 HTTP/2 + Protocol Buffers。(维基百科)

• Apache Thrift：支持多语言、IDL 定义、二进制传输等。

• JSON‑RPC：基于 JSON 的简单 RPC 协议，适合 Web 应用。(维基百科)

• Microsoft RPC：在 Windows 系统中广泛使用。(Microsoft Learn)

RPC 的优缺点

优点

• 接口调用简洁，开发者视角像本地调用。

• 隐藏了网络细节、序列化细节，降低开发难度。

• 支持分布式服务、跨语言调用，有利于构建微服务架构。

缺点 & 注意事项

• 与本地调用相比，远程调用有 高延迟、易出错（网络故障、服务不可达）风险。(维基百科)

• 设计时需考虑 幂等性、容错机制、重试/幂等、超时。(GeeksforGeeks)

• 参数传递、引用类型、状态管理较复杂——不像纯本地函数那样简单。(GeeksforGeeks)

• 接口版本管理、服务治理、安全、认证、监控都需额外设计。(ibm.com)

• 如果滥用（如把细粒度函数都做 RPC）可能导致系统调用量爆炸、网络瓶颈。

对你（开发者）的实战角度建议

既然你专注于 Java／Python／iOS／Vue + 高性能应用 +微服务架构，这里有几点建议：

1. 明确边界：哪些服务适合 RPC？例如：服务间高频调用、强类型、跨语言的场景。对于简单 Web 前端调用，REST 或 GraphQL 更直观。

2. 使用合适框架：如 Java 服务用 gRPC（生成 Java Stub + proto 文件），Python 客户端也可生成 bindings。iOS 客户端也可有对应库。

3. 接口设计：使用 proto 或其他 IDL 定义接口。考虑好参数模型、版本兼容性、错误码规范。

4. 性能优化：

   • 串行调用 vs 批量调用：避免多个小 RPC 串联导致延迟累积。

   • 长连接／HTTP2 的优点（如 gRPC）可降低握手开销。

   • 序列化格式选择：Protocol Buffers、Avro、Thrift Binary 等比 JSON 更高效。

5. 容错 &超时设计：远程调用需超时控制、重试机制、幂等性设计。对于关键业务，服务降级也很重要。

6. 监控与治理：RPC 调用需要链路追踪（如 OpenTelemetry）、日志、统计调用量、失败率、延迟分布。服务注册发现、负载均衡、熔断器（circuit breaker）也是服务治理重要一环。

7. 客户端跨平台：例如 iOS 客户端通过 gRPC-Swift（或其他库）调用后端服务时，要考虑面对移动网络的不稳定性、离线场景、流量开销。

8. 与 Kubernetes 结合：在 Kubernetes 环境中部署 RPC 服务时，要注意：

   • 服务发现（如使用 Helm 部署、Service、Ingress／Gateway）

   • 网络策略、认证机制（mTLS、JWT）

   • 滚动升级、版本兼容：接口版本管理、兼容老客户端。

   • 性能监控与伸缩：CPU、网络、延迟监控，自动伸缩（HPA）要考虑 RPC 请求的特点。

简短总结

RPC 是构建分布式系统、微服务架构的一个核心通信模式，它通过“像本地调用一样”的方式隐藏了远程调用的复杂性。不过，正是因为隐藏了复杂性，开发者更不能忘记其背后隐藏的网络延迟、失败、版本兼容、序列化成本等风险。对于你这样既关注性能、又涉及多语言／多平台开发的人来说，理解 RPC 的原理、设计思路、以及具体框架的使用（如 gRPC）是非常必要的。