序列化
序列化是將一個對象變成一個二進制流就是序列化， 反序列化是將二進制流轉換成對象。
為什么要序列化？
1. 減小內存空間和網絡傳輸的帶寬
2. 分布式的可擴展性
3. 通用性，接口可共用。
dubbo RPC是dubbo體系中最核心的一種高性能、高吞吐量的遠程調用方式，我喜歡稱之為多路復用的TCP長連接調用，簡單的說：
1. 長連接：避免了每次調用新建TCP連接，提高了調用的響應速度
2. 多路復用：單個TCP連接可交替傳輸多個請求和響應的消息，降低了連接的等待閑置時間，從而減少了同樣並發數下的網絡連接數，提高了系統吞吐量。
dubbo RPC主要用於兩個dubbo系統之間作遠程調用，特別適合高並發、小數據的互聯網場景。
而序列化對於遠程調用的響應速度、吞吐量、網絡帶寬消耗等同樣也起着至關重要的作用，是我們提升分布式系統性能的最關鍵因素之一。
在dubbo RPC中，同時支持多種序列化方式，例如：
1、dubbo序列化：阿里尚未開發成熟的高效java序列化實現，阿里不建議在生產環境使用它
2、hessian2序列化：hessian是一種跨語言的高效二進制序列化方式。但這里實際不是原生的hessian2序列化，而是阿里修改過的hessian lite，它是dubbo RPC默認啟用的序列化方式
3、json序列化：目前有兩種實現，一種是采用的阿里的fastjson庫，另一種是采用dubbo中自己實現的簡單json庫，但其實現都不是特別成熟，而且json這種文本序列化性能一般不如上面兩種二進制序列化。
4、java序列化：主要是采用JDK自帶的Java序列化實現，性能很不理想。
在通常情況下，這四種主要序列化方式的性能從上到下依次遞減。對於dubbo RPC這種追求高性能的遠程調用方式來說，實際上只有1、2兩種高效序列化方式比較般配，而第1個dubbo序列化由於還不成熟，所以實際只剩下2可用，所以 dubbo RPC默認采用hessian2序列化。
但hessian是一個比較老的序列化實現了，而且它是跨語言的，所以不是單獨針對java進行優化的。最近幾年，各種新的高效序列化方式層出不窮，不斷刷新序列化性能的上限，最典型的包括：
- 專門針對Java語言的：Kryo，FST等等
- 跨語言的：Protostuff，ProtoBuf，Thrift，Avro，MsgPack等等
這些序列化方式的性能多數都顯著優於hessian2（甚至包括尚未成熟的dubbo序列化）
其中，Kryo是一種非常成熟的序列化實現，已經在Twitter、Groupon、Yahoo以及多個著名開源項目（如Hive、Storm）中廣泛的使用。而FST是一種較新的序列化實現，目前還缺乏足夠多的成熟使用案例，但我認為它還是非常有前途的。
序列化性能分析與測試
使用兩台相同的服務器配置，相同的 jvm 啟動參數，通過配置不同數量的多線程以及傳輸文本大小進行壓測
序列化生成字節碼的大小是一個比較有確定性的指標，它決定了遠程調用的網絡傳輸時間和帶寬占用。
針對復雜對象的結果如下（數值越小越好）：
Dubbo RPC 中不同序列化響應時間和吞吐量對比：
測試總結
就目前結果而言，我們可以看到不管從生成字節的大小，還是平均響應時間和平均TPS，Kryo 和 FST 相比 Dubbo RPC 中原有的序列化方式都有非常顯著的改進。如果只是 java to java 且是線上使用，建議使用序列化協議：kryo。
有篇博文自己寫代碼壓測發現 fst 比 kryo 效率更高，但是有高手評論說寫法有問題，經過更改最后可能還是 kryo 效率更高，具體博文地址：https://www.iteye.com/blog/liuyieyer-2136240
有興趣的同學可以自己研究一下。