我們都知道程序在運(yùn)行的過程中經(jīng)常需要進(jìn)行服務(wù)間的通信和交互，特別是在當(dāng)下微服務(wù)的架構(gòu)下，每個(gè)系統(tǒng)都會龐大那么為了提高服務(wù)間的通信效率以及數(shù)據(jù)傳輸?shù)男阅埽覀兺紩⑿枰獋鬏數(shù)臄?shù)據(jù)進(jìn)行序列化，然后再進(jìn)行傳輸。

什么是序列化

關(guān)于序列化相信大家都很了解，在 Java 中我們經(jīng)常就可以看到很多實(shí)體類或者 POJO 都會實(shí)現(xiàn) Serializable 接口，有了解過 Serializable 接口的小伙伴應(yīng)該都知道，這個(gè)接口是一個(gè)空接口，只是用來標(biāo)記的。所謂序列化簡單來說就是在傳輸對象之前將對象轉(zhuǎn)換成二進(jìn)制字節(jié)進(jìn)行傳輸，接收端在收到二進(jìn)制數(shù)據(jù)后再反序列化轉(zhuǎn)化成普通對象。

所以說序列化最終的目的是為了對象可以跨平臺存儲和進(jìn)行網(wǎng)絡(luò)傳輸。之所以需要序列化是因?yàn)樵诰W(wǎng)絡(luò)傳輸?shù)臅r(shí)候，我們需要經(jīng)過 IO，而 IO 傳輸支持的就是字節(jié)數(shù)組這種格式，所以序列化過后可以更好的傳輸。另外反序列化就是根據(jù)字節(jié)數(shù)組反向生成對象，是一個(gè)逆向過程。

常見的序列化方式

既然知道了什么是序列化，那么接下來我們看看有哪些常見的序列化方式。

JSON

當(dāng)下最流行的序列化方式無非是 JSON 了，而且 JSON 作為前后端交互使用最廣泛的格式，形式如下。作為最通用的格式，各種語言都支持，并且可以支持復(fù)雜的對象。

{"name":"鴨血粉絲","age":4,"sex":"男"}

JSON 作為一個(gè)序列化方案，它的優(yōu)點(diǎn)是可讀性很高，跨平臺跨語言支持；但是有個(gè)缺點(diǎn)那就是體積較大，很存在很多冗余內(nèi)容，比如雙引號，花括號。

相信 JSON 大家在工作中使用的肯定會廣泛，阿里提供的 fastjson 包是我們項(xiàng)目中必不可少的一個(gè)依賴。

<dependency>
   <groupId>com.alibaba</groupId>
   <artifactId>fastjson</artifactId>
</dependency>

XML

<?xml version="1.0"?>
<Person version="4.0">
 <name>鴨血粉絲</name>
 <age>4</age>
 <sex>男</sex>
</Person>

前些年不管是使用 SSM，還是使用 Spring 都會有很多 XML 的配置文件，現(xiàn)在很多被注解代替了，但是 XML 還是支持使用的。另外有一些廣電或者銀卡等老系統(tǒng)里面會有很多基于 XML 的協(xié)議開發(fā)的系統(tǒng)和服務(wù)。

阿粉之前做項(xiàng)目就遇到過銀行的項(xiàng)目，里面都是很古老的 XML 協(xié)議，對接起來真是頭疼呀~

通過上面例子我們可以看到，XML 協(xié)議的優(yōu)缺點(diǎn)跟 JSON 類似，優(yōu)點(diǎn)也是可讀性很強(qiáng)，跨平臺跨語言支持，缺點(diǎn)也是體積大，容易內(nèi)容多?？梢钥吹綖榱擞涗浺粋€(gè)字段的值，每個(gè)標(biāo)簽都需要成對存在，過于冗余了。

Protobuf

Protobuf 是谷歌提出的一種序列化協(xié)議，Protobuf 是一種接口定義語言，它與語言和平臺無關(guān)。它是一種序列化結(jié)構(gòu)化數(shù)據(jù)并通過網(wǎng)絡(luò)傳輸?shù)姆绞?，使?nbsp;Protobuf 傳輸二進(jìn)制文件，與 JSON 的字符串格式相比，它提高了傳輸速度。

