RPC远程接口调用实现原理与优化方法深度解析

时间：2026-06-13 16:17

回顾 RPC 调用过程先帮大家理一理RPC调用的完整流程，一共九步，每一步都很关键，我们来顺一下：第一步：服务消费方（client）以本地调用的方式发起调用，感觉就像调本地函数一样自然；第二步：client stub 收到这个调用请求后，立刻把方法名、参数等信息组装成能在网络上传输的消息体；

回顾 RPC 调用过程

先帮大家理一理RPC调用的完整流程，一共九步，每一步都很关键，我们来顺一下：

第一步：服务消费方（client）以本地调用的方式发起调用，感觉就像调本地函数一样自然；
第二步：client stub 收到这个调用请求后，立刻把方法名、参数等信息组装成能在网络上传输的消息体；
第三步：client stub 找到目标服务的地址，把消息发到服务端；
第四步：server stub 收到消息，先把它解码成可读的内部结构；
第五步：server stub 根据解码结果，调用本地真正的服务实现；
第六步：本地服务执行完毕，把结果返回给 server stub；
第七步：server stub 将返回结果打包成网络消息，再发回消费方；
第八步：client stub 接收到返回消息，同样要进行解码；
第九步：服务消费方拿到最终的结果，整个过程结束。

你看，这九步就是RPC调用的基本骨架，理解了它，后面的内容就顺了。

为什么要用 RPC

举个例子说明一下分布式调用的必要性。假设酒店里只有一个厨师，他要干所有活——洗菜、切菜、炒菜，这就是典型的单体架构，一台机器包揽全部。

制作番茄炒蛋{厨师->洗菜->切菜->炒菜}

但效率太低了，厨师一个人忙不过来。于是酒店招了备菜师和切菜师来帮忙，厨师终于轻松了一些。不过问题又来了：切菜师得等备菜师洗完菜，厨师得等切菜师切完菜，流程串行，还是慢。

制作番茄炒蛋{备菜师->洗菜切菜师->切菜厨师->炒菜}

这种情况下，酒店就需要多人协作，最终目标还是炒菜。厨师通知备菜师洗菜、通知切菜师切菜的过程，其实就是远程调用。实际流程是这样的：顾客下单后，服务员把单子送到厨房，然后分发任务给备菜师、切菜师和厨师。你看，这和计算机系统的分布式调用几乎一个道理。

如今的大型网站都是分布式部署的。以一次下单流程为例，它可能涉及物流、支付、库存、红包等多个子系统，而这些系统分别部署在不同的机器上，由不同的团队负责。要实现一个完整的下单动作，就必须依赖远程调用。

RPC 远程调用

RPC 是什么？

RPC 指的是计算机 A 上的进程调用另一台计算机 B 上的进程，调用时 A 的进程被挂起，B 上的被调用进程开始执行，执行完结果返回给 A，A 继续往下走。调用方可以把参数传给被调用方，再通过返回结果获取信息。整个过程对开发人员来说是透明的——你看不到网络传输、序列化、编解码这些细节。

用后厨的例子来类比：服务员把菜单传给后厨，厨师告诉备菜师和洗菜师开始工作，然后自己等着他们干完。备菜师和洗菜师完工后，厨师再炒菜。服务员完全不关心后厨内部怎么分工，这就是透明的含义。

RPC 远程接口调用：详解实现和优化

示例图

我们追求的目标，就是要把上面那九步中的第二步到第八步全部封装起来，让使用者感觉就像在调用本地方法一样。

那么如何封装通信细节呢？以 Ja va 为例，最常用的手段就是使用袋里。Ja va 中有两种袋里方式：一种是 JDK 动态袋里，另一种是字节码生成。确定好消息的数据结构后，接下来要考虑序列化与反序列化的问题。再下一步就是网络通信，常用的方案有三种：基于 Ja va NIO 自研、基于 Mina、或者基于 Netty。

另外，如何让别人发现并使用我们的服务？这里可以借助 ZooKeeper，它充当着一个服务注册中心的角色，可以管理多个服务提供者。消费者通过这个注册表能及时获取服务列表的变化，如下图所示。

RPC 远程接口调用：详解实现和优化