怎么設(shè)計(jì)一個(gè)RPC系統(tǒng)

這篇文章主要講解了“怎么設(shè)計(jì)一個(gè)RPC系統(tǒng)”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來(lái)研究和學(xué)習(xí)“怎么設(shè)計(jì)一個(gè)RPC系統(tǒng)”吧！

10年的茌平網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對(duì)設(shè)計(jì)、前端、開發(fā)、售后、文案、推廣等六對(duì)一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。全網(wǎng)營(yíng)銷推廣的優(yōu)勢(shì)是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整茌平建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無(wú)論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。創(chuàng)新互聯(lián)從事“茌平網(wǎng)站設(shè)計(jì)”,“茌平網(wǎng)站推廣”以來(lái)，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。

由于RPC底層的網(wǎng)絡(luò)開發(fā)一般和具體使用環(huán)境有關(guān)，而編程實(shí)現(xiàn)手段也非常多樣化，但不影響使用者，因此本文基本涉及如何實(shí)現(xiàn)一個(gè)RPC系統(tǒng)。

認(rèn)識(shí) RPC (遠(yuǎn)程調(diào)用)

我們?cè)诟鞣N操作系統(tǒng)、編程語(yǔ)言生態(tài)圈中，多少都會(huì)接觸過(guò)“遠(yuǎn)程調(diào)用”的概念。一般來(lái)說(shuō)，他們指的是用簡(jiǎn)單的一行代碼，通過(guò)網(wǎng)絡(luò)調(diào)用另外一個(gè)計(jì)算機(jī)上的某段程序。比如：

  • RMI——Remote Method Invoke：調(diào)用遠(yuǎn)程的方法。“方法”一般是附屬于某個(gè)對(duì)象上的，所以通常RMI指對(duì)在遠(yuǎn)程的計(jì)算機(jī)上的某個(gè)對(duì)象，進(jìn)行其方法函數(shù)的調(diào)用。

  • RPC——Remote Procedure Call：遠(yuǎn)程過(guò)程調(diào)用。指的是對(duì)網(wǎng)絡(luò)上另外一個(gè)計(jì)算機(jī)上的，某段特定的函數(shù)代碼的調(diào)用。

遠(yuǎn)程調(diào)用本身是網(wǎng)絡(luò)通信的一種概念，他的特點(diǎn)是把網(wǎng)絡(luò)通信封裝成一個(gè)類似函數(shù)的調(diào)用。網(wǎng)絡(luò)通信在遠(yuǎn)程調(diào)用外，一般還有其他的幾種概念：數(shù)據(jù)包處理、消息隊(duì)列、流過(guò)濾、資源拉取等待。下面比較一下他們差異：

方案編程方式信息封裝傳輸模型典型應(yīng)用

  • 遠(yuǎn)程調(diào)用調(diào)用函數(shù)，輸入?yún)?shù)，獲得返回值。使用編程語(yǔ)言的變量、類型、函數(shù)發(fā)出請(qǐng)求，獲得響應(yīng)Java RMI

  • 數(shù)據(jù)包處理調(diào)用Send()/Recv()，使用字節(jié)碼數(shù)據(jù)，編解碼，處理內(nèi)容把通信內(nèi)容構(gòu)造成二進(jìn)制的協(xié)議包發(fā)送/接收UDP編程

  • 消息隊(duì)列調(diào)用Put()/Get()，使用“包”對(duì)象，處理其包含的內(nèi)容消息被封裝成語(yǔ)言可用的對(duì)象或結(jié)構(gòu)對(duì)某隊(duì)列，存入一個(gè)消息;取出一個(gè)消息ActiveMQ

  • 流過(guò)濾讀取一個(gè)流，或?qū)懗鲆粋€(gè)流，對(duì)流中的單元包即刻處理單元長(zhǎng)度很小的統(tǒng)一數(shù)據(jù)結(jié)構(gòu)連接;發(fā)送/接收;處理網(wǎng)絡(luò)視頻

  • 資源拉取輸入一個(gè)資源ID，獲得資源內(nèi)容請(qǐng)求或響應(yīng)都包含：頭部+正文請(qǐng)求后等待響應(yīng)WWW

  • 針對(duì)遠(yuǎn)程調(diào)用的特點(diǎn)——調(diào)用函數(shù)。業(yè)界在各種語(yǔ)言下都開發(fā)過(guò)類似的方案，同時(shí)也有些方案是試圖做到跨語(yǔ)言的。盡管遠(yuǎn)程調(diào)用在編程方式上，看起來(lái)似乎是最簡(jiǎn)單易用的，但是也有明顯的缺點(diǎn)。所以了解清楚遠(yuǎn)程調(diào)用的優(yōu)勢(shì)和缺點(diǎn)，是決定是否要開發(fā)、或者使用遠(yuǎn)程調(diào)用這種模型的關(guān)鍵問題。

