1 引言

遠(yuǎn)程過(guò)程調(diào)用（Remote Procedure Call，RPC）是一種通過(guò)網(wǎng)絡(luò)從遠(yuǎn)程計(jì)算機(jī)程序上請(qǐng)求服務(wù)。通過(guò)RPC，使用者無(wú)需了解底層網(wǎng)絡(luò)技術(shù)，快速開(kāi)發(fā)部署業(yè)務(wù)功能邏輯[1]。因此，在RPC在分布式系統(tǒng)中的系統(tǒng)環(huán)境建設(shè)和應(yīng)用程序設(shè)計(jì)中有著廣泛的應(yīng)用[2]，如：分布式操作系統(tǒng)的進(jìn)程間通訊、構(gòu)造分布式計(jì)算的軟件環(huán)境、遠(yuǎn)程數(shù)據(jù)庫(kù)服務(wù)、分布式應(yīng)用程序設(shè)計(jì)、分布式程序的調(diào)試等。

RPC主流實(shí)現(xiàn)的方式[3]有：基于TCP協(xié)議、基于HTTP協(xié)議?；赥CP協(xié)議實(shí)現(xiàn)RPC，由于處于協(xié)議棧底層，可更靈活地對(duì)協(xié)議字段進(jìn)行定制，減少網(wǎng)絡(luò)傳輸字節(jié)數(shù)，提高性能，但受所定義協(xié)議的局限，需要關(guān)注底層實(shí)現(xiàn)細(xì)節(jié)，難以實(shí)現(xiàn)跨平臺(tái)調(diào)用，不同的終端需要開(kāi)發(fā)不同的工具包來(lái)進(jìn)行請(qǐng)求發(fā)送和響應(yīng)解析，代碼量高，工作量大[4]；基于HTTP協(xié)議實(shí)現(xiàn)RPC，作為通用的格式標(biāo)準(zhǔn)，使用JSON和XML格式開(kāi)發(fā)相對(duì)成熟，但與TCP傳輸性能的存在較大差距[5]。

綜上所述，基于上述協(xié)議的主流RPC框架，雖然有適用面廣、功能強(qiáng)大的優(yōu)點(diǎn)，但是也存在著代碼量多、流程復(fù)雜、對(duì)系統(tǒng)開(kāi)銷(xiāo)較大的缺點(diǎn)，用于小型應(yīng)用程序上過(guò)于龐大，因此，本文提出一種基于UDP通信的遠(yuǎn)程過(guò)程調(diào)用方法，采用對(duì)系統(tǒng)開(kāi)銷(xiāo)較小的UDP協(xié)議，利用負(fù)載均衡策略，基于服務(wù)進(jìn)程向注冊(cè)進(jìn)程注冊(cè)服務(wù)的方式，應(yīng)用進(jìn)程從注冊(cè)進(jìn)程獲取服務(wù)進(jìn)程的相關(guān)信息，實(shí)現(xiàn)應(yīng)用與服務(wù)進(jìn)程的直接RPC通信，具備構(gòu)架輕便、系統(tǒng)開(kāi)銷(xiāo)小的特點(diǎn)，滿足小型應(yīng)用程序的輕量化要求，具有重要的意義。

2 基于UDP通信的遠(yuǎn)程調(diào)用方法

RPC系統(tǒng)采用C/S模式，請(qǐng)求程序作為客戶(hù)機(jī)，服務(wù)提供程序作為服務(wù)器，由請(qǐng)求程序向服務(wù)程序發(fā)送調(diào)用信息，能夠獲得答復(fù)信息并獲得進(jìn)程結(jié)果，交互流程如圖1所示。

圖1 RPC交互流程

基于UDP通信的遠(yuǎn)程調(diào)用方法，包含以下重要部分：①服務(wù)端服務(wù)進(jìn)程注冊(cè)模塊、②客戶(hù)端查詢(xún)注冊(cè)進(jìn)程模塊、③應(yīng)用進(jìn)程負(fù)載均衡策略、④客戶(hù)端發(fā)送RPC服務(wù)請(qǐng)求模塊、⑤服務(wù)端執(zhí)行對(duì)應(yīng)的業(yè)務(wù)流程模塊、⑥服務(wù)端發(fā)送響應(yīng)信息模塊、⑦客戶(hù)端接收響應(yīng)信息模塊，各部分對(duì)應(yīng)的步驟如圖2所示。

