同前幾篇博文，本次針對大神分享的PRC框架核心技術進行總結分享。歡迎討論
一、RPC框架整體架構
RPC Client && RPC Server
RPC Client
1、動態代理，根據lookUp信息（接口-實現-方法）動態創建出代理類，（創建代理類==RPC服務端的目標接口）。即Lookup爲遠端目標接口地址，創建調用目標接口代理。
2、上下文管理，主要爲標識每個請求的sessionID,保證server端返回的結果找到對應的上下文。例如同時ABC三個請求從客戶端發送到server去請求，上下文就用來標識server返回的ABC response對應客戶端發來的ABC request。
處理好client的請求數據後，經過序列化、經由兩端統一的協議，傳輸到server端，進行反序列化操作解析出目標接口、參數等信息，執行invoke調用後，將結果再次序列化傳輸。
RPC Server
1、分發器，將請求分發到sever實例（負載策略&容錯）
2、過濾器，統一攔截，在server方法執行前後進行鏈路調用統計、超時統計等操作
3、線程模型，下面深入總結。
核心流程
1、創建接口代理類：從客戶端開始，利用動態代理創建server目標接口代理
2、序列化：將入參對象序列化
3、協議組裝：將序列化方式、協議版本、協議類型、方法簽名等信息組裝成一個協議包，交付給傳輸層進行發送
4、傳輸，server協議：傳輸層將協議包發送到sever端，server端將協議包解析，從中取出接口簽名、入參對象字節流信息
5、server反序列化：反序列化操作，找出接口實現類（server端真實的服務實現），invoke執行目標方法
6、server將結果序列化：Server端將返回結果按照同樣的序列化方式進行序列化操作。
7、server組裝協議：同樣，將序列化方式、協議版本、協議類型、方法簽名等信息組裝成一個協議包，發送給client
8、client解析協議，反序列化結果：Client接收sever返回的協議包，經過解析協議包中返回結果流，反序列化操作，得到RPC方法調用結果
這就是完整的一個RPC請求流程 （下次問終於不至於provider、consumer、zk註冊中心這碼事兒了）
從RPC架構和流程不難看出，RPC核心技術包括：動態代理、序列化、協議、通訊（netty）、註冊中心幾塊技術。動態代理就不多說了，可看上週的博文：JDK、CGLib、Javassist實現動態代理。本次重點討論序列化反序列化、傳輸協議、server端的線程模型。
二、序列化&反序列化
序列化載體：
xml：可擴展標記語言，自定義節點schema含義；但傳輸太多額外無用的數據（schema、節點解析）
Json：kv結構，易擴展
二進制字節流：緊湊，無額外多餘數據，減少傳輸佔用帶寬；但字節順序是固定的，例如user對象，1-8字節存儲userId，8-16存儲username；如果刪減user屬性，序列化反序列化時數據則對不上。則需要對屬性添加tagId標識，tagID（sortedId）=1，則標識userId，tagId=2標識username；type標識屬性類型（類型可知則知道對應占字節長度），value標識屬性值；（其實這裏用tagID標識屬性名，根據屬性名採用反射即可得到字段類型、長度信息；可能考慮效率，直接採用key標識）
這就定義好了採用字節流來序列化傳輸對象。
三、協議
常用的通訊協議、數據傳輸格式、底層傳輸協議、序列化方式、應用實現整理如下：
而公司自研的RPC框架採用自定義協議包。考慮到非開源，簡單介紹，思路一致，非實際實現。
協議一般包括定長包頭（公共屬性）和變長包體（業務數據）組成。例如
1byte(版本號)|1-4byte(協議總長度)|5-8byte(序列號)|9byte(服務編號)|10byte(消息體類型)|11byte(壓縮；算法)|12byte(序列化規則)
消息頭總長度：12 byte
協議總長度=消息頭總長度+消息體總長度（不含分界符）
四、總結
序列化、協議（自定義）還需結合代碼看實現邏輯，架構部同事提供的豐厚土壤，不吸收就辜負了。