RPC简介，及与web service的对比

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

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发布服务的方式，我认为是有可取之处的

rpc和ws最大的好处就是跨语言的

“rpc的传输层协议可以自己实现”这句话何解？
在我印象中，传输层协议好像只有tcp udp netbios这些，其中很多都淘汰了，用的普遍的就只有tcp，udp

像rcp，ssl这些协议是传输层和应用层之间的协议

http，rtsp，smtp等等这些是应用层协议

请楼主解释一下

嗯，这句话不是重点哈

如果用web service的话，那应用层的协议就是http+soap了（http内包含soap信息）；传输层是tcp

如果是自行实现RPC的话，假设不使用现有的RPC实现（比如SUN的），应用层的协议是可以自行实现的；传输层也可以选择使用tcp或者udp

我就是这个意思，呵呵

rpc最核心的就是数据对象的打包解包，

建议楼主去看下 google 的http://code.google.com/p/protobuf/