RPC 框架設計
RPC 框架設計
初識 RPC
服務化有什麼好處?
- 防止程式碼拷貝
- 防止底層複雜性的擴散
- 防止公共庫的耦合
- 保證 SQL 的品質,能夠解除資料庫的耦合
什麼是 RPC
RPC:Remote Procedure Call Protocol,遠程過程調用協議,像調用本地函數一樣,去調用一個遠端服務。
相比「同一個進程」的「本地」函數調用,有沒有辦法,調用一個「跨進程」的「遠程」函數呢?
Socket 通訊,只能傳遞連續的位元組流,如何將 「入參/函數」 放到連續的位元組流里呢?需要設計「應用層報文(協議)」
「跨進程」「遠程」調用的過程
RPC 框架的架構職責
上述跨進程調用遠端的服務,存在的問題是沒有將通用操作抽離出來。
RPC框架職責:
- 讓調用端,像調用本地函數一樣,便捷的調用遠程的服務
- 讓服務端,像提供本地函數一樣,便捷的提供遠程的服務
向調用方屏蔽各種複雜性,向服務方也屏蔽各種複雜性,讓調用方感覺上就是在調用本地函數一樣,來調用一個遠端的服務;讓服務方就像實現一個本地函數一樣,便捷地提供遠端服務。
序列化與反序列化
為什麼需要序列化?
需要將對象等數據進行二進位轉儲。
所謂序列化,是將「對象」形態的數據轉化為「連續空間二進位位元組流」形態數據的過程。
如何進行序列化?
如何將一個 class User
的記憶體實體 u1 轉化為二進位位元組流?
-
方案一:自描述
自描述的標記性語言
(XML/JSON)
,來進行轉換。規定好轉換規則。 -
方案二:序列化協議
序號 | key 長度 | key 值 | value 長度 | value 值
序列化協議設計,要考慮什麼因素?
- 解析效率
- 壓縮率,傳輸有效性
- 擴展性,兼容性
- 可讀性,可調試性
- 跨語言
- 通用性
常見的序列化方法(協議)
- xml/json
- protobuf
- Avro
- CORBA
- mc_pack
位元組流發送 + 位元組流接收
同步 RPC 系統架構,核心流程
RPC-server:IO
執行緒,中間是一個隊列,工作執行緒處理結果,返回。
連接池組件
非同步 RPC 系統架構,核心流程
調用方調用,生成上下文,編程報文,放入隊列;調用結束
非同步架構,上下文管理器
- 為什麼需要上下文管理器?
- 如何將請求-響應-回調等資訊匹配起來?
一條連接,非同步請求、響應報文如何匹配? 可以通過「請求ID」關聯!!!
通過「請求ID」關聯 請求-響應-回調
非同步架構,超時管理器
RPC-Server
監聽一個埠,收發執行緒收發資料庫包,中間一個包隊列,工作執行緒來處理,整個 RPC-Server 就是一個比較簡單的生產者-消費者。
總結
-
什麼是 RPC?
像調用本地函數一樣,去調用一個遠端服務
-
為什麼需要 RPC 框架?
用來屏蔽 rpc 調用過程中,跟業務程式碼無關的底層技術細節
-
什麼是序列化?為什麼需要序列化?
將對象轉換為二進位流的過程
-
同步 RPC-Client 的核心組件是什麼?
序列化/反序列化、連接池
-
非同步 RPC-Client 的核心組件是什麼?
收發隊列(用於解耦)、工作執行緒、上下文管理器