遠(yuǎn)程調(diào)用的優(yōu)勢(shì)有：

  • 屏蔽了網(wǎng)絡(luò)層。因此在傳輸協(xié)議和編碼協(xié)議上，我們可以選擇不同的方案。比如WebService方案就是用的HTTP傳輸協(xié)議+SOAP編碼協(xié)議;而REST的方案往往使用HTTP+JSON協(xié)議。Facebook的Thrift甚至可以定制任何不同的傳輸協(xié)議和編碼協(xié)議，你可以用TCP+Google Protocol Buffer，也可以用UDP+JSON……。由于屏蔽了網(wǎng)絡(luò)層，你可以根據(jù)實(shí)際需要來(lái)獨(dú)立的優(yōu)化網(wǎng)絡(luò)部分，而無(wú)需涉及業(yè)務(wù)邏輯的處理代碼，這對(duì)于需要在各種網(wǎng)絡(luò)環(huán)境下運(yùn)行的程序來(lái)說(shuō)，非常有價(jià)值。

  • 函數(shù)映射協(xié)議。你可以直接用編程語(yǔ)言來(lái)書寫數(shù)據(jù)結(jié)構(gòu)和函數(shù)定義，取代編寫大量的編碼協(xié)議格式和分包處理邏輯。對(duì)于那些業(yè)務(wù)邏輯非常復(fù)雜的系統(tǒng)，比如網(wǎng)絡(luò)游戲，可以節(jié)省大量定義消息格式的時(shí)間。而且函數(shù)調(diào)用模型非常容易學(xué)習(xí)，不需要學(xué)習(xí)通信協(xié)議和流程，讓經(jīng)驗(yàn)較淺的程序員也能很容易的開始使用網(wǎng)絡(luò)編程。

遠(yuǎn)程調(diào)用的缺點(diǎn)：

  • 增加了性能消耗。由于把網(wǎng)絡(luò)通信包裝成“函數(shù)”，需要大量額外的處理。比如需要預(yù)生產(chǎn)代碼，或者使用反射機(jī)制。這些都是額外消耗CPU和內(nèi)存的操作。而且為了表達(dá)復(fù)雜的數(shù)據(jù)類型，比如變長(zhǎng)的類型string/map/list，這些都要數(shù)據(jù)包中增加更多的描述性信息，則會(huì)占用更多的網(wǎng)絡(luò)包長(zhǎng)度。

  • 不必要的復(fù)雜化。如果你僅僅是為了某些特定的業(yè)務(wù)需求，比如傳送一個(gè)固定的文件，那么你應(yīng)該用HTTP/FTP協(xié)議模型。如果為了做監(jiān)控或者IM軟件，用簡(jiǎn)單的消息編碼收發(fā)會(huì)更快速高效。如果是為了做代理服務(wù)器，用流式的處理會(huì)很簡(jiǎn)單。另外，如果你要做數(shù)據(jù)廣播，那么消息隊(duì)列會(huì)很容易做到，而遠(yuǎn)程調(diào)用這幾乎無(wú)法完成。

因此，遠(yuǎn)程調(diào)用最適合的場(chǎng)景是：業(yè)務(wù)需求多變，網(wǎng)絡(luò)環(huán)境多變。

RPC方案的核心問題

