文章目录
- 0.前言
- [1.核心 RPC 模式对比](#1.核心 RPC 模式对比)
- 2.模式详解
-
- [2.1 同步模式 (Request-Reply)](#2.1 同步模式 (Request-Reply))
- [2.2 异步模式 (Future/Promise)](#2.2 异步模式 (Future/Promise))
- [2.3 单向调用 (One-way)](#2.3 单向调用 (One-way))
- [2.4 回调模式 (Callback)](#2.4 回调模式 (Callback))
- 3.如何选择？
- 4.补充阅读
- 参考文献
0.前言
远程过程调用（RPC，Remote Procedure Call）的核心思想是让调用远程服务像调用本地函数一样自然。但在工程实践中，根据不同的业务需求和技术场景，RPC 演化出了多种实现模式。
这里整理了四种最核心的模式，可以帮助你建立一个清晰的认知框架。
1.核心 RPC 模式对比
这四种模式各有侧重，简单来说，同步模式 和异步模式 解决的是通信的效率 问题，而单向调用 和回调模式 解决的是通信的交互形式问题。
| 模式 | 核心机制 | 特点 | 适用场景 |
|---|---|---|---|
| 同步模式 | 请求-响应 阻塞等待 | 实现简单、逻辑直观；但客户端必须等待，可能造成线程阻塞。 | 普通Web后端、BFF层、读写数据库等大部分常规业务。 |
| 异步模式 | 基于 Future/Promise 非阻塞 | 高吞吐、资源利用率高；但编程模型相对复杂。 | 高并发服务、IO密集型任务、调用链较长的场景。 |
| 单向调用 | 请求-only 无需响应 | 客户端发送后即返回，开销极小；可靠性低，无法感知服务端状态。 | 日志上报、监控指标采集、非关键通知。 |
| 回调模式 | 双向异步 结果通知 | 适合长时任务，客户端无需轮询；实现复杂，需要额外处理回调。 | AI推理任务、报表生成、订单异步处理。 |
2.模式详解
2.1 同步模式 (Request-Reply)
这是最基础的RPC模式，由 Birrell 和 Nelson 在 1984 年的经典论文中首次系统阐述 [1]。客户端发起调用后，线程会阻塞，一直等待服务器返回结果或超时，才继续执行。
java
// 客户端代码会在此等待1秒钟，直到服务端返回结果
Response res = rpcClient.send(request);它最大的优点是编程模型简单，符合直觉，在大部分业务逻辑简单的场景（如HTTP调用、数据库操作）是首选。缺点是当服务端处理慢时，客户端线程会被长时间占用，影响系统整体吞吐量。
2.2 异步模式 (Future/Promise)
客户端发起调用后，会立即返回一个 Future 或 Promise 对象，不会阻塞当前线程。你可以在稍后通过这个对象获取最终结果。Ananda 等人于 1992 年发表了关于异步 RPC 的系统性综述 [2]，对这一模式进行了详细分类。
java
Future<Response> future = rpcClient.asyncSend(request);
// 这里可以做别的事情，不阻塞
doOtherThings();
// 最后再尝试获取结果，如果未完成则阻塞等待
Response res = future.get();这种模式能有效提升系统的并发能力，非常适合IO密集型或服务调用链较长的场景。
2.3 单向调用 (One-way)
客户端发送请求后，完全不关心服务端是否收到或如何处理，立刻返回。这是最轻量级的模式，几乎没有响应开销。
java
// 调用发出后立刻返回，不等待任何响应
rpcClient.onewaySend(logRequest);适用于日志上报、监控打点等可靠性要求不高、但对性能有极致要求的场景。
2.4 回调模式 (Callback)
这是异步模式的一种实现。客户端发起调用时，会附带一个回调函数。当服务端处理完成并返回结果时，这个回调函数会被自动触发。
java
rpcClient.asyncSend(request, new Callback() {
public void onSuccess(Response res) { handle(res); }
public void onFailure(Throwable t) { handleError(t); }
});
// 调用发出后立刻返回，不阻塞
doOtherThings();这种方式在GUI编程和JavaScript中非常常见。在RPC中，它非常适合处理耗时较长的任务，客户端无需一直等待，通过回调优雅地处理最终结果。
工业实践参考：SOFARPC 框架对这四种调用模式（同步、Future、Callback、单向）均有完整的实现支持 [3][4]。
3.如何选择？
你可以根据自己的需求，参考下面的思路来选择合适的模式：
- 你的业务逻辑是简单的请求-响应吗？ ➡️ 同步模式。它是默认选择，简单直接。
- 你的系统需要处理海量并发请求吗？ ➡️ 异步模式 (Future)。它能有效提升吞吐量。
- 你需要发送日志或监控数据，并且不能影响主流程吗？ ➡️ 单向调用。
- 你需要调用一个耗时很长的任务，并且不想阻塞线程吗？ ➡️ 回调模式。
4.补充阅读
- ISO/IEC 11578:1996 -- Information technology. Open systems interconnection. Remote procedure call (RPC).（可在 ISO 官网检索购买）
- Rutgers University CS 417 Lecture Notes: Remote Procedure Calls.
🔗 https://people.cs.rutgers.edu/\~pxk/417/notes/rpc-guide.html
参考文献
1\] Birrell, A.D., Nelson, B.J. Implementing remote procedure calls. *ACM Transactions on Computer Systems* , 2(1), 39--59 (1984). 🔗 https://dl.acm.org/doi/10.1145/2080.357392 \[2\] Ananda, A.L., Tay, B.H., Koh, E.K. A survey of asynchronous remote procedure calls. *ACM SIGOPS Operating Systems Review* , 26(2), 92--109 (1992). 🔗 https://dl.acm.org/doi/10.1145/382244.382832 \[3\] SOFARPC 官方文档：同步异步实现剖析。阿里云开发者社区，2018. 🔗 https://developer.aliyun.com/article/663767 \[4\] SOFARPC 线程模型剖析：同步异步与线程模型详解。阿里云开发者社区，2018. 🔗 https://developer.aliyun.com/article/662498