RPC是一種方便的網(wǎng)絡(luò)通信編程模型，由于和編程語言的高度結(jié)合，大大減少了處理網(wǎng)絡(luò)數(shù)據(jù)的復(fù)雜度，讓代碼可讀性也有可觀的提高。但是RPC本身的構(gòu)成卻比較復(fù)雜，由于受到編程語言、網(wǎng)絡(luò)模型、使用習(xí)慣的約束，有大量的妥協(xié)和取舍之處。本文就是通過分析幾種流行的RPC實現(xiàn)案例，提供大家在設(shè)計RPC系統(tǒng)時的參考。
由于RPC底層的網(wǎng)絡(luò)開發(fā)一般和具體使用環(huán)境有關(guān)，而編程實現(xiàn)手段也非常多樣化，但不影響使用者，因此本文基本涉及如何實現(xiàn)一個RPC系統(tǒng)。
我們在各種操作系統(tǒng)、編程語言生態(tài)圈中，多少都會接觸過“遠程調(diào)用”的概念。一般來說，他們指的是用簡單的一行代碼，通過網(wǎng)絡(luò)調(diào)用另外一個計算機上的某段程序。比如：
遠程調(diào)用本身是網(wǎng)絡(luò)通信的一種概念，他的特點是把網(wǎng)絡(luò)通信封裝成一個類似函數(shù)的調(diào)用。網(wǎng)絡(luò)通信在遠程調(diào)用外，一般還有其他的幾種概念：數(shù)據(jù)包處理、消息隊列、流過濾、資源拉取等待。下面比較一下他們差異：
|
方案 |
編程方式 |
信息封裝 |
傳輸模型 |
典型應(yīng)用 |
|---|---|---|---|---|
遠程調(diào)用 | 調(diào)用函數(shù)，輸入?yún)?shù)，獲得返回值。 | 使用編程語言的變量、類型、函數(shù) | 發(fā)出請求，獲得響應(yīng) | Java RMI |
數(shù)據(jù)包處理 | 調(diào)用Send()/Recv()，使用字節(jié)碼數(shù)據(jù)，編解碼，處理內(nèi)容 | 把通信內(nèi)容構(gòu)造成二進制的協(xié)議包 | 發(fā)送/接收 | UDP編程 |
消息隊列 | 調(diào)用Put()/Get()，使用“包”對象，處理其包含的內(nèi)容 | 消息被封裝成語言可用的對象或結(jié)構(gòu) | 對某隊列，存入一個消息；取出一個消息 | ActiveMQ |
流過濾 | 讀取一個流，或?qū)懗鲆粋€流，對流中的單元包即刻處理 | 單元長度很小的統(tǒng)一數(shù)據(jù)結(jié)構(gòu) | 連接；發(fā)送/接收；處理 | 網(wǎng)絡(luò)視頻 |
資源拉取 | 輸入一個資源ID，獲得資源內(nèi)容 | 請求或響應(yīng)都包含：頭部+正文 | 請求后等待響應(yīng) | WWW |
針對遠程調(diào)用的特點——調(diào)用函數(shù)。業(yè)界在各種語言下都開發(fā)過類似的方案，同時也有些方案是試圖做到跨語言的。盡管遠程調(diào)用在編程方式上，看起來似乎是最簡單易用的，但是也有明顯的缺點。所以了解清楚遠程調(diào)用的優(yōu)勢和缺點，是決定是否要開發(fā)、或者使用遠程調(diào)用這種模型的關(guān)鍵問題。
遠程調(diào)用的優(yōu)勢有：
遠程調(diào)用的缺點：
因此，遠程調(diào)用最適合的場景是：業(yè)務(wù)需求多變，網(wǎng)絡(luò)環(huán)境多變。
由于遠程調(diào)用的使用接口是“函數(shù)”，所以要如何構(gòu)建這個“函數(shù)”，就產(chǎn)生了三個方面需要決策的問題：
所謂遠程，就是指網(wǎng)絡(luò)上另外一個位置，那么網(wǎng)絡(luò)地址就是必須要輸入的部分。在TCP/IP網(wǎng)絡(luò)下，IP地址和端口號代表了運行中程序的一個入口。所以指定IP地址和端口是發(fā)起遠程調(diào)用所必需的。
然而，一個程序可能會運行很多個功能，可以接收多個不同含義的遠程調(diào)用。這樣如何去讓用戶指定這些不同含義的遠程調(diào)用入口，就成為了另外一個問題。當(dāng)然最簡單的是每個端口一種調(diào)用，但是一個IP最多支持65535個端口，而且別的網(wǎng)絡(luò)功能也可能需要端口，所以這種方案可能會不夠用，同時一個數(shù)字代表一個功能也不太好理解，必須要查表才能明白。
所以我們必須想別的方法。在面向?qū)ο蟮乃枷胂?，有些方案提出了：以不同的對象來歸納不同的功能組合，先指定對象，再指定方法。這個想法非常符合程序員的理解方式，EJB就是這種方案的。一旦你確定了用對象這種模型來定義遠程調(diào)用的地址，那么你就需要有一種指定遠程對象的方法，為了指定對象，你必須要能把對象的一些信息，從被調(diào)用方（服務(wù)器端）傳輸給調(diào)用方（客戶端）。
最簡單的方案就是客戶端輸入一串字符串作為對象的“名字”，發(fā)給服務(wù)器端，查找注冊了這個“名字”的對象，如果找到了，服務(wù)器端就會用某種技術(shù)“傳輸”這個對象給客戶端，然后客戶端就可以調(diào)用他的方法了。當(dāng)然這種傳輸不可能是把整個服務(wù)器上的對象數(shù)據(jù)拷貝給客戶端，而是用一些符號或者標(biāo)志的方法，來代表這個服務(wù)器上的對象，然后發(fā)給客戶端。
如果你不是使用面向?qū)ο蟮哪Ｐ停敲催h程的一個函數(shù)，也是必須要定位和傳輸?shù)?，因為你調(diào)用的函數(shù)必須先能找到，然后成為客戶端側(cè)的一個接口，才能調(diào)用。針對“遠程對象”（這里說的對象包括面向?qū)ο蟮膶ο蠡蛘邇H僅是 函數(shù)）如何表達才能在網(wǎng)絡(luò)上定位；以及定位成功之后以什么形式供客戶端調(diào)用，都是“遠程調(diào)用”設(shè)計方案中第一個重要的問題。
遠程調(diào)用由于受到網(wǎng)絡(luò)通信的約束，所以往往不能完全的支持編程語言的所有特性。比如C語言函數(shù)中的指針類型參數(shù)，就無法通過網(wǎng)絡(luò)傳遞出去。因此遠程調(diào)用的函數(shù)定義，能用語言中的什么特性，不能用什么特性，是需要在設(shè)計方案是規(guī)定下來的。
這種規(guī)定如果太嚴格，會影響使用者的易用性；如果太寬泛，則可能導(dǎo)致遠程調(diào)用的性能低下。如何去設(shè)計一種方式，把編程語言中的函數(shù)，描述成一個遠程調(diào)用的函數(shù)，也是需要考慮的問題。很多方案采用了配置文件這種通用的方式，而另外一些方案可以直接在源代碼中里面加特殊的注釋。
一般來說，編譯型語言如C/C++只能采用源代碼根據(jù)配置文件生成的方案，虛擬機型語言如C#/JAVA可以采用反射機制結(jié)合配置文件（設(shè)置是在源代碼中用特殊注釋來代替配置文件）的方案，如果是腳本語言就更簡單，有時候連配置文件都不需要，因為腳本自己就可以充當(dāng)。總之遠程調(diào)用的接口要滿足怎樣的約束，也是一個需要仔細考慮的問題。
遠程調(diào)用最重要的實現(xiàn)細節(jié)，就是關(guān)于網(wǎng)絡(luò)通信。用何種通信方式來承載遠程調(diào)用的問題，細化下來就是兩個子問題：用什么樣的服務(wù)程序提供網(wǎng)絡(luò)功能？用什么樣的通信協(xié)議？
遠程調(diào)用系統(tǒng)可以自己直接對TCP/IP編程來實現(xiàn)通信，也可以委托一些其他軟件，比如Web服務(wù)器、消息隊列服務(wù)器等等……也可以使用不同的網(wǎng)絡(luò)通信框架，如Netty/Mina這些開源框架。通信協(xié)議則一般有兩層：一個是傳輸協(xié)議，比如TCP/UDP或者高層一點的HTTP，或者自己定義的傳輸協(xié)議；另外一個是編碼協(xié)議，就是如何把一個編程語言中的對象，序列化和反序列化成為二進制字節(jié)流的方案，流行的方案有JSON、Google Protocol Buffer等等，很多開發(fā)語言也有自己的序列化方案，如JAVA/C#都自帶。以上這些技術(shù)細節(jié)，應(yīng)該選擇使用哪些，直接關(guān)系到遠程調(diào)用系統(tǒng)的性能和環(huán)境兼容性。
以上三個問題，就是遠程調(diào)用系統(tǒng)必須考慮的核心選型。根據(jù)每個方案所面對的約束不同，他們都會在這三個問題上做出取舍，從而適應(yīng)其約束。但是現(xiàn)在并不存在一個“萬能”或者“通用”的方案，其原因就是：在如此復(fù)雜的一個系統(tǒng)中，如果要照顧的特性越多，需要付出的成本（易用性代價、性能開銷）也會越多。
下面，我們可以研究下業(yè)界現(xiàn)存的各種遠程調(diào)用方案，看他們是如何在這三個方面做平衡和選擇的。
CORBA是一個“古老”的，雄心勃勃的方案，他試圖在完成遠程調(diào)用的同時，還完成跨語言的通信的任務(wù)，因此其復(fù)雜程度是最高的，但是它的設(shè)計思想，也被后來更多的其他方案所學(xué)習(xí)。在通信對象的定位上，它使用URL來定義一個遠程對象，這是在互聯(lián)網(wǎng)時代非常容易接受的。其對象的內(nèi)容則限定在C語言類型上，并且只能傳遞值，這也是非常容易理解的。為了能讓不同語言的程序通信，所以就必須要在各種編程語言之外獨立設(shè)計一種僅僅用于描述遠程接口的語言，這就是所謂的IDL：Interface Description Language 接口描述語言。
用這個方法，你就可以先用一種超然于所有語言之外的語言來定義接口，然后使用工具自動生成各種編程語言的代碼。這種方案對于編譯型語言幾乎是唯一選擇。CORBA并沒有對通信問題有任何約定，而是留給具體語言的實現(xiàn)者去處理，這也許是他沒有廣泛流行的原因之一。
實際上CORBA有一個非常著名的繼承者，他就是Facebook公司的Thrift框架。Thrift也是使用一種IDL編譯生成多種語言的遠程調(diào)用方案，并且用C++/JAVA等多種語言完整的實現(xiàn)了通信承載，所以在開源框架中是特別有號召力的一個。Thrfit的通信承載還有個特點，就是能組合使用各種不同的傳輸協(xié)議和編碼協(xié)議，比如TCP/UDP/HTTP配合JSON/BIN/PB……這讓它幾乎可以選擇任何的網(wǎng)絡(luò)環(huán)境。
Thrift的模型類似下圖，這里有的stub表示“樁代碼”，就是客戶端直接使用的函數(shù)形式程序；skeleton表示“骨架代碼”，是需要程序員編寫具體提供遠程服務(wù)功能的模板代碼，一般對模版做填空或者繼承（擴展）即可。這個stub-skeleton模型幾乎是所有遠程調(diào)用方案的標(biāo)配。
JAVA RMI是JAVA虛擬機自帶的一個遠程調(diào)用方案。它也是可以使用URL來定位遠程對象，使用JAVA自帶的序列化編碼協(xié)議傳遞參數(shù)值。在接口描述上，由于這是一個僅限于JAVA環(huán)境下的方案，所以直接用JAVA語言的Interface類型作為定義語言。用戶通過實現(xiàn)這個接口類型來提供遠程服務(wù)，同時JAVA會根據(jù)這個接口文件自動生成客戶端的調(diào)用代碼供調(diào)用者使用。他的底層通信實現(xiàn)，還是用TCP協(xié)議實現(xiàn)的。在這里，Interface文件就是JAVA語言的IDL，同時也是skeleton模板，供開發(fā)者來填寫遠程服務(wù)內(nèi)容。而stub代碼則由于JAVA的反射功能，由虛擬機直接包辦了。
這個方案由于JAVA虛擬機的支持，使用起來非常簡單，完全按照標(biāo)志的JAVA編程方法就可以輕松解決問題，但是這也僅僅能在JAVA環(huán)境下運行，限制了其適用的范圍。魚與熊掌不可兼得，易用性和適用性往往是互相沖突的。這和CORBA/Thrift追求大范圍的適用性有很大的差別，也導(dǎo)致了兩者在易用性上的不同。
Windows中對RPC支持是比較早和比較完善的。首先它通過GUID來查詢對象，然后使用C語言類型作為參數(shù)值的傳遞。由于Windows的API主要是C語言的，所以對于RPC功能來說，還是要用一種IDL來描述接口，最后生成.h和.c文件來生產(chǎn)RPC的stub和skeleton代碼。而通信機制，由于是操作系統(tǒng)自帶的，所以使用內(nèi)核LPC機制承載，這一點還是對使用者來說比較方便的。但是也限制了只能用于Windows程序之間做調(diào)用。
在互聯(lián)網(wǎng)時代，程序需要通過互聯(lián)網(wǎng)來互相調(diào)用。而互聯(lián)網(wǎng)上最流行的協(xié)議是HTTP協(xié)議和WWW服務(wù)，因此使用HTTP協(xié)議的Web Service就順理成章的成為跨系統(tǒng)調(diào)用的最流行方案。由于可以使用大多數(shù)互聯(lián)網(wǎng)的基礎(chǔ)設(shè)施，所以Web Service的開發(fā)和實現(xiàn)幾乎是毫無難度的。一般來說，它都會使用URL來定位遠程對象，而參數(shù)則通過一系列預(yù)定義的類型（主要是C語言基礎(chǔ)類型），以及對象序列化方式來傳遞。接口生成方面，你可以自己直接對HTTP做解析，也可以使用諸如WSDL或者SOAP這樣的規(guī)范。在REST的方案中，則限定了只有PUT/GET/DELETE/POST四種操作函數(shù)，其他都是參數(shù)。
總結(jié)一下上面的這些RPC方案，我們發(fā)現(xiàn)，針對遠程調(diào)用的三個核心問題，一般業(yè)界有以下幾個選擇：
在我們確定了遠程調(diào)用系統(tǒng)方案幾個可行選擇后，自然就要明確一下各個方案的優(yōu)缺點，這樣才能選擇真正合適需求的設(shè)計：
1. 對于遠程對象的描述： 使用URL是互聯(lián)網(wǎng)通行的標(biāo)準(zhǔn)，比較方便用戶理解，也容易添加日后需要擴展到內(nèi)容，因為URL本身是一個由多個部分組合的字符串；而名字服務(wù)則老式一些，但是依然有他的好處，就是名字服務(wù)可以附帶負載均衡、容災(zāi)擴容、自定義路由等一系列特性，對于需求復(fù)雜的定位比較容易實現(xiàn)。
2. 遠程調(diào)用的接口描述： 如果只限制于某個語言、操作系統(tǒng)、平臺上，直接利用“隱喻”方式的接口描述，或者以“注解”類型注釋手段來標(biāo)注源代碼，實現(xiàn)遠程調(diào)用接口的定義，是最方便不過的。但是，如果需要兼容編譯型語言，如C/C++，就一定要用某種IDL來生成這些編譯語言的源代碼了。
3.通信承載： 給用戶自己定制通信模塊，能提供最好的適用性，但是也讓用戶增加了使用的復(fù)雜程度。而HTTP/消息隊列這種承載方式，在系統(tǒng)的部署、運維、編程上都會比較簡單，缺點就是對于性能、傳輸特性的定制空間就比較小。
分析完核心問題，我們還需要考慮一些適用性場景：
1. 面向?qū)ο筮€是面向過程： 如果我們只是考慮做面向過程的遠程調(diào)用，只需要定位到“函數(shù)”即可。而如果是面向?qū)ο蟮?，則需要定位到“對象”。由于函數(shù)是無狀態(tài)的，所以其定位過程可以簡單到一個名字即可，而對象則需要動態(tài)的查找到其ID或句柄。
2.跨語言還是單一語言： 單一語言的方案中，頭文件或接口定義完全用一種語言處理即可，如果是跨語言的，就少不免要IDL
3. 混合式通信承載還是使用HTTP服務(wù)器承載： 混合式承載可能可以用到TCP/UDP/共享內(nèi)存等底層技術(shù)，可以提供最優(yōu)的性能，但是使用起來必然非常麻煩。使用HTTP服務(wù)器的話，則非常簡單，因為WWW服務(wù)的開源軟件、庫眾多，而且客戶端使用瀏覽器或者一些JS頁面即可調(diào)試，缺點是其性能較低。
假設(shè)我們現(xiàn)在要為某種業(yè)務(wù)邏輯非常多變的領(lǐng)域，如企業(yè)業(yè)務(wù)應(yīng)用領(lǐng)域，或游戲服務(wù)器端領(lǐng)域，去設(shè)計一個遠程調(diào)用系統(tǒng)，我們可能應(yīng)該如下選擇：
1. 使用名字服務(wù)定位遠程對象： 由于企業(yè)服務(wù)是需要高可用性的，使用名字服務(wù)能在查詢名字時識別和選擇可用性 服務(wù)對象。J2EE方案中的EJB（企業(yè)JavaBean）就是用名字服務(wù)的。
2. 使用IDL來生成接口定義： 由于企業(yè)服務(wù)或游戲服務(wù)，其開發(fā)語言可能不是統(tǒng)一的，又或者需要高性能的編程語言如C/C++，所以只能使用IDL。
3.使用混合式通信承載： 雖然企業(yè)服務(wù)看起來無需在很復(fù)雜的網(wǎng)絡(luò)下運行，但是不同的企業(yè)的網(wǎng)絡(luò)環(huán)境又可能是千差萬別的，所以要做一個通用的系統(tǒng)，最好還是不怕麻煩提供混合式的通信承載，這樣可以在TCP/UDP等各種協(xié)議中選擇。
重慶分公司
重慶分公司
