浏览 5706 次
精华帖 (1) :: 良好帖 (1) :: 新手帖 (3) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2012-12-11
最后修改:2012-12-11
RPC是Remote Procedure Calling,远程过程调用的缩写。并不是“远程进程调用”——Remote Process Calling哦 RPC总的来说是一个Client/Server的结构,提供服务的一方称为Server,消费服务的一方称为Client 哎,笔记本上什么画图软件都没装,只好用WINDOWS的画图随便画点示意的草图了 下图是本地过程调用,所有的过程都在本地服务器上,依次调用即可 下图则是所谓的远程过程调用,需要在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协议提供了一种标准的建议,如果没有特别的理由,我认为没有必要自行实现,但是清楚这个原理,总是好的 最后回到我最近正在分析的系统上来说。本文一开始就提到,它的架构中有一个RPC Interface 由于这不是一个开源系统,所以我并不清楚它的RPC Interface的实现,也就是说,我并不清楚它的应用协议和传输协议是什么。姑且假设它是用的标准RPC协议的 但是它将server服务发布给client的方式,是向client提供了API,对JAVA平台的程序员来说,就是一个xxx.jar 这个jar包里,有2部分内容: 1、client stub,包括接口和封装过的数据结构。即ServerService,和XXXForm、XXXFilter等。那对于client程序员来说,就只需要调用ServerService.xxxx()的方法,并组装XXXForm对象作为参数即可,类似 public interface ServerService{ public XXXFilter giveMeTheFilter(XXXForm form); } 程序员只需要关心怎么封装合适的XXXForm,以及什么时候调用giveMeTheFilter()方法即可,底层的协议,server端的实现,对client程序员来说都是透明的 2、RPC Interface层的实现。这部分就做了协议解析、连接处理、异常处理等,但这部分类,是不对client程序员开放的 这种通过API(SDK),向client发布服务的方式,我认为是有可取之处的 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2012-12-11
rpc和ws最大的好处就是跨语言的
|
|
返回顶楼 | |
发表时间:2012-12-11
最后修改:2012-12-11
“rpc的传输层协议可以自己实现”这句话何解?
在我印象中,传输层协议好像只有tcp udp netbios这些,其中很多都淘汰了,用的普遍的就只有tcp,udp 像rcp,ssl这些协议是传输层和应用层之间的协议 http,rtsp,smtp等等这些是应用层协议 请楼主解释一下 |
|
返回顶楼 | |
发表时间:2012-12-11
嗯,这句话不是重点哈
如果用web service的话,那应用层的协议就是http+soap了(http内包含soap信息);传输层是tcp 如果是自行实现RPC的话,假设不使用现有的RPC实现(比如SUN的),应用层的协议是可以自行实现的;传输层也可以选择使用tcp或者udp 我就是这个意思,呵呵 |
|
返回顶楼 | |
发表时间:2012-12-12
rpc最核心的就是数据对象的打包解包,
建议楼主去看下 google 的http://code.google.com/p/protobuf/ |
|
返回顶楼 | |