RPC和WebService的區別

最近分析的這個系統，邏輯架構中有一層是RPC interface。之前對RPC不熟悉，就上網搜索了一下資料，在此總結一下：

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協議提供了一種標準的建議，如果沒有特別的理由，我認爲沒有必要自行實現，但是清楚這個原理，總是好的。

最後回到我最近正在分析的系統上來說。本文一開始就提到，它的架構中有一個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發佈服務的方式，我認爲是有可取之處的。