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的原理草圖
Java程式碼
- public interface ServerService{
- public XXXFilter giveMeTheFilter(XXXForm form);
- }
程式設計師只需要關心怎麼封裝合適的XXXForm,以及什麼時候呼叫giveMeTheFilter()方法即可,底層的協議,server端的實現,對client程式設計師來說都是透明的。 2、RPC Interface層的實現。這部分就做了協議解析、連線處理、異常處理等,但這部分類,是不對client程式設計師開放的。這種通過API(SDK),向client釋出服務的方式,我認為是有可取之處的。