***章聊了【“為什么要進行服務化，服務化究竟解決什么問題”】

第二章聊了【“微服務的服務粒度選型”】

上一篇聊了【“為什么說要搞定微服務架構，先搞定RPC框架?”】

通過上篇文章的介紹，知道了要實施微服務，首先要搞定RPC框架，RPC框架的職責要向【調用方】和【服務提供方】屏蔽各種復雜性：

(1)讓調用方感覺就像調用本地函數一樣

(2)讓服務提供方感覺就像實現一個本地函數一樣來實現服務

整個RPC框架又分為client部分與server部分： 

RPC-client的部分流程如上圖，要進行序列化反序列化(上圖中的1、4)，要進行發送字節流與接收字節流(上圖中的2、3)。

通過上一篇文章的用戶調研：

78%讀者 -> 繼續聊RPC框架技術細節

14%讀者 -> 聊微服務其他實踐

7%讀者 -> 不聊微服務了，聊最終一致性

那么按照多數讀者的意見，今天深入聊RPC的技術細節，本文先討論RPC-client部分的【序列化反序列化】實施細節(筆者不是這方面的專家，有不對之處，歡迎大家指正，任何具有建設性意見的留言，將在下一章share給更多的小伙伴)。

一、為什么要進行序列化

工程師通常使用“對象”來進行數據的操縱：

class User{ 
         std::Stringuser_name; 
         uint64_tuser_id; 
         uint32_tuser_age; 
}; 
  
User u = new User(“shenjian”); 
u.setUid(123); 
u.setAge(35); 

但當需要對數據進行存儲(固化存儲，緩存存儲)或者傳輸(跨進程網絡傳輸)時，“對象”就不這么好用了，往往需要把數據轉化成連續空間的二進制字節流，一些典型的場景是：

(1)數據庫索引的磁盤存儲：數據庫的索引在內存里是b+樹或者hash的格式，但這個格式是不能夠直接存儲到磁盤上的，所以需要把b+樹或者hash轉化為連續空間的二進制字節流，才能存儲到磁盤上

(2)緩存的KV存儲：redis/memcache是KV類型的緩存，緩存存儲的value必須是連續空間的二進制字節流，而不能夠是User對象

(3)數據的網絡傳輸：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對象(特別是語言支持反射的時候，就更easy了)。

第二個方法是自己實現二進制協議來進行序列化，還是以上面的User對象為例，可以設計一個這樣的通用協議： 

(1)頭4個字節表示序號

(2)序號后面的4個字節表示key的長度m

(3)接下來的m個字節表示key的值

(4)接下來的4個字節表示value的長度n

(5)接下來的n個字節表示value的值

(6)像xml一樣遞歸下去，直到描述完整個對象

上面的User對象，用這個協議描述出來可能是這樣的： 

(1)***行：序號4個字節(設0表示類名)，類名長度4個字節(長度為4)，接下來4個字節是類名(”User”)，共12字節

(2)第二行：序號4個字節(1表示***個屬性)，屬性長度4個字節(長度為9)，接下來9個字節是屬性名(”user_name”)，屬性值長度4個字節(長度為8)，屬性值8個字節(值為”shenjian”)，共29字節

(3)第三行：序號4個字節(2表示第二個屬性)，屬性長度4個字節(長度為7)，接下來7個字節是屬性名(”user_id”)，屬性值長度4個字節(長度為8)，屬性值8個字節(值為123)，共27字節

(3)第四行：序號4個字節(3表示第三個屬性)，屬性長度4個字節(長度為8)，接下來8個字節是屬性名(”user_name”)，屬性值長度4個字節(長度為4)，屬性值4個字節(值為35)，共24字節

整個二進制字節流共12+29+27+24=92字節

實際的序列化協議要考慮的細節遠比這個多，例如：強類型的語言不僅要還原屬性名，屬性值，還要還原屬性類型;復雜的對象不僅要考慮普通類型，還要考慮對象嵌套類型等。however，序列化的思路都是類似的。

三、序列化協議要考慮什么因素

不管使用成熟協議xml/json，還是自定義二進制協議來序列化對象，序列化協議設計時要考慮哪些因素呢?

(1)解析效率：這個應該是序列化協議應該首要考慮的因素，像xml/json解析起來比較耗時，需要解析doom樹，二進制自定義協議解析起來效率就很高

(2)壓縮率，傳輸有效性：同樣一個對象，xml/json傳輸起來有大量的xml標簽，信息有效性低，二進制自定義協議占用的空間相對來說就小多了

(3)擴展性與兼容性：是否能夠方便的增加字段，增加字段后舊版客戶端是否需要強制升級，都是需要考慮的問題，xml/json和上面的二進制協議都能夠方便的擴展

(4)可讀性與可調試性：這個很好理解，xml/json的可讀性就比二進制協議好很多

(5)跨語言：上面的兩個協議都是跨語言的，有些序列化協議是與開發語言緊密相關的，例如dubbo的序列化協議就只能支持Java的RPC調用

(6)通用性：xml/json非常通用，都有很好的第三方解析庫，各個語言解析起來都十分方便，上面自定義的二進制協議雖然能夠跨語言，但每個語言都要寫一個簡易的協議客戶端

(7)歡迎大家補充…

四、業內常見的序列化方式

(1)xml/json：解析效率，壓縮率都較差;擴展性、可讀性、通用性較好

(2)thrift：沒有用過，歡迎大家補充

(3)protobuf：Google出品，必屬精品，各方面都不錯，強烈推薦，屬于二進制協議，可讀性差了點，但也有類似的to-string協議幫助調試問題

(4)Avro：沒有用過，歡迎大家補充

(5)CORBA：沒有用過，歡迎大家補充

(6)mc_pack：懂的同學就懂，不懂的就不懂了，09年用過，傳說各方面都超越protobuf，懂行的同學可以說一下現狀

(7)…

五、后文預告

RPC-client的部分，除了要進行序列化反序列化，還要進行發送字節流與接收字節流，下一篇文章會介紹這一部分內容。

RPC-client中數據的發送與接收遠比序列化反序列化復雜，其涉及“連接池、負載均衡、故障轉移、隊列、超時、異步、上下文回調管理”等技術，具體細節，下篇再溝通。

文章轉載自微信公眾號“架構師之路”