為什么說要搞定微服務架構，先搞定RPC框架？
1. 為什么說要搞定微服務架構，先搞定RPC框架？
如果沒有統一的服務框架，RPC框架，各個團隊的服務提供方就需要各自實現一套序列化、反序列化、網絡框架、連接池、收發線程、超時處理、狀態機等“業務之外”的重復技術勞動，造成整體的低效。
所以，統一RPC框架把上述“業務之外”的技術勞動統一處理，是服務化首要解決的問題。
RPC框架能夠讓調用方“像調用本地函數一樣調用遠端的函數（服務）”。
2. RPC框架職責
通過上面的討論，RPC框架要向調用方屏蔽各種復雜性，要向服務提供方也屏蔽各類復雜性：
1）調用方感覺就像調用本地函數一樣
2）服務提供方感覺就像實現一個本地函數一樣來實現服務
所以整個RPC框架又分為client部分與server部分，負責把整個非（1）（2）的各類復雜性屏蔽，這些復雜性就是RPC框架的職責。
再細化一些，
client端又包含：序列化、反序列化、連接池管理、負載均衡、故障轉移、隊列管理，超時管理、異步管理等等等等職責。
server端包含：服務端組件、服務端收發包隊列、io線程、工作線程、序列化反序列化、上下文管理器、超時管理、異步回調等等等等職責。
微服務架構之RPC-client序列化細節
1. 為什么要進行序列化
工程師通常使用“對象”來進行數據的操縱，但當需要對數據進行存儲（固化存儲，緩存存儲）或者傳輸（跨進程網絡傳輸）時，“對象”就不這么好用了，往往需要把數據轉化成連續空間的二進制字節流，一些典型的場景是：
1）數據庫索引的磁盤存儲：數據庫的索引在內存里是b+樹或者hash的格式，但這個格式是不能夠直接存儲到磁盤上的，所以需要把b+樹或者hash轉化為連續空間的二進制字節流，才能存儲到磁盤上
2）緩存的KV存儲：redis/memcache是KV類型的緩存，緩存存儲的value必須是連續空間的二進制字節流，而不能夠是User對象
3）數據的網絡傳輸：socket發送的數據必須是連續空間的二進制字節流，也不能是對象
所謂序列化（Serialization），就是將“對象”形態的數據轉化為“連續空間二進制字節流”形態數據的過程，以方便存儲與傳輸。這個過程的逆過程叫做反序列化。
2. 怎么進行序列化
1）很容易想到的一個方法是xml（或者json）這類具有自描述特性的標記性語言
2）第二個方法是自己實現二進制協議來進行序列化，還是以上面的User對象為例，可以設計一個這樣的通用協議：
（1）頭4個字節表示序號
（2）序號后面的4個字節表示key的長度m
（3）接下來的m個字節表示key的值
（4）接下來的4個字節表示value的長度n
（5）接下來的n個字節表示value的值
（6）像xml一樣遞歸下去，直到描述完整個對象
實際的序列化協議要考慮的細節遠比這個多，例如：強類型的語言不僅要還原屬性名，屬性值，還要還原屬性類型；復雜的對象不僅要考慮普通類型，還要考慮對象嵌套類型等。however，序列化的思路都是類似的。
3. 序列化協議要考慮什么因素
不管使用成熟協議xml/json，還是自定義二進制協議來序列化對象，序列化協議設計時要考慮哪些因素呢？
1）解析效率：這個應該是序列化協議應該首要考慮的因素，像xml/json解析起來比較耗時，需要解析doom樹，二進制自定義協議解析起來效率就很高
2）壓縮率，傳輸有效性：同樣一個對象，xml/json傳輸起來有大量的xml標簽，信息有效性低，二進制自定義協議占用的空間相對來說就小多了
3）擴展性與兼容性：是否能夠方便的增加字段，增加字段后舊版客戶端是否需要強制升級，都是需要考慮的問題，xml/json和上面的二進制協議都能夠方便的擴展
4）可讀性與可調試性：這個很好理解，xml/json的可讀性就比二進制協議好很多
5）跨語言：上面的兩個協議都是跨語言的，有些序列化協議是與開發語言緊密相關的，例如dubbo的序列化協議就只能支持Java的RPC調用
6）通用性：xml/json非常通用，都有很好的第三方解析庫，各個語言解析起來都十分方便，上面自定義的二進制協議雖然能夠跨語言，但每個語言都要寫一個簡易的協議客戶端
7）歡迎大家補充…
4. 業內常見的序列化方式
1）xml/json：解析效率，壓縮率都較差；擴展性、可讀性、通用性較好
2）thrift：沒有用過，歡迎大家補充
3）protobuf：Google出品，必屬精品，各方面都不錯，強烈推薦，屬於二進制協議，可讀性差了點，但也有類似的to-string協議幫助調試問題
4）Avro：沒有用過，歡迎大家補充
5）CORBA：沒有用過，歡迎大家補充
6）mc_pack：懂的同學就懂，不懂的就不懂了，09年用過，傳說各方面都超越protobuf，懂行的同學可以說一下現狀
7）…
RPC-client異步收發核心細節
1. RPC-client主要功能：
1）序列化反序列化的部分（上圖中的1、4）
2）發送字節流與接收字節流的部分（上圖中的2、3）
2. 客戶端調用又分為同步調用與異步調用
同步調用的代碼片段為：
Result = Add(Obj1, Obj2);// 得到Result之前處於阻塞狀態
異步調用的代碼片段為：
Add(Obj1, Obj2, callback);// 調用后直接返回，不等結果
處理結果通過回調得到：
callback(Result){// 得到處理結果后會調用這個回調函數
…
}
3. RPC-client同步調用
所謂同步調用，在得到結果之前，一直處於阻塞狀態，會一直占用一個工作線程，上圖簡單的說明了一下組件、交互、流程步驟。
上圖中的左邊大框，就代表了調用方的一個工作線程。
左邊粉色中框，代表了RPC-client組件。
右邊橙色框，代表了RPC-server。
藍色兩個小框，代表了同步RPC-client兩個核心組件，序列化組件與連接池組件。
白色的流程小框，以及箭頭序號1-10，代表整個工作線程的串行執行步驟：
1）業務代碼發起RPC調用，Result=Add(Obj1,Obj2)
2）序列化組件，將對象調用序列化成二進制字節流，可理解為一個待發送的包packet1
3）通過連接池組件拿到一個可用的連接connection
4）通過連接connection將包packet1發送給RPC-server
5）發送包在網絡傳輸，發給RPC-server
6）響應包在網絡傳輸，發回給RPC-client
7）通過連接connection從RPC-server收取響應包packet2
8）通過連接池組件，將conneciont放回連接池
9）序列化組件，將packet2范序列化為Result對象返回給調用方
10）業務代碼獲取Result結果，工作線程繼續往下走
RPC框架需要支持負載均衡、故障轉移、發送超時，這些特性都是通過連接池組件去實現的。
連接池組件
典型連接池組件對外提供的接口為：
int ConnectionPool::init(…);
Connection ConnectionPool::getConnection();
intConnectionPool::putConnection(Connection t);
【INIT】
和下游RPC-server（一般是一個集群），建立N個tcp長連接，即所謂的連接“池”
【getConnection】
從連接“池”中拿一個連接，加鎖（置一個標志位），返回給調用方
【putConnection】
將一個分配出去的連接放回連接“池”中，解鎖（也是置一個標志位）
如何實現負載均衡？
回答：連接池中建立了與一個RPC-server集群的連接，連接池在返回連接的時候，需要具備隨機性。
如何實現故障轉移？
回答：連接池中建立了與一個RPC-server集群的連接，當連接池發現某一個機器的連接異常后，需要將這個機器的連接排除掉，返回正常的連接，在機器恢復后，再將連接加回來。
如何實現發送超時？
回答：因為是同步阻塞調用，拿到一個連接后，使用帶超時的send/recv即可實現帶超時的發送和接收。
總的來說，同步的RPC-client的實現是相對比較容易的，序列化組件、連接池組件配合多工作線程數，就能夠實現。還有一個問題，就是【“工作線程數設置多少最為合適？”】，這個問題在之前的文章中討論過，此處不再深究。
4. PC-client異步回調
所謂異步回調，在得到結果之前，不會處於阻塞狀態，理論上任何時間都沒有任何線程處於阻塞狀態，因此異步回調的模型，理論上只需要很少的工作線程與服務連接就能夠達到很高的吞吐量。
上圖中左邊的框框，是少量工作線程（少數幾個就行了）進行調用與回調。
中間粉色的框框，代表了RPC-client組件。
右邊橙色框，代表了RPC-server。
藍色六個小框，代表了異步RPC-client六個核心組件：上下文管理器，超時管理器，序列化組件，下游收發隊列，下游收發線程，連接池組件。
白色的流程小框，以及箭頭序號1-17，代表整個工作線程的串行執行步驟：
1）業務代碼發起異步RPC調用，Add(Obj1,Obj2, callback)
2）上下文管理器，將請求，回調，上下文存儲起來
3）序列化組件，將對象調用序列化成二進制字節流，可理解為一個待發送的包packet1
4）下游收發隊列，將報文放入“待發送隊列”，此時調用返回，不會阻塞工作線程
5）下游收發線程，將報文從“待發送隊列”中取出，通過連接池組件拿到一個可用的連接connection
6）通過連接connection將包packet1發送給RPC-server
7）發送包在網絡傳輸，發給RPC-server
8）響應包在網絡傳輸，發回給RPC-client
9）通過連接connection從RPC-server收取響應包packet2
10）下游收發線程，將報文放入“已接受隊列”，通過連接池組件，將conneciont放回連接池
11）下游收發隊列里，報文被取出，此時回調將要開始，不會阻塞工作線程
12）序列化組件，將packet2范序列化為Result對象
13）上下文管理器，將結果，回調，上下文取出
14）通過callback回調業務代碼，返回Result結果，工作線程繼續往下走
如果請求長時間不返回，處理流程是：
15）上下文管理器，請求長時間沒有返回
16）超時管理器拿到超時的上下文
17）通過timeout_cb回調業務代碼，工作線程繼續往下走
上下文管理器
為什么需要上下文管理器？
回答：由於請求包的發送，響應包的回調都是異步的，甚至不在同一個工作線程中完成，需要一個組件來記錄一個請求的上下文，把請求-響應-回調等一些信息匹配起來。
如何將請求-響應-回調這些信息匹配起來？
這是一個很有意思的問題，通過一條連接往下游服務發送了a，b，c三個請求包，異步的收到了x，y，z三個響應包：
（1）怎么知道哪個請求包與哪個響應包對應？
（2）怎么知道哪個響應包與哪個回調函數對應？
回答：這是通過【請求id】來實現請求-響應-回調的串聯的。
整個處理流程如上，通過請求id，上下文管理器來對應請求-響應-callback之間的映射關系：
1）生成請求id
2）生成請求上下文context，上下文中包含發送時間time，回調函數callback等信息
3）上下文管理器記錄req-id與上下文context的映射關系，
4）將req-id打在請求包里發給RPC-server
5）RPC-server將req-id打在響應包里返回
6）由響應包中的req-id，通過上下文管理器找到原來的上下文context
7）從上下文context中拿到回調函數callback
8）callback將Result帶回，推動業務的進一步執行
如何實現負載均衡，故障轉移？
回答：與同步的連接池思路相同。不同在於，同步連接池使用阻塞方式收發，需要與一個服務的一個ip建立多條連接，異步收發，一個服務的一個ip只需要建立少量的連接（例如，一條tcp連接）。
如何實現超時發送與接收？
回答：同步阻塞發送，可以直接使用帶超時的send/recv來實現，異步非阻塞的nio的網絡報文收發，如何實現超時接收呢？（由於連接不會一直等待回包，那如何知曉超時呢？）這時，超時管理器就上場啦。
超時管理器
超時管理器，用於實現請求回包超時回調處理。
每一個請求發送給下游RPC-server，會在上下文管理器中保存req-id與上下文的信息，上下文中保存了請求很多相關信息，例如req-id，回包回調，超時回調，發送時間等。
超時管理器啟動timer對上下文管理器中的context進行掃描，看上下文中請求發送時間是否過長，如果過長，就不再等待回包，直接超時回調，推動業務流程繼續往下走，並將上下文刪除掉。
如果超時回調執行后，正常的回包又到達，通過req-id在上下文管理器里找不到上下文，就直接將請求丟棄（因為已經超時處理過了）。
however，異步回調和同步回調相比，除了序列化組件和連接池組件，會多出上下文管理器，超時管理器，下游收發隊列，下游收發線程等組件，並且對調用方的調用習慣有影響（同步->回調）。
異步回調能提高系統整體的吞吐量，具體使用哪種方式實現RPC-client，可以結合業務場景來選取（對時延敏感的可以選用同步，對吞吐量敏感的可以選用異步）。