圖2 基于UDP通信的遠(yuǎn)程調(diào)用方法

系統(tǒng)處理流程如下：①首先，客戶(hù)進(jìn)程中，應(yīng)用層調(diào)用RPC接口的API發(fā)起請(qǐng)求，調(diào)用系統(tǒng)網(wǎng)絡(luò)接口發(fā)送請(qǐng)求，通過(guò)網(wǎng)絡(luò)數(shù)據(jù)包從客戶(hù)端發(fā)到服務(wù)端；②然后，服務(wù)進(jìn)程中，RPC請(qǐng)求從服務(wù)端的系統(tǒng)層傳遞到用戶(hù)層的RPC接口，通過(guò)RPC請(qǐng)求解析后，找到對(duì)應(yīng)的服務(wù)層，并將執(zhí)行結(jié)果發(fā)回給RPC接口，調(diào)用系統(tǒng)網(wǎng)絡(luò)接口回復(fù)執(zhí)行結(jié)果；③最后，客戶(hù)進(jìn)程中，執(zhí)行結(jié)果通過(guò)網(wǎng)絡(luò)數(shù)據(jù)包從服務(wù)端發(fā)到客戶(hù)端，從客戶(hù)端的系統(tǒng)層傳遞到用戶(hù)層的RPC接口，將執(zhí)行結(jié)果轉(zhuǎn)給對(duì)應(yīng)的應(yīng)用層，完成請(qǐng)求任務(wù)。

各部分詳細(xì)介紹如下。

2.1 服務(wù)端服務(wù)進(jìn)程注冊(cè)模塊

服務(wù)進(jìn)程是提供RPC服務(wù)的應(yīng)用程序，需要注冊(cè)在服務(wù)器上，其對(duì)應(yīng)信息包含：RPC服務(wù)信息（服務(wù)名、服務(wù)說(shuō)明等）以及相應(yīng)的UDP端口號(hào)。服務(wù)信息的結(jié)構(gòu)定義如下：

2.2 客戶(hù)端查詢(xún)注冊(cè)進(jìn)程模塊

客戶(hù)端的應(yīng)用進(jìn)程是需要使用RPC服務(wù)的應(yīng)用程序，當(dāng)應(yīng)用進(jìn)程需要調(diào)用RPC服務(wù)時(shí)，可根據(jù)服務(wù)名向注冊(cè)進(jìn)程發(fā)送查詢(xún)請(qǐng)求；注冊(cè)進(jìn)程可以依據(jù)查詢(xún)請(qǐng)求中攜帶的服務(wù)名，查找當(dāng)前可以提供相應(yīng)RPC服務(wù)的服務(wù)進(jìn)程，并向應(yīng)用進(jìn)程發(fā)送反饋信息，反饋信息中可包含有提供RPC服務(wù)的各個(gè)服務(wù)進(jìn)程的鏈接信息，包括：服務(wù)進(jìn)程的IP地址、UDP端口號(hào)等。反饋信息的結(jié)構(gòu)定義如下：

2.3 負(fù)載均衡策略

每個(gè)服務(wù)進(jìn)程可以提供多個(gè)不同的RPC服務(wù)，因此，針對(duì)同一項(xiàng)RPC服務(wù)而言，可以提供該項(xiàng)RPC服務(wù)的服務(wù)進(jìn)程可能有多個(gè)，即應(yīng)用進(jìn)程接收的反饋信息中可能包含有多個(gè)服務(wù)進(jìn)程的相關(guān)信息。

系統(tǒng)應(yīng)用進(jìn)程設(shè)計(jì)按照可以依據(jù)負(fù)載均衡策略，選取出一個(gè)合適的服務(wù)進(jìn)程作為目標(biāo)服務(wù)進(jìn)程，利用該目標(biāo)服務(wù)進(jìn)程提供相應(yīng)的RPC服務(wù)。

2.4 客戶(hù)端發(fā)送RPC服務(wù)請(qǐng)求模塊