由于遠(yuǎn)程調(diào)用的使用接口是“函數(shù)”，所以要如何構(gòu)建這個(gè)“函數(shù)”，就產(chǎn)生了三個(gè)方面需要決策的問題：

1 . 如何表示“遠(yuǎn)程”的信息

所謂遠(yuǎn)程，就是指網(wǎng)絡(luò)上另外一個(gè)位置，那么網(wǎng)絡(luò)地址就是必須要輸入的部分。在TCP/IP網(wǎng)絡(luò)下，IP地址和端口號(hào)代表了運(yùn)行中程序的一個(gè)入口。所以指定IP地址和端口是發(fā)起遠(yuǎn)程調(diào)用所必需的。

然而，一個(gè)程序可能會(huì)運(yùn)行很多個(gè)功能，可以接收多個(gè)不同含義的遠(yuǎn)程調(diào)用。這樣如何去讓用戶指定這些不同含義的遠(yuǎn)程調(diào)用入口，就成為了另外一個(gè)問題。當(dāng)然最簡(jiǎn)單的是每個(gè)端口一種調(diào)用，但是一個(gè)IP最多支持65535個(gè)端口，而且別的網(wǎng)絡(luò)功能也可能需要端口，所以這種方案可能會(huì)不夠用，同時(shí)一個(gè)數(shù)字代表一個(gè)功能也不太好理解，必須要查表才能明白。

所以我們必須想別的方法。在面向?qū)ο蟮乃枷胂?，有些方案提出了：以不同的?duì)象來(lái)歸納不同的功能組合，先指定對(duì)象，再指定方法。這個(gè)想法非常符合程序員的理解方式，EJB就是這種方案的。一旦你確定了用對(duì)象這種模型來(lái)定義遠(yuǎn)程調(diào)用的地址，那么你就需要有一種指定遠(yuǎn)程對(duì)象的方法，為了指定對(duì)象，你必須要能把對(duì)象的一些信息，從被調(diào)用方(服務(wù)器端)傳輸給調(diào)用方(客戶端)。

最簡(jiǎn)單的方案就是客戶端輸入一串字符串作為對(duì)象的“名字”，發(fā)給服務(wù)器端，查找注冊(cè)了這個(gè)“名字”的對(duì)象，如果找到了，服務(wù)器端就會(huì)用某種技術(shù)“傳輸”這個(gè)對(duì)象給客戶端，然后客戶端就可以調(diào)用他的方法了。當(dāng)然這種傳輸不可能是把整個(gè)服務(wù)器上的對(duì)象數(shù)據(jù)拷貝給客戶端，而是用一些符號(hào)或者標(biāo)志的方法，來(lái)代表這個(gè)服務(wù)器上的對(duì)象，然后發(fā)給客戶端。

如果你不是使用面向?qū)ο蟮哪Ｐ?，那么遠(yuǎn)程的一個(gè)函數(shù)，也是必須要定位和傳輸?shù)?，因?yàn)槟阏{(diào)用的函數(shù)必須先能找到，然后成為客戶端側(cè)的一個(gè)接口，才能調(diào)用。針對(duì)“遠(yuǎn)程對(duì)象”(這里說(shuō)的對(duì)象包括面向?qū)ο蟮膶?duì)象或者僅僅是 函數(shù))如何表達(dá)才能在網(wǎng)絡(luò)上定位;以及定位成功之后以什么形式供客戶端調(diào)用，都是“遠(yuǎn)程調(diào)用”設(shè)計(jì)方案中第一個(gè)重要的問題。

2 . 函數(shù)的接口形式應(yīng)該如何表示

遠(yuǎn)程調(diào)用由于受到網(wǎng)絡(luò)通信的約束，所以往往不能完全的支持編程語(yǔ)言的所有特性。比如C語(yǔ)言函數(shù)中的指針類型參數(shù)，就無(wú)法通過(guò)網(wǎng)絡(luò)傳遞出去。因此遠(yuǎn)程調(diào)用的函數(shù)定義，能用語(yǔ)言中的什么特性，不能用什么特性，是需要在設(shè)計(jì)方案是規(guī)定下來(lái)的。

