转载自:http://blog.csdn.net/tanga842428/article/details/52159757
RPC是Remote Procedure Calling,远程过程调用的缩写。并不是“远程进程调用”——Remote Process Calling。RPC总的来说是一个Client/Server的结构,提供服务的一方称为Server,消费服务的一方称为Client。
下图是本地过程调用,所有的过程都在本地服务器上,依次调用即可。
下图是本地过程调用,所有的过程都在本地服务器上,依次调用即可。
下图则是所谓的远程过程调用,需要在Client和Server中交互。
因此,两种调用方式,会产生什么区别呢?
1、网络传输的开销和编程的额外复杂性。
2、本地过程调用中,过程在同一块物理内存中,因此就可以传递指针了。而远程过程调用则不能,因为远程过程与调用者运行在完全不同的地址空间中。
3、远程过程不能共享调用者的环境,所以它就无法直接访问调用者的I/O和操作系统API。
简单来说,就是远程过程调用会比本地过程调用复杂。除了性能的额外开销之外,编程也复杂得多。
至少可以想到,交互双方需要能够封装数据结构,理解协议,处理连接等等,确实是很麻烦的。可能一个很简单的调用,却需要做很多的编程工作。所以,为了简化RPC调用的编程,就提出了一个RPC的标准模型。
下面是RPC的原理草图。
可以看到,该模型中多了一个stub的组件,这个是约定的接口,也就是server提供的服务。注意这里的“接口”,不是指JAVA中的interface,因为RPC是跨平台跨语言的,用JAVA写的客户端,应该能够调用用C语言提供的过程。
对客户端来说,有了这个stub,RPC调用过程对client code来说就变成透明的了,客户端代码不需要关心沟通的协议是什么,网络连接是怎么建立的。对客户端来说,它甚至不知道自己调用的是一个远程过程,还是一个本地过程。
然后,前面说的理解协议,处理连接的工作,总是要有人做的,这个工作就是在下面的RPC Interface里完成的。
最近几年,遇到这种场景(需要调用远程机器上的服务),往往会考虑用web service来完成,其实我认为web service和RPC是非常相像的,下面是web service的原理草图
对比一下RPC草图,就会发现非常的接近。在组件层次,和交互时序上完全没有差别,只是方框内的字不一样,但是实际上承担的职责却是完全对应的。
web service接口就是RPC中的stub组件,规定了server能够提供的服务(web service),这在server和client上是一致的,但是也是跨语言跨平台的。同时,由于web service规范中的WSDL文件的存在,现在各平台的web service框架,都可以基于WSDL文件,自动生成web service接口。
下面的web service框架,根据所选的平台有所不同,比如在JAVA平台中,现在最流行的是apache的cxf框架。它做的事情也和RPC Interface是一样的,负责解析协议(SOAP协议),负责处理连接(建立HTTP连接)。
因此,我认为RPC和web service非常得接近,只是RPC的传输层协议,以及应用层协议,可以自行实现,所以选择的余地更大一点。可能会在性能和传输效率上,有更大的优势(不一定) 。
和web service有很多成熟框架可供选择一样,RPC也有很多现成的框架可供选择,比如在JAVA平台上有nfs-rpc等。
总结来说,要实现远程过程调用,需要有3要素:
1、server必须发布服务。
2、在client和server两端都需要有模块来处理协议和连接。
3、server发布的服务,需要将接口给到client。
当然,应用协议是什么样的,怎么连接,服务接口怎么给到client,是可以自行实现的,选择余地很大。但是RPC协议提供了一种标准的建议,如果没有特别的理由,我认为没有必要自行实现,但是清楚这个原理,总是好的。