當前位置:
首頁 > 最新 > XmlRPC簡介及使用

XmlRPC簡介及使用

緣起

最近在項目使用過程中需要使用到較簡便的客戶端/伺服器網路通信模型,對數據進行實時拉取。要求並不多(貌似也不少),主要有以下幾點即可:

簡單:使用操作應該簡便快捷

穩定:毋庸置疑,雖然目前不考慮並發使用(採集客戶端相對較少)

通用:支持多語言多平台

支持老設備(目前我們需要通信的些許設備都是xp及其以前的Win2k)

通過前期資料收集,要麼自己定義協議(簡單來說就是實現一個簡易版本的HTTP協議,發送請求返回相應),要麼就是主流的RPC(Remote Procedure call)協議,即遠過程調用。

不搜不知道,一搜索才發現RPC裡面又是一個大世界,下面就先介紹下RPC的運行原理


百度百科的定義如下:

RPC(Remote Procedure Call)—遠程過程調用,它是一種通過網路從遠程計算機程序上請求服務,而不需要了解底層網路技術的協議。RPC協議假定某些傳輸協議的存在,如TCP或UDP,為通信程序之間攜帶信息數據。在OSI網路通信模型中,RPC跨越了傳輸層和應用層。RPC使得開發包括網路分散式多程序在內的應用程序更加容易。

RPC採用客戶機/伺服器模式。請求程序就是一個客戶機,而服務提供程序就是一個伺服器。首先,客戶機調用進程發送一個有進程參數的調用信息到服務進程,然後等待應答信息。在伺服器端,進程保持睡眠狀態直到調用信息到達為止。當一個調用信息到達,伺服器獲得進程參數,計算結果,發送答覆,然後等待下一個調用信息,最後,客戶端調用進程接收答覆信息,獲得進程結果,然後調用執行繼續進行。


通過像本地服務一樣遠程調用另外一台伺服器上的服務來完成需求。既然說到是遠程過程調用那麼先至少得明白什麼是本地函數調用這樣才能更好理解下面的工作原理


下面我們以最簡單的一個求和方法調用進行說明

本地進程函數調用

執行這段代碼的時候,傳入參數[2,4]調用了本地代碼段中的方法Sum,並將計算的結果返回。整個流程就是:輸入參數,返回結果

跨進程函數調用

上例是在同一進程中進行調用,那麼跨進程調用呢?跨進程就分兩種了,本機進程間通信和跨機器進程間通信(該種方式就更符合我們需求了)

對於這種,我們就很容易想到,通過協定一個協議,然後用網路Socket通信,來傳輸參數,再在遠端機器調用指定方法Sum,最後再把返回值原路返回

比如這個地方我們定一個協議,指定方法名稱和參數如下圖,服務端調用後再將結果返回

至此,應該對RPC應該也明白了大概,下文從網上盜圖一張,進行更加詳盡的講解


一圖勝千言:

有了圖,那麼我們就看圖說話,理理Client和Server之間整個數據通訊路徑,對於C/S模型,客戶端發送請求,服務端返回結果。就像我們訪問百度一樣,先輸入一個搜索關鍵字,百度把它知道的相關數據返回給你,就完成了一次數據通訊。那麼RPC的通訊路徑如何呢?為了方便說明,我先理定一個場景:

服務端實現了一個當前時間的方法:CurrentTimeStamp()獲取當前時間,我們暫定該時間是一個標準的時間戳。

客戶端通過定期更新該時間作為本地系統時間

此時客戶端要更新本機系統時間的流程,那麼需要走哪些路徑才能成功獲取到數據,請看下文(此處可結合下文demo演示進行對照):

首先Computer 01作為Client,要更新系統時間,先要發起一次RPC調用,告訴服務端:「我要調用方法CurrentTimeStamp,請把時間給我吧!」。通過以調用本地服務的方式調用遠程API。比如:proxy.CurrentTimeStamp()

此時Client就會調用Client Stub(客戶端句柄),通過傳入參數並進行數據封裝(編碼)成可以進行網路傳送的結構體。包括:調用方法,方法參數(如果有的話)

Client Stub調用本地系統的網路服務,發送封裝好的結構體信息到服務端

通過網路傳送消息到達服務端主機

Server Stub(服務端句柄)收到發送過來的信息後,對信息進行解碼,取出傳送過來的參數

在Computer 02作為Server執行函數調用,獲取結果信息

