一個簡單RPC架構是怎樣煉成的(V)——引入傳輸層

開局篇我們說了，RPC架構的四個核心内容

RPC資料的傳輸。

RPC消息 協定

RPC服務注冊

RPC消息處理   

接下來處理傳輸資料。實際應用場景一般都是基于socket。socket代碼比較多，使用起來也比較麻煩。

并且詳細的傳輸通道使用socket或者其它的方式，如更上層的http，或者android裡的binder，都是可替換的。僅僅是詳細的一種實作而已。是以，這裡我就偷個懶，僅僅是引入一個非常easy的Connection類。用來描寫叙述一下怎樣将傳輸資料 這一層給獨立出來。

首先簡單列出Connection類的實作，非常easy，就是兩個list。一個管發送。一個管接收。

（實作沒有考慮多線程安全。實際是必須考慮的）。

須要說明的是，這裡的recv的實作約定是堵塞式的，也就是假設沒有收到不論什麼資料。recv調用會一直堵塞。

一般說來。都是socket連接配接。這裡簡化起見，直接本地變量實作。

'''

def __init__(self, sending_msg_list, recving_msg_list):

Constructor

self.sending_msg_list = sending_msg_list

self.recving_msg_list = recving_msg_list

def send(self, message):

self.sending_msg_list.append(message)

def recv(self):

while len(self.recving_msg_list) == 0: time.sleep(0.01)

return self.recving_msg_list.pop(0)

def isClosed(self):

return False

有了這個connection，剩下的就僅僅要将rpc消息統統通過這個connection去發送。通過這個Connection去接收。

接着改動client的request請求，不再直接調用server端的procRequest方法，而是将請求交給connection，去發送。

 然後等待connection收到server端的回複，将回複消息從connection中取出來。

相同的，改動服務端收到request請求後的處理。首先重複調用connection.recv()方法讀取用戶端發過來的請求。當請求處理完畢後，不再直接以函數傳回的方式return。而是将rsp交給connection。由connection負責傳輸給client

最後。列一下connection的初始化

總結，引入傳輸層的意義在于

1. 實作client與server端的解耦，client端不再須要持有server端的對象了。 這也是實作“遠端調用 ”所必須的。

2. 傳輸層的實作有非常大的自由度，一般說來，他無需關心詳細的RPC消息的格式。僅僅須要完畢資料的可靠傳輸就能夠了。

3. 傳輸層詳細基于socket。binder， 是採用http，udp。tcp這些都是自由的。依據須要選擇就能夠了。也就是相當于一個能夠自由拼接的元件。

4. 上面的模型實在過于簡單，沒有考慮多線程保護，沒有考慮異常。

實際比較理想的情況。應該起碼有個類，Connector，以及Channel。當中channel僅僅負責資料的傳輸，Connector負責管理channel。

興許假設有時間，會再進行完好

本文轉自mfrbuaa部落格園部落格，原文連結：http://www.cnblogs.com/mfrbuaa/p/5386763.html，如需轉載請自行聯系原作者