應(yīng)用進(jìn)程依據(jù)該鏈接信息，可向目標(biāo)服務(wù)進(jìn)程發(fā)送RPC服務(wù)請(qǐng)求。設(shè)計(jì)基于UDP通信的遠(yuǎn)程調(diào)用，將RPC服務(wù)請(qǐng)求以UDP數(shù)據(jù)包的形式發(fā)送到目標(biāo)服務(wù)進(jìn)程所在IP地址的UDP端口上，RPC服務(wù)請(qǐng)求中可以包含請(qǐng)求號(hào)、服務(wù)名、請(qǐng)求參數(shù)等信息。RPC服務(wù)請(qǐng)求的結(jié)構(gòu)定義如下：

為了可以一次發(fā)送多個(gè)RPC服務(wù)請(qǐng)求，在RPC服務(wù)請(qǐng)求中增加了參數(shù)reqId，該參數(shù)在每個(gè)請(qǐng)求中都是不同了，唯一標(biāo)識(shí)一個(gè)RPC服務(wù)請(qǐng)求消息。參數(shù)serviceName是請(qǐng)求的服務(wù)名。參數(shù)textArg和binArg是請(qǐng)求參數(shù)，格式是服務(wù)自定義的。為了方便使用，textArg使用擴(kuò)展性好的JSON格式，保存可以用字符串表達(dá)的參數(shù)，binArg保存不能用字符串表達(dá)的參數(shù)，這樣兩種類(lèi)型的參數(shù)已經(jīng)可以覆蓋業(yè)務(wù)需求，并且良好的擴(kuò)展性，便于后期維護(hù)。

2.5 服務(wù)端執(zhí)行對(duì)應(yīng)的業(yè)務(wù)流程

目標(biāo)服務(wù)進(jìn)程提供的RPC服務(wù)可能有多個(gè)，依據(jù)RPC服務(wù)請(qǐng)求中攜帶的服務(wù)名，可以獲知需要執(zhí)行哪一項(xiàng)RPC服務(wù)，從而調(diào)用相應(yīng)的業(yè)務(wù)流程。請(qǐng)求參數(shù)可以看做是該業(yè)務(wù)流程的輸入?yún)?shù)，經(jīng)過(guò)業(yè)務(wù)流程的處理，可以得到相應(yīng)的執(zhí)行結(jié)果。

2.6 服務(wù)端發(fā)送響應(yīng)信息

業(yè)務(wù)進(jìn)程可以一次發(fā)送多個(gè)RPC服務(wù)請(qǐng)求，為了便于區(qū)分每個(gè)RPC服務(wù)請(qǐng)求的執(zhí)行結(jié)果，在響應(yīng)信息中可以攜帶請(qǐng)求號(hào)和服務(wù)名，其中，該請(qǐng)求號(hào)和RPC服務(wù)請(qǐng)求中的請(qǐng)求號(hào)相同，該服務(wù)名是和RPC服務(wù)請(qǐng)求中的服務(wù)名相同。響應(yīng)信息的結(jié)構(gòu)定義如下，

響應(yīng)消息中的參數(shù)reqId、serviceName和RPC服務(wù)請(qǐng)求中的參數(shù)是一致的，textResult保存可以用字符串表達(dá)的結(jié)果，binResult保存不能用字符串表達(dá)的結(jié)果。

2.7 客戶(hù)端接收響應(yīng)信息

如果響應(yīng)信息的數(shù)據(jù)量很大，可以分為多個(gè)UDP包發(fā)送，在消息的包頭中可以用消息的分片序號(hào)來(lái)標(biāo)識(shí)每個(gè)數(shù)據(jù)包，在客戶(hù)端的RPC接口層中進(jìn)行重組后提交給上層。

3 結(jié)論

本文所提的基于UDP通信的遠(yuǎn)程過(guò)程調(diào)用方法，采用了對(duì)系統(tǒng)開(kāi)銷(xiāo)較小的UDP協(xié)議，設(shè)計(jì)了簡(jiǎn)單快捷的處理流程，快速的配置下發(fā)和狀態(tài)查詢(xún)功能既能滿足輕量級(jí)應(yīng)用程序的需求，又能減輕系統(tǒng)負(fù)擔(dān)，在2/3/4/5G通信網(wǎng)業(yè)務(wù)功能設(shè)計(jì)、DPI設(shè)備系統(tǒng)、協(xié)議解析設(shè)備系統(tǒng)中有廣泛的應(yīng)用，特別適用于功能簡(jiǎn)單、網(wǎng)絡(luò)情況良好的應(yīng)用場(chǎng)景。