這種規(guī)定如果太嚴(yán)格，會(huì)影響使用者的易用性;如果太寬泛，則可能導(dǎo)致遠(yuǎn)程調(diào)用的性能低下。如何去設(shè)計(jì)一種方式，把編程語(yǔ)言中的函數(shù)，描述成一個(gè)遠(yuǎn)程調(diào)用的函數(shù)，也是需要考慮的問題。很多方案采用了配置文件這種通用的方式，而另外一些方案可以直接在源代碼中里面加特殊的注釋。

一般來(lái)說(shuō)，編譯型語(yǔ)言如C/C++只能采用源代碼根據(jù)配置文件生成的方案，虛擬機(jī)型語(yǔ)言如C#/JAVA可以采用反射機(jī)制結(jié)合配置文件(設(shè)置是在源代碼中用特殊注釋來(lái)代替配置文件)的方案，如果是腳本語(yǔ)言就更簡(jiǎn)單，有時(shí)候連配置文件都不需要，因?yàn)槟_本自己就可以充當(dāng)?？傊h(yuǎn)程調(diào)用的接口要滿足怎樣的約束，也是一個(gè)需要仔細(xì)考慮的問題。

3. 用什么方法來(lái)實(shí)現(xiàn)網(wǎng)絡(luò)通信

遠(yuǎn)程調(diào)用最重要的實(shí)現(xiàn)細(xì)節(jié)，就是關(guān)于網(wǎng)絡(luò)通信。用何種通信方式來(lái)承載遠(yuǎn)程調(diào)用的問題，細(xì)化下來(lái)就是兩個(gè)子問題：用什么樣的服務(wù)程序提供網(wǎng)絡(luò)功能?用什么樣的通信協(xié)議?

遠(yuǎn)程調(diào)用系統(tǒng)可以自己直接對(duì)TCP/IP編程來(lái)實(shí)現(xiàn)通信，也可以委托一些其他軟件，比如Web服務(wù)器、消息隊(duì)列服務(wù)器等等……也可以使用不同的網(wǎng)絡(luò)通信框架，如Netty/Mina這些開源框架。通信協(xié)議則一般有兩層：一個(gè)是傳輸協(xié)議，比如TCP/UDP或者高層一點(diǎn)的HTTP，或者自己定義的傳輸協(xié)議;另外一個(gè)是編碼協(xié)議，就是如何把一個(gè)編程語(yǔ)言中的對(duì)象，序列化和反序列化成為二進(jìn)制字節(jié)流的方案，流行的方案有JSON、Google Protocol Buffer等等，很多開發(fā)語(yǔ)言也有自己的序列化方案，如JAVA/C#都自帶。以上這些技術(shù)細(xì)節(jié)，應(yīng)該選擇使用哪些，直接關(guān)系到遠(yuǎn)程調(diào)用系統(tǒng)的性能和環(huán)境兼容性。

怎么設(shè)計(jì)一個(gè)RPC系統(tǒng)

以上三個(gè)問題，就是遠(yuǎn)程調(diào)用系統(tǒng)必須考慮的核心選型。根據(jù)每個(gè)方案所面對(duì)的約束不同，他們都會(huì)在這三個(gè)問題上做出取舍，從而適應(yīng)其約束。但是現(xiàn)在并不存在一個(gè)“萬(wàn)能”或者“通用”的方案，其原因就是：在如此復(fù)雜的一個(gè)系統(tǒng)中，如果要照顧的特性越多，需要付出的成本(易用性代價(jià)、性能開銷)也會(huì)越多。

下面，我們可以研究下業(yè)界現(xiàn)存的各種遠(yuǎn)程調(diào)用方案，看他們是如何在這三個(gè)方面做平衡和選擇的。

業(yè)界方案舉例

1. CORBA