這里提到 Protobuf 是一種接口定義語言，說明也是一種語言，既然是語言那就有自己的關(guān)鍵字以及規(guī)則，所以對于Protobuf 協(xié)議，我們需要創(chuàng)建一個(gè)后綴為 .proto 

syntax = "proto2";
package com.demo;
message Request {
    required int32 version = 1;
    required string id = 2;
    message Model  {
        required int32 id = 1;
        required string pid = 2;
        optional int32 width = 3;
        optional int32 height = 4;
        optional int32 pos = 5;
    }
    repeated Model model = 3;
}

message 關(guān)鍵字表示定義一個(gè)結(jié)構(gòu)體，required 表示必須，optional 表示可選，此外還有字段的名稱和類型。這個(gè)原始的 proto 文件是通用的，只要定義一次就好，不管使用哪種語言都可以通過 proto 工具自動生成對應(yīng)語言的代碼。

比如要生成 Java 代碼，我們可以執(zhí)行下面的命令

protoc --java_out=. demo.proto 就會在指定的目錄下，生成對應(yīng)的 Demo.java，想生成其他語言的代碼，只需要修改命令執(zhí)行的參數(shù)即可，生成的代碼內(nèi)容會有很多，可以不用管直接使用就行。

我們定義模型的結(jié)構(gòu)一次，然后就可以使用生成的源代碼輕松地使用 Java、Python、Go、Ruby 和 C++ 等各種語言在各種數(shù)據(jù)流中寫入和讀取結(jié)構(gòu)化數(shù)據(jù)。

Protobuf 的優(yōu)點(diǎn)主要是性能高，體積小，缺點(diǎn)就是要學(xué)習(xí)一下特定的關(guān)鍵詞以及要下載按照 Protobuf 命令工具。

Thrift

Thrift 也是一種序列化協(xié)議，具體的使用方式跟 Protobuf 類似，只不過 Thrift 是 Facebook 提出來的一種協(xié)議。

Thrift是一種接口描述語言和二進(jìn)制通訊協(xié)議，原由Facebook于2007年開發(fā)，2008年正式提交Apache基金會托管，成為Apache下的開源項(xiàng)目。

Thrift 是一個(gè) RPC 通訊框架，采用自定義的二進(jìn)制通訊協(xié)議設(shè)計(jì)。相比于傳統(tǒng)的HTTP協(xié)議，效率更高，傳輸占用帶寬更小。另外，Thrift是跨語言的。Thrift的接口描述文件，通過其編譯器可以生成不同開發(fā)語言的通訊框架。

Thrift 的使用方式跟 Protobuf 類似，也是有一個(gè) .thrift 后綴的文件，然后通過命令生成各種語言的代碼，這里就不演示了。

除了上面提到的四種序列化方式之外，還有 Hessian，JDK 原生等序列化方式，就不一一介紹了。

序列化協(xié)議選擇

前面提到是幾種序列化的協(xié)議方式，那么對于我們平常項(xiàng)目中使用的時(shí)候，我們應(yīng)該如何選擇自己的協(xié)議呢？需要關(guān)注哪幾個(gè)方面的內(nèi)容呢？

每個(gè)協(xié)議有每個(gè)協(xié)議的特點(diǎn)，具體選擇哪種協(xié)議我們要根據(jù)實(shí)際的場景來選擇，比如說如果是前后端對接，那么自然是 JSON 最合適，應(yīng)該網(wǎng)頁的交互要求不需要太高，秒級別是可以接受的，所以我們可以更加關(guān)注可讀性。但是如果是微服務(wù)之間的數(shù)據(jù)傳輸，那我們就可以選擇 Protobuf 或者 Thrift 這種更高效的協(xié)議來進(jìn)行傳輸，因?yàn)檫@種場景我們對于協(xié)議序列化的體積和速度都有很高的要求。

總結(jié)

今天阿粉給大家介紹了幾種序列化的協(xié)議，相信大家在日常工作中必然會用到，上面提到的協(xié)議你是否都用過呢？歡迎在評論區(qū)留言探討。