转载:https://blog.csdn.net/zkp_java/article/details/81879577
RPC基本原理
RPC(Remote Procedure Call),远程过程调用,大部分的RPC框架都遵循如下三个开发步骤:
定义一个接口说明文件:描述了对象(结构体)、对象成员、接口方法等一系列信息;
通过RPC框架所提供的编译器,将接口说明文件编译成具体的语言文件;
在客户端和服务器端分别引入RPC编译器所生成的文件,即可像调用本地方法一样调用服务端代码;
定义一个接口说明文件:描述了对象结构体、对象成员、接口方法等一系列信息; 通过RPC框架所提供的编译器,将接口说明文件编译成具体的语言文件;
在客户端和服务器端分别引入RPC编译器所生成的文件,即可像调用本地方法一样调用服务端代码;
RPC通信过程如下图所示
通信过程包括以下几个步骤:
、客户过程以正常方式调用客户桩(client stub,一段代码);、客户桩生成一个消息,然后调用本地操作系统;
、客户端操作系统将消息发送给远程操作系统;
、远程操作系统将消息交给服务器桩(server stub,一段代码);
、服务器桩将参数提取出来,然后调用服务器过程;
、服务器执行要求的操作,操作完成后将结果返回给服务器桩;
、服务器桩将结果打包成一个消息,然后调用本地操作系统;
、服务器操作系统将含有结果的消息发送回客户端操作系统;
、客户端操作系统将消息交给客户桩;
、客户桩将结果从从消息中提取出来,返回给调用它的客户过程;
所有这些步骤的效果是,将客户过程对客户桩发出的本地调用转换成对服务器过程的本地调用,而客户端和服务器都不会意识到有中间步骤的存在。
这个时候,你可能会想,既然是调用另一台机器的服务,使用 RESTful API 也可以实现啊,为什么要选择 RPC 呢?我们可以从两个方面对比:
资源粒度。RPC 就像本地方法调用, API 每一次添加接口都可能需要额外地组织开放接口的数据, 这相当于在应用视图中再写了一次方法调用,而且它还需要维护开发接口的资源粒度、权限等;
流量消耗。 API 在应用层使用 HTTP 协议,哪怕使用轻型、高效、传输效率高的 JSON 也会消耗较
大的流量,而 RPC 传输既可以使用 TCP 也可以使用 UDP,而且协议一般使用二制度编码,大大降低了数据的
大小,减少流量消耗。
对接异构第三方服务时,通常使用 HTPP/RESTful 等公有协议,对于内部的服务调用,应用选择性能更高的二进制私有协议。
还没有评论,来说两句吧...