CORBA是一個(gè)“古老”的，雄心勃勃的方案，他試圖在完成遠(yuǎn)程調(diào)用的同時(shí)，還完成跨語(yǔ)言的通信的任務(wù)，因此其復(fù)雜程度是最高的，但是它的設(shè)計(jì)思想，也被后來(lái)更多的其他方案所學(xué)習(xí)。在通信對(duì)象的定位上，它使用URL來(lái)定義一個(gè)遠(yuǎn)程對(duì)象，這是在互聯(lián)網(wǎng)時(shí)代非常容易接受的。其對(duì)象的內(nèi)容則限定在C語(yǔ)言類型上，并且只能傳遞值，這也是非常容易理解的。為了能讓不同語(yǔ)言的程序通信，所以就必須要在各種編程語(yǔ)言之外獨(dú)立設(shè)計(jì)一種僅僅用于描述遠(yuǎn)程接口的語(yǔ)言，這就是所謂的IDL：Interface Description Language 接口描述語(yǔ)言。

用這個(gè)方法，你就可以先用一種超然于所有語(yǔ)言之外的語(yǔ)言來(lái)定義接口，然后使用工具自動(dòng)生成各種編程語(yǔ)言的代碼。這種方案對(duì)于編譯型語(yǔ)言幾乎是唯一選擇。CORBA并沒有對(duì)通信問題有任何約定，而是留給具體語(yǔ)言的實(shí)現(xiàn)者去處理，這也許是他沒有廣泛流行的原因之一。

實(shí)際上CORBA有一個(gè)非常著名的繼承者，他就是Facebook公司的Thrift框架。Thrift也是使用一種IDL編譯生成多種語(yǔ)言的遠(yuǎn)程調(diào)用方案，并且用C++/JAVA等多種語(yǔ)言完整的實(shí)現(xiàn)了通信承載，所以在開源框架中是特別有號(hào)召力的一個(gè)。Thrfit的通信承載還有個(gè)特點(diǎn)，就是能組合使用各種不同的傳輸協(xié)議和編碼協(xié)議，比如TCP/UDP/HTTP配合JSON/BIN/PB……這讓它幾乎可以選擇任何的網(wǎng)絡(luò)環(huán)境。

Thrift的模型類似下圖，這里有的stub表示“樁代碼”，就是客戶端直接使用的函數(shù)形式程序;skeleton表示“骨架代碼”，是需要程序員編寫具體提供遠(yuǎn)程服務(wù)功能的模板代碼，一般對(duì)模版做填空或者繼承(擴(kuò)展)即可。這個(gè)stub-skeleton模型幾乎是所有遠(yuǎn)程調(diào)用方案的標(biāo)配。

怎么設(shè)計(jì)一個(gè)RPC系統(tǒng)

2. JAVA RMI

JAVA RMI是JAVA虛擬機(jī)自帶的一個(gè)遠(yuǎn)程調(diào)用方案。它也是可以使用URL來(lái)定位遠(yuǎn)程對(duì)象，使用JAVA自帶的序列化編碼協(xié)議傳遞參數(shù)值。在接口描述上，由于這是一個(gè)僅限于JAVA環(huán)境下的方案，所以直接用JAVA語(yǔ)言的Interface類型作為定義語(yǔ)言。用戶通過(guò)實(shí)現(xiàn)這個(gè)接口類型來(lái)提供遠(yuǎn)程服務(wù)，同時(shí)JAVA會(huì)根據(jù)這個(gè)接口文件自動(dòng)生成客戶端的調(diào)用代碼供調(diào)用者使用。他的底層通信實(shí)現(xiàn)，還是用TCP協(xié)議實(shí)現(xiàn)的。在這里，Interface文件就是JAVA語(yǔ)言的IDL，同時(shí)也是skeleton模板，供開發(fā)者來(lái)填寫遠(yuǎn)程服務(wù)內(nèi)容。而stub代碼則由于JAVA的反射功能，由虛擬機(jī)直接包辦了。

這個(gè)方案由于JAVA虛擬機(jī)的支持，使用起來(lái)非常簡(jiǎn)單，完全按照標(biāo)志的JAVA編程方法就可以輕松解決問題，但是這也僅僅能在JAVA環(huán)境下運(yùn)行，限制了其適用的范圍。魚與熊掌不可兼得，易用性和適用性往往是互相沖突的。這和CORBA/Thrift追求最大范圍的適用性有很大的差別，也導(dǎo)致了兩者在易用性上的不同。

