服務化有什麼好處？
服務化的一個好處就是，不限定服務的提供方使用什麼技術選型，能夠實作大公司跨團隊的技術解耦，如下圖所示：
服務A：歐洲團隊維護，技術背景是Java
服務B：美洲團隊維護，用C++實作
服務C：中國團隊維護，技術棧是go
服務的上遊調用方，按照接口、協定即可完成對遠端服務的調用。
但實際上，大部分網際網路公司，研發團隊規模有限，大都使用同一套技術體系來實作服務：
這樣的話，如果沒有統一的服務架構，各個團隊的服務提供方就需要各自實作一套序列化、反序列化、網絡架構、連接配接池、收發線程、逾時處理、狀态機等“業務之外”的重複技術勞動，造成整體的低效。
是以，統一服務架構把上述“業務之外”的工作統一實作，是服務化首要解決的問題。
什麼是RPC？
Remote Procedure Call Protocol，遠端過程調用。
什麼是“遠端”，為什麼“遠”？
先來看下什麼是“近”，即“本地函數調用”。
當我們寫下：
int result = Add(1, 2); 這行代碼的時候，到底發生了什麼？
- 傳遞兩個入參
- 調用了本地代碼段中的函數，執行運算邏輯
- 傳回一個出參
這三個動作，都發生在同一個程序空間裡，這是本地函數調用。
那有沒有辦法，調用一個跨程序的函數呢？
典型的，這個程序部署在另一台伺服器上。
最容易想到的，兩個程序約定一個協定格式，使用Socket通信，來傳輸：
- 入參
- 調用哪個函數
- 出參
如果能夠實作，那這就是“遠端”過程調用。
Socket通信隻能傳遞連續的位元組流，如何将入參、函數都放到連續的位元組流裡呢？
假設，設計一個11位元組的請求封包：
- 前3個位元組填入函數名“add”
- 中間4個位元組填入第一個參數“1”
- 末尾4個位元組填入第二個參數“2”
同理，可以設計一個4位元組響應封包：
- 4個位元組填入處理結果“3”
調用方的代碼可能變為：
request = MakePacket(“add”, 1, 2);
SendRequest_ToService_B(request);
response = RecieveRespnse_FromService_B();
int result = unMakePacket(respnse);
這4個步驟是：
（1）将傳入參數變為位元組流；
（2）将位元組流發給服務B；
（3）從服務B接受傳回位元組流；
（4）将傳回位元組流變為傳出參數；
服務方的代碼可能變為：
request = RecieveRequest();
args/function = unMakePacket(request);
result = Add(1, 2);
response = MakePacket(result);
SendResponse(response);
這個5個步驟也很好了解：
（1）服務端收到位元組流；
（2）将位元組流轉為函數名與參數；
（3）本地調用函數得到結果；
（4）将結果轉變為位元組流；
（5）将位元組流發送給調用方；
這個過程用一張圖描述如下：
調用方與服務方的處理步驟都是非常清晰。
這個過程存在最大的問題是什麼呢？
調用方太麻煩了，每次都要關注很多底層細節：
- 入參到位元組流的轉化，即序列化應用層協定細節
- socket發送，即網絡傳輸協定細節
- socket接收
- 位元組流到出參的轉化，即反序列化應用層協定細節
能不能調用層不關注這個細節？
可以，RPC架構就是解決這個問題的，它能夠讓調用方“像調用本地函數一樣調用遠端的函數（服務）”。
講到這裡，是不是對RPC，對序列化範序列化有點感覺了？往下看，有更多的底層細節。
RPC架構的職責是什麼？
RPC架構，要向調用方屏蔽各種複雜性，要向服務提供方也屏蔽各類複雜性：
- 服務調用方client感覺就像調用本地函數一樣，來調用服務
- 服務提供方server感覺就像實作一個本地函數一樣，來實作服務
是以整個RPC架構又分為client部分與server部分，實作上面的目标，把複雜性屏蔽，就是RPC架構的職責。
如上圖所示，業務方的職責是：
- 調用方A，傳入參數，執行調用，拿到結果
- 服務方B，收到參數，執行邏輯，傳回結果
RPC架構的職責是，中間大藍框的部分：
- client端：序列化、反序列化、連接配接池管理、負載均衡、故障轉移、隊列管理，逾時管理、異步管理等等
- server端：服務端元件、服務端收發包隊列、io線程、工作線程、序列化反序列化等
server端的技術大家了解的比較多，接下來重點講講client端的技術細節。
先來看看RPC-client部分的“序列化反序列化”部分。
為什麼要進行序列化？
工程師通常使用“對象”來進行資料的操縱：
class User{
std::String user_name;
uint64_t user_id;
uint32_t user_age;
};
User u = new User(“shenjian”);
u.setUid(123);
u.setAge(35);
但當需要對資料進行存儲或者傳輸時，“對象”就不這麼好用了，往往需要把資料轉化成連續空間的“二進制位元組流”，一些典型的場景是：
- 資料庫索引的磁盤存儲：資料庫的索引在記憶體裡是b+樹，但這個格式是不能夠直接存儲到磁盤上的，是以需要把b+樹轉化為連續空間的二進制位元組流，才能存儲到磁盤上
- 緩存的KV存儲：redis/memcache是KV類型的緩存，緩存存儲的value必須是連續空間的二進制位元組流，而不能夠是User對象
- 資料的網絡傳輸：socket發送的資料必須是連續空間的二進制位元組流，也不能是對象
所謂序列化（Serialization），就是将“對象”形态的資料轉化為“連續空間二進制位元組流”形态資料的過程。這個過程的逆過程叫做反序列化。
怎麼進行序列化？
這是一個非常細節的問題，要是讓你來把“對象”轉化為位元組流，你會怎麼做？很容易想到的一個方法是xml（或者json）這類具有自描述特性的标記性語言：
<class name=”User”>
<element name=”user_name” type=”std::String” value=”shenjian” />
<element name=”user_id” type=”uint64_t” value=”123” />
<element name=”user_age” type=”uint32_t” value=”35” />
</class>
規定好轉換規則，發送方很容易把User類的一個對象序列化為xml，服務方收到xml二進制流之後，也很容易将其範序列化為User對象。
畫外音：語言支援反射時，這個工作很容易。
第二個方法是自己實作二進制協定來進行序列化，還是以上面的User對象為例，可以設計一個這樣的通用協定：
- 頭4個位元組表示序号
- 序号後面的4個位元組表示key的長度m
- 接下來的m個位元組表示key的值
- 接下來的4個位元組表示value的長度n
- 接下來的n個位元組表示value的值
- 像xml一樣遞歸下去，直到描述完整個對象
上面的User對象，用這個協定描述出來可能是這樣的：
- 第一行：序号4個位元組（設0表示類名），類名長度4個位元組（長度為4），接下來4個位元組是類名（”User”），共12位元組
- 第二行：序号4個位元組（1表示第一個屬性），屬性長度4個位元組（長度為9），接下來9個位元組是屬性名（”user_name”），屬性值長度4個位元組（長度為8），屬性值8個位元組（值為”shenjian”），共29位元組
- 第三行：序号4個位元組（2表示第二個屬性），屬性長度4個位元組（長度為7），接下來7個位元組是屬性名（”user_id”），屬性值長度4個位元組（長度為8），屬性值8個位元組（值為123），共27位元組
- 第四行：序号4個位元組（3表示第三個屬性），屬性長度4個位元組（長度為8），接下來8個位元組是屬性名（”user_name”），屬性值長度4個位元組（長度為4），屬性值4個位元組（值為35），共24位元組
整個二進制位元組流共12+29+27+24=92位元組。
實際的序列化協定要考慮的細節遠比這個多，例如：強類型的語言不僅要還原屬性名，屬性值，還要還原屬性類型；複雜的對象不僅要考慮普通類型，還要考慮對象嵌套類型等。無論如何，序列化的思路都是類似的。
序列化協定要考慮什麼因素？
不管使用成熟協定xml/json，還是自定義二進制協定來序列化對象，序列化協定設計時都需要考慮以下這些因素。
- 解析效率：這個應該是序列化協定應該首要考慮的因素，像xml/json解析起來比較耗時，需要解析doom樹，二進制自定義協定解析起來效率就很高
- 壓縮率，傳輸有效性：同樣一個對象，xml/json傳輸起來有大量的xml标簽，資訊有效性低，二進制自定義協定占用的空間相對來說就小多了
- 擴充性與相容性：是否能夠友善的增加字段，增加字段後舊版用戶端是否需要強制更新，都是需要考慮的問題，xml/json和上面的二進制協定都能夠友善的擴充
- 可讀性與可調試性：這個很好了解，xml/json的可讀性就比二進制協定好很多
- 跨語言：上面的兩個協定都是跨語言的，有些序列化協定是與開發語言緊密相關的，例如dubbo的序列化協定就隻能支援Java的RPC調用
- 通用性：xml/json非常通用，都有很好的第三方解析庫，各個語言解析起來都十分友善，上面自定義的二進制協定雖然能夠跨語言，但每個語言都要寫一個簡易的協定用戶端
有哪些常見的序列化方式？
- xml/json：解析效率，壓縮率都較差，擴充性、可讀性、通用性較好
- thrift
- protobuf：Google出品，必屬精品，各方面都不錯，強烈推薦，屬于二進制協定，可讀性差了點，但也有類似的to-string協定幫助調試問題
- Avro
- CORBA
- mc_pack：懂的同學就懂，不懂的就不懂了，09年用過，傳說各方面都超越protobuf，懂行的同學可以說一下現狀
…
RPC-client除了：
- 序列化反序列化的部分（上圖中的1、4）
還包含：
- 發送位元組流與接收位元組流的部分（上圖中的2、3）
這一部分，又分為同步調用與異步調用兩種方式，下面一一來進行介紹。
畫外音：搞通透RPC-client确實不容易。
同步調用的代碼片段為：
Result = Add(Obj1, Obj2);// 得到Result之前處于阻塞狀态
異步調用的代碼片段為：
Add(Obj1, Obj2, callback);// 調用後直接傳回，不等結果
處理結果通過回調為：
callback(Result){// 得到處理結果後會調用這個回調函數
…
}
這兩類調用，在RPC-client裡，實作方式完全不一樣。
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結果，工作線程繼續往下走；
畫外音：請對照架構圖中的1-10步驟閱讀。
連接配接池元件有什麼作用？
RPC架構鎖支援的負載均衡、故障轉移、發送逾時等特性，都是通過連接配接池元件去實作的。
典型連接配接池元件對外提供的接口為：
int ConnectionPool::init(…);
Connection ConnectionPool::getConnection();
int ConnectionPool::putConnection(Connection t);
init做了些什麼？
和下遊RPC-server（一般是一個叢集），建立N個tcp長連接配接，即所謂的連接配接“池”。
getConnection做了些什麼？
從連接配接“池”中拿一個連接配接，加鎖（置一個标志位），傳回給調用方。
putConnection做了些什麼？
将一個配置設定出去的連接配接放回連接配接“池”中，解鎖（也是置一個标志位）。
如何實作負載均衡？
連接配接池中建立了與一個RPC-server叢集的連接配接，連接配接池在傳回連接配接的時候，需要具備随機性。
如何實作故障轉移？
連接配接池中建立了與一個RPC-server叢集的連接配接，當連接配接池發現某一個機器的連接配接異常後，需要将這個機器的連接配接排除掉，傳回正常的連接配接，在機器恢複後，再将連接配接加回來。
如何實作發送逾時？
因為是同步阻塞調用，拿到一個連接配接後，使用帶逾時的send/recv即可實作帶逾時的發送和接收。
總的來說，同步的RPC-client的實作是相對比較容易的，序列化元件、連接配接池元件配合多工作線程數，就能夠實作。
遺留問題，工作線程數設定為多少最合适？
這個問題在《工作線程數究竟要設定為多少最合适？》中讨論過，此處不再深究。
RPC-client異步回調架構如何？
所謂異步回調，在得到結果之前，不會處于阻塞狀态，理論上任何時間都沒有任何線程處于阻塞狀态，是以異步回調的模型，理論上隻需要很少的工作線程與服務連接配接就能夠達到很高的吞吐量，如上圖所示：
- 左邊的框框，是少量工作線程（少數幾個就行了）進行調用與回調
- 中間粉色的框框，代表了RPC-client元件
- 藍色六個小框，代表了異步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三個響應包：
怎麼知道哪個請求包與哪個響應包對應？
怎麼知道哪個響應包與哪個回調函數對應？
可以通過“請求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在上下文管理器裡找不到上下文，就直接将請求丢棄。
畫外音：因為已經逾時處理了，無法恢複上下文。
無論如何，異步回調和同步回調相比，除了序列化元件和連接配接池元件，會多出上下文管理器，逾時管理器，下遊收發隊列，下遊收發線程等元件，并且對調用方的調用習慣有影響。
畫外音：程式設計習慣，由同步變為了回調。
異步回調能提高系統整體的吞吐量，具體使用哪種方式實作RPC-client，可以結合業務場景來選取。
總結
什麼是RPC調用？
像調用本地函數一樣，調用一個遠端服務。
為什麼需要RPC架構？
RPC架構用于屏蔽RPC調用過程中的序列化，網絡傳輸等技術細節。讓調用方隻專注于調用，服務方隻專注于實作調用。
什麼是序列化？為什麼需要序列化？
把對象轉化為連續二進制流的過程，叫做序列化。磁盤存儲，緩存存儲，網絡傳輸隻能操作于二進制流，是以必須序列化。
同步RPC-client的核心元件是什麼？
同步RPC-client的核心元件是序列化元件、連接配接池元件。它通過連接配接池來實作負載均衡與故障轉移，通過阻塞的收發來實作逾時處理。
異步RPC-client的核心元件是什麼？
異步RPC-client的核心元件是序列化元件、連接配接池元件、收發隊列、收發線程、上下文管理器、逾時管理器。它通過“請求id”來關聯請求包-響應包-回調函數，用上下文管理器來管理上下文，用逾時管理器中的timer觸發逾時回調，推進業務流程的逾時處理。
思路比結論重要。
本文轉自“架構師之路”公衆号，58沈劍提供。