RPC 发展史

“Does developer convenience really trump correctness, scalability, performance, separation of concerns, extensibility, and accidental complexity?” Vinoski (2008)

开发者的便利性真的比正确性、可扩展性、性能、关注点分离、可扩展性和偶然复杂度更重要吗？

本文主要介绍RPC基础概念以及发展历程，目的是为了让读者对RPC 的发展以及发展过程中遇到的问题有比较清晰的了解。

RPC 介绍

远程过程调用(Remote Procedure Call，RPC)是一种允许两个实体通过通用请求/响应机制的通信通道进行通信的设计范例。RPC 的定义在过去三十年中发生了重大的变化和演变，因此 这里RPC 范式是一个广义的分类术语，指的是过去四十年中出现的所有 RPC 式系统。RPC 的定义经过几十年的发展。它已经从一个简单的客户端-服务器设计转移到一组相互连接的服务。虽然最初的 RPC 实现被设计为将计算外包给分布式系统中的服务器的工具，但 RPC 经过多年的发展，已经构建了一个与语言无关的应用程序生态系统。RPC 范式已经成为创建真正革命性的分布式系统的驱动力的一部分，并且在不同系统之间产生了各种通信方案和协议。

最简单的 RPC 实现如图1所示。在这种情况下，客户端(或调用方)和服务器(或被调用方)被一个物理网络分开。系统的主要组件是客户端例程/程序、客户端存根、服务器例程/程序、服务器存根和网络例程。存根是一个小程序，通常用作较大程序的替代程序(或接口)。客户端存根向客户端例程公开服务器例程提供的功能，而服务器存根向服务器例程提供类似于客户端的程序。客户端存根从客户端程序获取输入参数并返回结果，而服务器存根向服务器程序提供输入参数并获取结果。客户端程序只能与客户端存根交互，后者为客户端提供远程服务器的接口。这个存根还序列化客户端例程发送到存根的输入参数。类似地，服务器存根为服务器例程提供客户端接口，并处理发送到客户端的数据序列化。

当客户端例程执行远程过程时，它调用客户端存根，该存根序列化输入参数。这个序列化数据使用 OS 网络例程(TCP/IP)发送到服务器。然后，服务器存根将数据反序列化，并使用给定的参数提供给服务器例程。来自服务器例程的返回值再次序列化，并通过网络发送回客户端，在那里客户端存根对其进行反序列化，并显示给客户端例程。这个远程过程通常对客户端例程隐藏，并作为本地过程显示给客户端。RPC 服务还需要一个发现服务/主机解析机制来引导客户端和服务器之间的通信。

完整的 RPC 框架

在一个典型 RPC 的使用场景中，包含了服务发现、负载、容错、网络传输、序列化等组件，其中“RPC 协议”就指明了程序如何进行网络传输和序列化。

RPC 的发展历程

太长不看版

1969年11月，ARPAnet 开始建立。

1996年，美国国防部高级研究计划管理局（ARPA全称：Advanced Research Projects Agency）开始建立一个命名为ARPAnet的网络。最开始只有4个结点，分别是洛杉矶的加利福尼亚州大学洛杉矶分校、加州大学圣巴巴拉分校、斯坦福大学、犹他州大学四所大学的4台大型计算机。选择这四个节点的一个原因是要测试不同类型主机联网的兼容性。

1974年：Jon Postel 和 Jim White发表了RFC674

过程调用最早可以追溯到 Jon Postel 和 Jim White 在1974 年发表的 Procedure Call Protocol Documents Version 2（RFC674）。这个协议试图定义一种通用的方法，用于解决 NSW 项目中多个计算节点通信的问题。

协议发表后，引起了非常大的争议，1975年，RFC674的注释篇RFC684 发布。

1975年：RFC684 作为RFC 674 的注释发表，对RFC 674 的争议进行回复

RFC 684 不是一个独立的协议， 主要对 RFC674 的争议进行讨论。讨论内容可以总结为以下几点：

• RFC674 认为过程调用应该是一个原语操作，它应该在操作系统底层进行操作

• 原语是在操作系统中调用核心层子程序的指令。与一般广义指令的区别在于它是不可中断的，而且总是作为一个基本单位出现。

• 本地调用和远程调用是不同的，远程调用可能会发生故障，并且发生故障后可能无法恢复。

• 异步消息传递，或者显示的声明什么时候需要同步等待消息返回应该是一个更好的模型。

从这几点出发，关于这个编程范型的担忧成了RPC40多年历史中一个永恒的话题，即：

• 故障或错误后怎么恢复？重试、抛出异常？

• 顺序操作非常困难。比如一系列同步请求，如果其中某些请求失败，怎么保证错误的请求重新执行，以及请求还是顺序的？

• RPC 请求是同步模型，方法被调用后会等待响应，但是由于请求是同步的，在系统负载高时如果希望优先响应优先级高的请求则变成了非常困难的事情。

• 同步更多地是针对一对一的调用和返回，而不是针对单个请求的异步特性和多个返回。此外，低优先级、可抢占的后台任务也不太可能在过程调用中实现。

此时的协议还是基于阿帕网（ARPANET），互联网还没有出现，已经在讨论分布式系统间调用的问题了。

1976年：RFC 707 发布

由于远程和本地调用的成本差异，应用程序程序员必须谨慎使用远程资源，即使远程资源的使用机制将被 RTE 大大简化。与虚拟内存一样，过程调用模型提供了极大的便利，也提供了强大的能力，于此同时也应该对可能产生的滥用有合理警觉

RFC 707 概括了 RFC 684 的思想，并讨论了诸如 TELNET 和 FTP 等服务的资源共享问题，这些服务中的每一个都提供了与之交互的不同接口，这就要求操作员知道与该服务交互的具体协议。针对这种问题，作者提出了一个新的想法：与其需要知道远程计算机上所有可用的命令和协议，我们能否定义一个通用的接受参数并遵循调用/响应模型的接口来执行一个远程过程。

1983年1月1日，ARPA网将其网络核心协议由网络控制程序改变为 TCP/IP 协议

1983年1月1日，ARPA网将其网络核心协议由网络控制程序改变为 TCP/IP 协议，互联网的种子开始发芽。

1984年：论文 《Implementing remote procedure calls》发表

RPC 是远程过程调用（Remote Procedure Call）的缩写形式，Birrell 和 Nelson 在 1984 发表于 ACM Transactions on Computer Systems 的论文《Implementing remote procedure calls》对 RPC 做了经典的诠释。RPC 是指计算机 A 上的进程，调用另外一台计算机 B 上的进程，其中 A 上的调用进程被挂起，而 B 上的被调用进程开始执行，当值返回给 A 时，A 进程继续执行。调用方可以通过使用参数将信息传送给被调用方，而后可以通过传回的结果得到信息。而这一过程，对于开发人员来说是透明的。之后的几年RPC一直被认为是建立分布式操作系统的最合适