將結果信息發送給Server Stub

Server Stub將消息封裝,通過本地系統網路服務,發送網路信息到客戶端

消息傳送回Client主機所在網路系統

Client Stub對收到信息進行處理解碼

將返回信息返回給Client應用程序

至此就完成了一個消息調用過程,對客戶端來說,就像調用本地方法CurrentTimeStamp一樣獲取到了伺服器時間戳。對於用戶來說根本不需要要關係這個時間是怎麼來的,通過何種形式來的。反正我獲得了我需要的結果。


那麼為什麼要用RPC?因為如上文這麼一講解,發現調用方太複雜了,需要關注許多底層細節,比如:

首先方法名、參數等得序列化吧,服務端還要反序列化

再通過網路協議進行傳輸,獲取最終結果。

不用擔心,RPC框架解決了這些中間繁瑣的調用,我們只需要關係業務邏輯,針對業務寫介面即可

RPC框架包含兩個重要部分:

傳輸協議; 比如gRPC基於http2協議,Xml-Rpc、Json-Rpc都是通過HTTP傳輸,而其他多數基於TCP設計的自定義協議

編碼協議;說白了就是對數據的序列號和反序列化。對於編碼協議有基於文本編碼的xml、json,也有基於二進位編碼的protobuf。從性能來說當然二進位編碼比基於xml和json相對好些,能減少帶寬,更加安全,但是撇開這些,其他方式也還是可用

目前市面上這麼多RPC框架,主要還是在不斷實踐中自己提煉和總結實現了一套更符合自己業務員場景或者更加通用的框架供大家使用。就像目前我們使用的語言,官方語言是普通話,我們還有各個地方的方言。目的就是一個溝通。

RPC主要是用在大型企業裡面,因為大型企業裡面系統繁多,業務線複雜,而且效率優勢也是非常重要的一塊,同時目前伺服器分散式部署、多機器、多機房等,這個時候RPC的優勢就比較明顯了 。在項目實現上,只需要定義好介面,服務端實現該介面,客戶端直接調用即可。


每每對於下定義,我還是覺得百科能說得更加清楚,維基百科定義如下:

Xml-RPC是一個遠程過程調用(remote procedure call,RPC)的分散式計算協議,通過XML將調用函數封裝,並使用HTTP協議作為傳送機制。

而在XmlRPC中數據使用XML格式的。那麼為什麼用XML而不用二進位呢?我想一方面應該是為了兼容更多的語言,因為這個世界上除了C/C++、Java、C#等編譯語言, 還有很多腳本語言(Python、JavaScript等)。XmlRPC協議規定發送請求時,通過統一規則發送命令和參數,更好兼容多平台、多語言。任何事情都有兩面性,兼容性好那麼性能相對就會慢下來

對於XmlRPC的命令、參數的協定請參考維基百科中XML-RPC


XmlRPC客戶端工作原理

Client根據指定URL找到服務端地址

然後編碼請求數據

調用服務端上的指定服務的方法

接收到服務端的返回,解析響應包,拿出調用的返回結果

XmlRPC服務端工作原理

啟動一個服務程序, 註冊每個能提供的服務,每個服務對應一個Handler類

進入服務監聽狀態

等待Client的請求

優點:

簡單、輕量

XML編碼,可讀性強

支持多語言多平台

缺點:

對字元的編碼較弱,中文編碼可能得需要通過base64了

浪費帶寬,比如就傳遞兩個參數,需要發送一大堆無用的xml節點

複雜數據結構支持不夠好

孰優孰劣,具體看應用場景,對於目前我的需求來說,簡單使用足矣


下面我們就通過C++、C#和Python來實現一個簡單的RPC調用

人生苦短,我用Python!那麼我們就先用Python來實現一個時間戳伺服器,短短几行代碼就可完成



C++我這使用了一個三方庫XmlRpc++ ,該庫使用簡單就不做過多解釋,拿來即用


使用C#時,本文引入第三方庫CookComputing.XmlRpcV2,相應庫較多,可自行測試

喜歡這篇文章嗎?立刻分享出去讓更多人知道吧!

本站內容充實豐富,博大精深,小編精選每日熱門資訊,隨時更新,點擊「搶先收到最新資訊」瀏覽吧!


請您繼續閱讀更多來自 奔跑阿甘 的精彩文章:

Windows窗體數據抓取詳解

TAG:奔跑阿甘 |