3. Windows RPC

Windows中對(duì)RPC支持是比較早和比較完善的。首先它通過(guò)GUID來(lái)查詢對(duì)象，然后使用C語(yǔ)言類型作為參數(shù)值的傳遞。由于Windows的API主要是C語(yǔ)言的，所以對(duì)于RPC功能來(lái)說(shuō)，還是要用一種IDL來(lái)描述接口，最后生成.h和.c文件來(lái)生產(chǎn)RPC的stub和skeleton代碼。而通信機(jī)制，由于是操作系統(tǒng)自帶的，所以使用內(nèi)核LPC機(jī)制承載，這一點(diǎn)還是對(duì)使用者來(lái)說(shuō)比較方便的。但是也限制了只能用于Windows程序之間做調(diào)用。

4. WebService & REST

在互聯(lián)網(wǎng)時(shí)代，程序需要通過(guò)互聯(lián)網(wǎng)來(lái)互相調(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ā)和實(shí)現(xiàn)幾乎是毫無(wú)難度的。一般來(lái)說(shuō)，它都會(huì)使用URL來(lái)定位遠(yuǎn)程對(duì)象，而參數(shù)則通過(guò)一系列預(yù)定義的類型(主要是C語(yǔ)言基礎(chǔ)類型)，以及對(duì)象序列化方式來(lái)傳遞。接口生成方面，你可以自己直接對(duì)HTTP做解析，也可以使用諸如WSDL或者SOAP這樣的規(guī)范。在REST的方案中，則限定了只有PUT/GET/DELETE/POST四種操作函數(shù)，其他都是參數(shù)。

怎么設(shè)計(jì)一個(gè)RPC系統(tǒng)

總結(jié)一下上面的這些RPC方案，我們發(fā)現(xiàn)，針對(duì)遠(yuǎn)程調(diào)用的三個(gè)核心問題，一般業(yè)界有以下幾個(gè)選擇：

  • 遠(yuǎn)程對(duì)象定位：使用URL;或者使用名字服務(wù)來(lái)查找

  • 遠(yuǎn)程調(diào)用參數(shù)傳遞：使用C的基本類型定義;或者使用某種預(yù)訂的序列化(反序列化)方案

  • 接口定義：使用某種特定格式的技術(shù)，直接按預(yù)先約定一種接口定義文件;或者使用某種描述協(xié)議IDL來(lái)生成這些接口文件

  • 通信承載：有使用特定TCP/UDP之類的服務(wù)器，也有可以讓用戶自己開發(fā)定制的通信模型;還有使用HTTP或者消息隊(duì)列這一類更加高級(jí)的傳輸協(xié)議

方案選型

在我們確定了遠(yuǎn)程調(diào)用系統(tǒng)方案幾個(gè)可行選擇后，自然就要明確一下各個(gè)方案的優(yōu)缺點(diǎn)，這樣才能選擇真正合適需求的設(shè)計(jì)：

  1. 對(duì)于遠(yuǎn)程對(duì)象的描述：使用URL是互聯(lián)網(wǎng)通行的標(biāo)準(zhǔn)，比較方便用戶理解，也容易添加日后需要擴(kuò)展到內(nèi)容，因?yàn)閁RL本身是一個(gè)由多個(gè)部分組合的字符串;而名字服務(wù)則老式一些，但是依然有他的好處，就是名字服務(wù)可以附帶負(fù)載均衡、容災(zāi)擴(kuò)容、自定義路由等一系列特性，對(duì)于需求復(fù)雜的定位比較容易實(shí)現(xiàn)。

  2. 遠(yuǎn)程調(diào)用的接口描述：如果只限制于某個(gè)語(yǔ)言、操作系統(tǒng)、平臺(tái)上，直接利用“隱喻”方式的接口描述，或者以“注解”類型注釋手段來(lái)標(biāo)注源代碼，實(shí)現(xiàn)遠(yuǎn)程調(diào)用接口的定義，是最方便不過(guò)的。但是，如果需要兼容編譯型語(yǔ)言，如C/C++，就一定要用某種IDL來(lái)生成這些編譯語(yǔ)言的源代碼了。

  3. 通信承載：給用戶自己定制通信模塊，能提供最好的適用性，但是也讓用戶增加了使用的復(fù)雜程度。而HTTP/消息隊(duì)列這種承載方式，在系統(tǒng)的部署、運(yùn)維、編程上都會(huì)比較簡(jiǎn)單，缺點(diǎn)就是對(duì)于性能、傳輸特性的定制空間就比較小。

