RPC 框架設計

RPC 框架設計

初識 RPC

服務化有什麼好處?

• 防止代碼拷貝
• 防止底層複雜性的擴散
• 防止公共庫的耦合
• 保證 SQL 的質量，可以解除數據庫的耦合

什麼是 RPC

RPC：Remote Procedure Call Protocol，遠程過程調用協議，像調用本地函數同樣，去調用一個遠端服務。

相比「同一個進程」的「本地」函數調用，有沒有辦法，調用一個「跨進程」的「遠程」函數呢?

Socket 通信，只能傳遞連續的字節流，如何將 「入參/函數」 放到連續的字節流裏呢?須要設計「應用層報文（協議）」

「跨進程」「遠程」調用的過程

RPC 框架的架構職責

上述跨進程調用遠端的服務，存在的問題是沒有將通用操做抽離出來。

RPC框架職責：

1. 讓調用端，像調用本地函數同樣，便捷的調用遠程的服務
2. 讓服務端，像提供本地函數同樣，便捷的提供遠程的服務

向調用方屏蔽各類複雜性，向服務方也屏蔽各類複雜性，讓調用方感受上就是在調用本地函數同樣，來調用一個遠端的服務；讓服務方就像實現一個本地函數同樣，便捷地提供遠端服務。

序列化與反序列化

爲何須要序列化?

須要將對象等數據進行二進制轉儲。

所謂序列化，是將「對象」形態的數據轉化爲「連續空間二進制字節流」形態數據的過程。

如何進行序列化?

如何將一個 class User 的內存實體 u1 轉化爲二進制字節流?

• 方案一：自描述

  自描述的標記性語言 (XML/JSON)，來進行轉換。規定好轉換規則。

• 方案二：序列化協議

  序號 | key 長度 | key 值 | value 長度 | value 值

序列化協議設計，要考慮什麼因素?

1. 解析效率
2. 壓縮率，傳輸有效性
3. 擴展性，兼容性
4. 可讀性，可調試性
5. 跨語言
6. 通用性

常見的序列化方法(協議)

1. xml/json
2. protobuf
3. Avro
4. CORBA
5. mc_pack

字節流發送 + 字節流接收

同步 RPC 系統架構，核心流程

RPC-server:IO線程，中間是一個隊列，工做線程處理結果，返回。

鏈接池組件

異步 RPC 系統架構，核心流程

調用方調用，生成上下文，編程報文，放入隊列；調用結束

異步架構，上下文管理器

1. 爲何須要上下文管理器?
2. 如何將請求-響應-回調等信息匹配起來?

一條鏈接，異步請求、響應報文如何匹配? 能夠經過「請求ID」關聯!!!

經過「請求ID」關聯 請求-響應-回調

異步架構，超時管理器

RPC-Server

監聽一個端口，收發線程收發數據庫包，中間一個包隊列，工做線程來處理，整個 RPC-Server 就是一個比較簡單的生產者-消費者。

總結

1. 什麼是 RPC？

   像調用本地函數同樣，去調用一個遠端服務

2. 爲何須要 RPC 框架?

   用來屏蔽 rpc 調用過程當中，跟業務代碼無關的底層技術細節

3. 什麼是序列化?爲何須要序列化?

   將對象轉換爲二進制流的過程

4. 同步 RPC-Client 的核心組件是什麼?

   序列化/反序列化、鏈接池

5. 異步 RPC-Client 的核心組件是什麼?

   收發隊列(用於解耦)、工做線程、上下文管理器