javarpc与webservice_RPC和WebService的区别

最近分析的这个系统&＃xff0c;逻辑架构中有一层是RPC interface。之前对RPC不熟悉&＃xff0c;就上网搜索了一下资料&＃xff0c;在此总结一下&＃xff1a;

RPC是Remote Procedure Calling&＃xff0c;远程过程调用的缩写。并不是“远程进程调用”——Remote Process Calling。RPC总的来说是一个Client/Server的结构&＃xff0c;提供服务的一方称为Server&＃xff0c;消费服务的一方称为Client。

下图是本地过程调用&＃xff0c;所有的过程都在本地服务器上&＃xff0c;依次调用即可。

下图则是所谓的远程过程调用&＃xff0c;需要在Client和Server中交互。

因此&＃xff0c;两种调用方式&＃xff0c;会产生什么区别呢&＃xff1f;

1、网络传输的开销和编程的额外复杂性。

2、本地过程调用中&＃xff0c;过程在同一块物理内存中&＃xff0c;因此就可以传递指针了。而远程过程调用则不能&＃xff0c;因为远程过程与调用者运行在完全不同的地址空间中。

3、远程过程不能共享调用者的环境&＃xff0c;所以它就无法直接访问调用者的I/O和操作系统API。

简单来说&＃xff0c;就是远程过程调用会比本地过程调用复杂。除了性能的额外开销之外&＃xff0c;编程也复杂得多。

至少可以想到&＃xff0c;交互双方需要能够封装数据结构&＃xff0c;理解协议&＃xff0c;处理连接等等&＃xff0c;确实是很麻烦的。可能一个很简单的调用&＃xff0c;却需要做很多的编程工作。所以&＃xff0c;为了简化RPC调用的编程&＃xff0c;就提出了一个RPC的标准模型。

下面是RPC的原理草图。

可以看到&＃xff0c;该模型中多了一个stub的组件&＃xff0c;这个是约定的接口&＃xff0c;也就是server提供的服务。注意这里的“接口”&＃xff0c;不是指JAVA中的interface&＃xff0c;因为RPC是跨平台跨语言的&＃xff0c;用JAVA写的客户端&＃xff0c;应该能够调用用C语言提供的过程。

对客户端来说&＃xff0c;有了这个stub&＃xff0c;RPC调用过程对client code来说就变成透明的了&＃xff0c;客户端代码不需要关心沟通的协议是什么&＃xff0c;网络连接是怎么建立的。对客户端来说&＃xff0c;它甚至不知道自己调用的是一个远程过程&＃xff0c;还是一个本地过程。

然后&＃xff0c;前面说的理解协议&＃xff0c;处理连接的工作&＃xff0c;总是要有人做的&＃xff0c;这个工作就是在下面的RPC Interface里完成的。

最近几年&＃xff0c;遇到这种场景(需要调用远程机器上的服务)&＃xff0c;往往会考虑用web service来完成&＃xff0c;其实我认为web service和RPC是非常相像的&＃xff0c;下面是web service的原理草图

对比一下RPC草图&＃xff0c;就会发现非常的接近。在组件层次&＃xff0c;和交互时序上完全没有差别&＃xff0c;只是方框内的字不一样&＃xff0c;但是实际上承担的职责却是完全对应的。

web service接口就是RPC中的stub组件&＃xff0c;规定了server能够提供的服务(web service)&＃xff0c;这在server和client上是一致的&＃xff0c;但是也是跨语言跨平台的。同时&＃xff0c;由于web service规范中的WSDL文件的存在&＃xff0c;现在各平台的web service框架&＃xff0c;都可以基于WSDL文件&＃xff0c;自动生成web service接口。

下面的web service框架&＃xff0c;根据所选的平台有所不同&＃xff0c;比如在JAVA平台中&＃xff0c;现在最流行的是apache的cxf框架。它做的事情也和RPC Interface是一样的&＃xff0c;负责解析协议(SOAP协议)&＃xff0c;负责处理连接(建立HTTP连接)。

因此&＃xff0c;我认为RPC和web service非常得接近&＃xff0c;只是RPC的传输层协议&＃xff0c;以及应用层协议&＃xff0c;可以自行实现&＃xff0c;所以选择的余地更大一点。可能会在性能和传输效率上&＃xff0c;有更大的优势(不一定) 。

和web service有很多成熟框架可供选择一样&＃xff0c;RPC也有很多现成的框架可供选择&＃xff0c;比如在JAVA平台上有nfs-rpc等。

总结来说&＃xff0c;要实现远程过程调用&＃xff0c;需要有3要素&＃xff1a;

1、server必须发布服务。

2、在client和server两端都需要有模块来处理协议和连接。

3、server发布的服务&＃xff0c;需要将接口给到client。

当然&＃xff0c;应用协议是什么样的&＃xff0c;怎么连接&＃xff0c;服务接口怎么给到client&＃xff0c;是可以自行实现的&＃xff0c;选择余地很大。但是RPC协议提供了一种标准的建议&＃xff0c;如果没有特别的理由&＃xff0c;我认为没有必要自行实现&＃xff0c;但是清楚这个原理&＃xff0c;总是好的。

最后回到我最近正在分析的系统上来说。本文一开始就提到&＃xff0c;它的架构中有一个RPC Interface。

由于这不是一个开源系统&＃xff0c;所以我并不清楚它的RPC Interface的实现&＃xff0c;也就是说&＃xff0c;我并不清楚它的应用协议和传输协议是什么。姑且假设它是用的标准RPC协议的。

但是它将server服务发布给client的方式&＃xff0c;是向client提供了API&＃xff0c;对JAVA平台的程序员来说&＃xff0c;就是一个xxx.jar。

这个jar包里&＃xff0c;有2部分内容&＃xff1a;

1、client stub&＃xff0c;包括接口和封装过的数据结构。即ServerService&＃xff0c;和XXXForm、XXXFilter等。那对于client程序员来说&＃xff0c;就只需要调用ServerService.xxxx()的方法&＃xff0c;并组装XXXForm对象作为参数即可&＃xff0c;类似

public interfaceServerService{publicXXXFilter giveMeTheFilter(XXXForm form);

}

程序员只需要关心怎么封装合适的XXXForm&＃xff0c;以及什么时候调用giveMeTheFilter()方法即可&＃xff0c;底层的协议&＃xff0c;server端的实现&＃xff0c;对client程序员来说都是透明的。

2、RPC Interface层的实现。这部分就做了协议解析、连接处理、异常处理等&＃xff0c;但这部分类&＃xff0c;是不对client程序员开放的。这种通过API(SDK)&＃xff0c;向client发布服务的方式&＃xff0c;我认为是有可取之处的。