RPC 应用

自成立以来，已经发表了许多有关将 RPC 范式应用于不同领域以及使用 RPC 实现创建新系统的论文。以下是一些包含 RPC 的应用程序和系统。

Shared State and Persistence Layer

RPC 的一个主要限制（和优势）被认为是网络中所有计算机的单独地址空间。这意味着无法在调用方和被调用方之间传递对数据对象的指针或引用。因此，Interweave 是一种中间件系统，可以实现在异构硬件上运行的任意数据类型和独立于语言的进程。Interweave 是专门设计的，并且与基于 RPC 的系统兼容，并且允许使用内存块和锁更轻松地访问不同应用程序之间的共享资源。尽管已经进行了研究以确保基于 RPC 的系统具有全局共享状态，但是这些系统倾向于通过使用共享存储而不是单独的地址空间来消除调用者和被调用者之间的独立性和模块化感。

GridRPC

网格计算是 RPC 范例中使用最广泛的应用之一。在较高的层次上，它可以看作是相互连接以形成网格的计算机的网格（或网络），以便每个系统都可以利用网络中任何其他系统的资源。在 GridRPC 范例中，网络中的每台计算机都可以充当呼叫者或被呼叫者，这取决于所需的资源量（Caniou 等，2008）。同一台计算机也可以充当呼叫者以及被呼叫者进行不同的计算。

GridSolve 是最流行的 GridRPC 兼容中间件的实现，Ninf 比 GridSolve 相对更老，并且于 1990 年代末首次发布。这是一个简单的 RPC 层，还提供了双方之间的身份验证和安全通信。另一方面，GridSolve 比较复杂，并使用客户端-代理-服务器模型为通信提供了中间件。

Mobile Systems and Computation Offloading

如今，移动系统已经变得非常强大。借助多核处理器和千兆字节的 RAM，它们可以轻松进行相对复杂的计算。由于这种进步，它们消耗了大量的能量，因此，尽管它们的电池变大了，但其使用却迅速消耗掉。此外，移动数据（网络带宽）仍然有限且昂贵。由于这些要求，最好在可能的情况下从移动系统上卸载移动计算。RPC 在此计算卸载的通讯中起着重要作用。其中一些服务使用 Grid RPC 技术来卸载此计算。而其他技术为此使用 RMI（远程方法调用）系统。

Ibis 专案（Ibis，n.d.）建立了 RMI（类似于 JavaRMI）和 GMI（群组方法调用）模型来促进外包计算。Cuckoo（Zhou，Zhang，Ye 和 Du，2016 年）使用此 Ibis 通信中间件将计算从运行在 Android 智能手机上的应用程序（使用 Cuckoo 构建）转移到远程 Cuckoo 服务器上。微软的 MAUI 项目（Cuervo 等人，2010 年）使用 RPC 通信，并允许对.NET 应用程序进行分区，并“细粒度的代码卸载可最大程度地节省能源，而对程序员的负担却最小”。MAUI 确定在运行时卸载到外部 MAUI 服务器的方法。

Async RPC, Futures and Promises

远程过程调用可以是异步的。不仅如此，这些异步 RPC 在 Futures & Promises 中也扮演着不可或缺的角色。Futures & Promises 是一种编程结构，其中 Futures 被可以是变量/数据/返回类型/错误，而 Promises 被视为尚未计算得到的 Futures。参考 Finagle 对 Futures & Promises 的定义，在该定义中，将 Futures（Empty Future）的 Promises 视为请求，而将 Future 的 异步解析得到的 Promises 视为响应。此构造主要用于异步编程。

使用此类 RPC 模型的最著名的系统也许是 Twitter 的 Finagle 和 Cap’n Proto。

RPC in Microservices Ecosystem

RPC 实现已从单服务器模型迁移到多台服务器，再到动态创建的，负载平衡的微服务。RPC 最初是 REST，Streaming RPC，MAUI，gRPC，Cap’n Proto 的单独实现，现在已经可以将所有这些实现作为用户端点的单个抽象进行集成。端点是微服务的构建块。微服务通常是具有非常简单，定义明确的目的的服务，几乎可以使用与其他微服务交互的任何语言编写，以提供一种大型整体服务的感觉。这些微服务与语言无关。一种使用 C/C++ 编写的机票微服务可能正在使用与语言无关的异步 RPC 框架（例如 gRPC）与以不同语言（Python，C++，Java，Node.js）编写的针对单个航空公司的许多其他微服务进行通信（Google，nd）或 Thrift（Prunicki，2009）。

RPC 的使用使我们能够即时创建新的微服务。微服务不仅可以在运行时创建和引导，还具有诸如负载平衡和故障恢复之类的固有功能。这种引导可能发生在同一台计算机上，添加到 Docker 容器中（Merkel，2014 年），或者跨网络（使用 DNS，NAT 或其他机制的任意组合）。

RPC 可以定义为将所有微服务结合在一起的“胶水”（Mueller，2015 年）。这意味着 RPC 是在不同系统上运行的不同微服务之间的主要通信机制之一。微服务请求另一个微服务执行操作/查询。另一个微服务在收到此类请求后执行操作并返回响应。此操作的范围可能从简单的计算到调用另一个创建一系列 RPC 事件的微服务到动态创建新的微服务以动态地平衡微服务系统的负载。这些微服务与语言无关。一种微服务可以用 C/C++ 编写，另一种可以用不同的语言（Python，C++，Java，Node.js）编写，并且它们都可以使用与语言无关的异步高性能 RPC 框架（如 gRPC）相互通信。（Google，nd）或 Thrift（Prunicki，2009）。

使用 Futures/Promises 的微服务生态系统的一个例子是 Twitter 上的 Finagle（Eriksen，2013 年）。