千字带你了解什么是 RPC 协议

什么是 RPC ?

RPC（Remote Procedure Call）远程过程调用协议是一个用于建立适当框架的协议。从本质上讲，它使一台机器上的程序能够调用另一台机器上的子程序，而不会意识到它是远程的。

RPC 是一种软件通信协议，一个程序可以用来向位于网络上另一台计算机的程序请求服务，而不必了解网络的细节。RPC 被用来像本地系统一样调用远程系统上的其他进程。过程调用有时也被称为函数调用或子程序调用。

为什么有 RPC？

Socket 和 HTTP 编程使用消息传递范式。客户端向服务器发送一个消息，而服务器通常会发送一个消息回来。双方都负责以双方都能理解的格式创建消息，并从这些消息中读出数据。

然而，大多数独立的应用程序并没有那么多地使用消息传递技术。一般来说，首选的机制是函数（或方法或过程）的调用。在这种方式中，程序将调用一个带有参数列表的函数，并在完成函数调用后有一组返回值。这些值可能是函数值，或者如果地址被作为参数传递，那么这些地址的内容可能已经被改变。地址的内容可能已经被改变。

RPC 就是将这种编程方式引入网络世界的一种尝试。因此，客户端将进行在它看来是正常的过程调用。客户端会将其打包成网络消息并传送给服务器。服务器会将其解包，并在服务器端将其转回为过程调用。服务器端的过程调用。这个调用的结果将被打包，以便返回给客户端。

本地过程和远程

过程是什么？ 过程就是业务处理、计算任务，更直白的说，就是程序。

RPC 就是想调用本地方法一样调用远程的过程。与本地过程调用一样，RPC 也是一种同步操作，需要挂起请求程序，直到返回远程过程的结果。但是，使用共享相同地址空间的轻量级进程或线程可以同时执行多个 RPC。

RPC 如何工作

在 RPC 的工作期间，将执行以下步骤：

RPC 的工作过程如下：

1. 服务消费方（client）调用以本地调用方式调用服务；
2. client stub 接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；这就是所谓的 marshalling。
3. client stub 找到服务地址，并将消息发送到服务端；这个过程可能是面向连接或无连接的。
4. server stub 收到消息后进行解码；也叫 unmarshalling。
5. server stub 根据解码结果调用本地的服务；
6. 本地服务执行并将结果返回给 server stub ；
7. server stub 将返回结果打包成消息并发送至消费方；
8. client stub 接收到消息，并进行解码；
9. 服务消费方得到最终结果。并且返回值被设置在本地进程的堆栈中。

RPC 的通常实现方式

有两种常见的实现 RPC 的方式：利用服务规范和自定义 API。

• 第一种是 Sun 的 RPC/ONC 和 CORBA 的典型代表。在这种情况下，服务的规范是用一些抽象语言给出的，如 CORBA IDL（接口定义语言）。然后，这被编译成客户端和服务器的代码。然后，客户写一个正常的程序，其中包含对过程/函数/方法的调用，该程序被链接到生成的客户方代码。服务器端的代码实际上是一个服务器本身，它被链接到你所写的过程实现上。这样一来，客户端的代码在外观上与普通的过程调用几乎是一样的。一般来说，会有 有一点额外的代码来定位服务器。在 Sun 的 ONC 中，必须知道服务器的地址；在 CORBA 中，要调用命名服务来查找服务器的地址。命名服务来查找服务器的地址；在 Java RMI 中，IDL 是 Java 本身，命名服务被用来查找服务器的地址。 服务来寻找服务的地址。
• 第二种方式，你必须利用一个特殊的客户端 API。你在客户端把函数名和它的参数交给这个库。在服务器端，你必须自己明确地编写服务器，以及远程过程的实现。这种方法被许多 RPC 系统所使用，如 Web 服务。

RPC 与 REST 的区别？

RPC 与 REST 最大的区别就在于 RPC 提供了更好的抽象，RPC 甚至将网络传输细节彻底隐藏了，而 REST 没有。具体来说，REST 至少要求用于提供 URL 以及请求参数，而 RPC 隐藏了与网络传输的相关实现细节。另一方面，RPC 可以基于任何网络通信协议，而 REST 通常基于 HTTP（或者 HTTPS）协议。RPC 调用者并不会关心具体的协议是：HTTP、TCP 还是其他任何自定义协议。

RPC 的优缺点

以下是 RPC 为开发人员和应用程序管理员提供的一些优势：

• 帮助客户端通过传统使用高级语言的过程调用与服务器进行通信。
• 可以在分布式环境以及本地环境中使用。
• 支持面向进程和面向线程的模型。
• 对用户隐藏内部消息传递机制。
• 只需极少的努力即可重写和重新开发代码。
• 提供抽象，即对用户隐藏网络通信的消息传递性质。
• 省略许多协议层以提高性能。

另一方面，RPC 的一些缺点包括：

• 客户端和服务器对各自的例程使用不同的执行环境，并且资源（例如，文件）的使用也更加复杂。因此，RPC 系统并不总是适合传输大量数据。
• RPC 非常容易发生故障，因为它涉及通信系统，另一台计算机和另一个进程。
• RPC 没有统一的标准;它可以通过多种方式实现。
• RPC 只是基于交互的，因此，在硬件架构方面，它不提供任何灵活性。

参考链接：

• What is RPC？