一個簡單RPC架構是如何煉成的(I)——開局篇

開場白，這是一個關於RPC的相關概念的普及篇系列，主要是通過一步步的調整，提煉出一個相對完整的RPC架構。

RPC（Remote Procedure Call Protocol）——遠端程序呼叫協議，基於C/S模型。網路上有一篇文章寫得不錯，可以去瞭解一下相關概念深入淺出RPC

這裡，直接使用一下上面作者的一個示意圖

總結下來就是有4塊核心內容

RPC資料的傳輸。如上面的RPCConnector，RPCChannel。它們主要負責資料轉送這一塊， 具體用戶端與伺服器之間的串連是不是socket串連，是原始tcp串連還是使用http，這些RPC協議本身不做任何規定。那麼我們的任務就是抽象出這樣一個傳輸層。 RPC訊息。如上面的RPCProtocol， 以及encode，decode方法。 因為RPC是遠程調用，所以沒辦法直接函數調用，於是就必須用一套專門的協議，去表示調用以及調用結果。另外，因為實際應用基本都是跨機器串連，所以無法直接傳遞記憶體變數，也就是說還需要將訊息編碼成 諸如字串一類的可以跨裝置傳輸的內容。具體的RPC訊息的封裝協議很多，常見的是基於xml，json封裝的。那麼我們的任務就是抽象出這樣一個協議層。 RPC服務註冊。如上面Callee -->export。 服務端具體支援哪些調用，收到來自用戶端的RPC請求後，怎樣去調用真正的需要執行的方法，這些內容也是一個完整的RPC架構必須考慮的。一些稍微進階一點的架構，都是可以服務自動註冊的，現在主流的RPC架構，還支援通過 IDL（Interface Definition Language）來定義遠程介面，實現跨語言的RPC 。那麼我們的任務就是抽象出一個RPC服務的註冊機制。 RPC訊息處理。如上面的RPCInvoker。這裡其實與RPC本身關係不大，一般就是考慮支援非同步/同步調用。 這一部分，大概我也會做一些說明，但不是這個系列的重點。 這次RPC架構的搭建，庄稼人將採用python作為開發語言，原因嘛，還有點不好意思：代碼量少，方便解釋（偷懶是碼工的天性）。初步的想法是，整個架構是從原始的普通調用開始，然後一步步的演化，最後產生一個完整的RPC架構。希望在這個過程中，能帶給各位同學更深刻的RPC入門知識，以及代碼修改的知識。說得有點高了，呵呵。