分析完核心問題，我們還需要考慮一些適用性場(chǎng)景：

  1. 面向?qū)ο筮€是面向過(guò)程：如果我們只是考慮做面向過(guò)程的遠(yuǎn)程調(diào)用，只需要定位到“函數(shù)”即可。而如果是面向?qū)ο蟮?，則需要定位到“對(duì)象”。由于函數(shù)是無(wú)狀態(tài)的，所以其定位過(guò)程可以簡(jiǎn)單到一個(gè)名字即可，而對(duì)象則需要?jiǎng)討B(tài)的查找到其ID或句柄。

  2. 跨語(yǔ)言還是單一語(yǔ)言：?jiǎn)我徽Z(yǔ)言的方案中，頭文件或接口定義完全用一種語(yǔ)言處理即可，如果是跨語(yǔ)言的，就少不免要IDL

  3. 混合式通信承載還是使用HTTP服務(wù)器承載：混合式承載可能可以用到TCP/UDP/共享內(nèi)存等底層技術(shù)，可以提供最優(yōu)的性能，但是使用起來(lái)必然非常麻煩。使用HTTP服務(wù)器的話，則非常簡(jiǎn)單，因?yàn)閃WW服務(wù)的開源軟件、庫(kù)眾多，而且客戶端使用瀏覽器或者一些JS頁(yè)面即可調(diào)試，缺點(diǎn)是其性能較低。

假設(shè)我們現(xiàn)在要為某種業(yè)務(wù)邏輯非常多變的領(lǐng)域，如企業(yè)業(yè)務(wù)應(yīng)用領(lǐng)域，或游戲服務(wù)器端領(lǐng)域，去設(shè)計(jì)一個(gè)遠(yuǎn)程調(diào)用系統(tǒng)，我們可能應(yīng)該如下選擇：

  1. 使用名字服務(wù)定位遠(yuǎn)程對(duì)象：由于企業(yè)服務(wù)是需要高可用性的，使用名字服務(wù)能在查詢名字時(shí)識(shí)別和選擇可用性服務(wù)對(duì)象。J2EE方案中的EJB(企業(yè)JavaBean)就是用名字服務(wù)的。

  2. 使用IDL來(lái)生成接口定義：由于企業(yè)服務(wù)或游戲服務(wù)，其開發(fā)語(yǔ)言可能不是統(tǒng)一的，又或者需要高性能的編程語(yǔ)言如C/C++，所以只能使用IDL。

  3. 使用混合式通信承載：雖然企業(yè)服務(wù)看起來(lái)無(wú)需在很復(fù)雜的網(wǎng)絡(luò)下運(yùn)行，但是不同的企業(yè)的網(wǎng)絡(luò)環(huán)境又可能是千差萬(wàn)別的，所以要做一個(gè)通用的系統(tǒng)，最好還是不怕麻煩提供混合式的通信承載，這樣可以在TCP/UDP等各種協(xié)議中選擇。

感謝各位的閱讀，以上就是“怎么設(shè)計(jì)一個(gè)RPC系統(tǒng)”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)怎么設(shè)計(jì)一個(gè)RPC系統(tǒng)這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！

網(wǎng)站題目：怎么設(shè)計(jì)一個(gè)RPC系統(tǒng)
URL鏈接：http://bm7419.com/article32/iipgpc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站改版、面包屑導(dǎo)航、網(wǎng)站設(shè)計(jì)、建站公司、外貿(mào)建站、電子商務(wù)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)

h5響應(yīng)式網(wǎng)站建設(shè)