千字带你了解什么是 RPC 协议
什么是 RPC ?
RPC(Remote Procedure Call)远程过程调用协议是一个用于建立适当框架的协议。从本质上讲,它使一台机器上的程序能够调用另一台机器上的子程序,而不会意识到它是远程的。
RPC 是一种软件通信协议,一个程序可以用来向位于网络上另一台计算机的程序请求服务,而不必了解网络的细节。RPC 被用来像本地系统一样调用远程系统上的其他进程。过程调用有时也被称为函数调用或子程序调用。
为什么有 RPC?
Socket 和 HTTP 编程使用消息传递范式。客户端向服务器发送一个消息,而服务器通常会发送一个消息回来。双方都负责以双方都能理解的格式创建消息,并从这些消息中读出数据。
然而,大多数独立的应用程序并没有那么多地使用消息传递技术。一般来说,首选的机制是函数(或方法或过程)的调用。在这种方式中,程序将调用一个带有参数列表的函数,并在完成函数调用后有一组返回值。这些值可能是函数值,或者如果地址被作为参数传递,那么这些地址的内容可能已经被改变。地址的内容可能已经被改变。
RPC 就是将这种编程方式引入网络世界的一种尝试。因此,客户端将进行在它看来是正常的过程调用。客户端会将其打包成网络消息并传送给服务器。服务器会将其解包,并在服务器端将其转回为过程调用。服务器端的过程调用。这个调用的结果将被打包,以便返回给客户端。
本地过程和远程
过程是什么? 过程就是业务处理、计算任务,更直白的说,就是程序。
RPC 就是想调用本地方法一样调用远程的过程。与本地过程调用一样,RPC 也是一种同步操作,需要挂起请求程序,直到返回远程过程的结果。但是,使用共享相同地址空间的轻量级进程或线程可以同时执行多个 RPC。
RPC 如何工作
在 RPC 的工作期间,将执行以下步骤:
RPC 的工作过程如下:
-
服务消费方(client)调用以本地调用方式调用服务;
-
client stub 接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体;这就是所谓的marshalling。
-
client stub 找到服务地址,并将消息发送到服务端;这个过程可能是面向连接或无连接的。
-
server stub 收到消息后进行解码;也叫 unmarshalling。
-
server stub 根据解码结果调用本地的服务;
-
本地服务执行并将结果返回给 server stub ;
-
server stub 将返回结果打包成消息并发送至消费方;
-
client stub 接收到消息,并进行解码;
-
服务消费方得到最终结果。并且返回值被设置在本地进程的堆栈中。
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 只是基于交互的,因此,在硬件架构方面,它不提供任何灵活性。
参考链接:
- 点赞
- 收藏
- 关注作者
评论(0)