ProtoBuf 作為一種跨平臺、語言無關、可擴充套件的序列化結構資料的方法，已廣泛應用於網路資料交換及儲存。隨著網際網路的發展，系統的異構性會愈發突出，跨語言的需求會愈加明顯，同時 gRPC 也大有取代Restful之勢，而 ProtoBuf 作為g RPC 跨語言、高效能的法寶，我們技術人有必要
深入理解 ProtoBuf 原理，為以後的技術更新和選型打下基礎。
我將過去的學習過程以及實踐經驗，總結成系列文章，與大家一起探討學習，希望大家能有所收穫，當然其中有不正確的地方也歡迎大家批評指正。
本系列文章主要包含：
- 深入理解 ProtoBuf 原理與工程實踐（概述）
- 深入理解 ProtoBuf 原理與工程實踐（編碼）
- 深入理解 ProtoBuf 原理與工程實踐（序列化）
- 深入理解 ProtoBuf 原理與工程實踐（工程實踐）
一、什麼是ProtoBuf
ProtoBuf(Protocol Buffers)是一種跨平臺、語言無關、可擴充套件的序列化結構資料的方法，可用於網路資料交換及儲存。
在序列化結構化資料的機制中，ProtoBuf是靈活、高效、自動化的，相對常見的XML、JSON，描述同樣的資訊，ProtoBuf序列化後資料量更小、序列化/反序列化速度更快、更簡單。
一旦定義了要處理的資料的資料結構之後，就可以利用ProtoBuf的程式碼生成工具生成相關的程式碼。只需使用 Protobuf 對資料結構進行一次描述，即可利用各種不同語言(proto3支援C++, Java, Python, Go, Ruby, Objective-C, C#)或從各種不同流中對你的結構化資料輕鬆讀寫。
二、為什麼是 ProtoBuf
大家可能會覺得 Google 發明 ProtoBuf 是為了解決序列化速度的，其實真實的原因並不是這樣的。
ProtoBuf最先開始是 Google用來解決索引伺服器 request/response 協議的。沒有ProtoBuf之前，Google 已經存在了一種 request/response 格式，用於手動處理 request/response 的編解碼。它也能支援多版本協議，不過程式碼不夠優雅：
if (protocolVersion=1) {
doSomething();
} else if (protocolVersion=2) {
doOtherThing();
} ...
如果是非常明確的格式化協議，會使新協議變得非常複雜。因為開發人員必須確保請求發起者與處理請求的實際伺服器之間的所有伺服器都能理解新協議，然後才能切換開關以開始使用新協議。
這也就是每個伺服器開發人員都遇到過的低版本相容、新舊協議相容相關的問題。
為了解決這些問題，於是ProtoBuf就誕生了。
ProtoBuf 最初被寄予以下 2 個特點：
- 更容易引入新的欄位，並且不需要檢查資料的中間伺服器可以簡單地解析並傳遞資料，而無需瞭解所有欄位。
- 資料格式更加具有自我描述性，可以用各種語言來處理(C++, Java 等各種語言)。
這個版本的 ProtoBuf 仍需要自己手寫解析的程式碼。
不過隨著系統慢慢發展，演進，ProtoBuf具有了更多的特性：
- 自動生成的序列化和反序列化程式碼避免了手動解析的需要。（官方提供自動生成程式碼工具，各個語言平臺的基本都有）。
- 除了用於資料交換之外，ProtoBuf被用作持久化資料的便捷自描述格式。
ProtoBuf 現在是 Google 用於資料交換和儲存的通用語言。谷歌程式碼樹中定義了 48162 種不同的訊息型別，包括 12183 個 .proto 檔案。它們既用於 RPC 系統，也用於在各種儲存系統中持久儲存資料。
ProtoBuf 誕生之初是為了解決伺服器端新舊協議(高低版本)相容性問題，名字也很體貼，“協議緩衝區”。只不過後期慢慢發展成用於傳輸資料。
Protocol Buffers 命名由來：
Why the name "Protocol Buffers"?
The name originates from the early days of the format, before we had the protocol buffer compiler to generate classes for us. At the time, there was a class called ProtocolBuffer which actually acted as a buffer for an individual method. Users would add tag/value pairs to this buffer individually by calling methods like AddValue(tag, value). The raw bytes were stored in a buffer which could then be written out once the message had been constructed.
Since that time, the "buffers" part of the name has lost its meaning, but it is still the name we use. Today, people usually use the term "protocol message" to refer to a message in an abstract sense, "protocol buffer" to refer to a serialized copy of a message, and "protocol message object" to refer to an in-memory object representing the parsed message.
三、如何使用 ProtoBuf
3.1 ProtoBuf 協議的工作流程
可以看到，對於序列化協議來說，使用方只需要關注業務物件本身，即 idl 定義，序列化和反序列化的程式碼只需要通過工具生成即可。
3.2 ProtoBuf 訊息定義
ProtoBuf 的訊息是在idl檔案(.proto)中描述的。下面是本次樣例中使用到的訊息描述符customer.proto：
syntax = "proto3";
package domain;
option java_package = "com.protobuf.generated.domain";
option java_outer_classname = "CustomerProtos";
message Customers {
repeated Customer customer = 1;
}
message Customer {
int32 id = 1;
string firstName = 2;
string lastName = 3;
enum EmailType {
PRIVATE = 0;
PROFESSIONAL = 1;
}
message EmailAddress {
string email = 1;
EmailType type = 2;
}
repeated EmailAddress email = 5;
}
上面的訊息比較簡單，Customers包含多個Customer，Customer包含一個id欄位，一個firstName欄位，一個lastName欄位以及一個email的集合。
除了這些定義外，檔案頂部還有三行可幫助程式碼生成器：
- 首先，syntax = "proto3"用於idl語法版本，目前有兩個版本proto2和proto3，兩個版本語法不相容，如果不指定，預設語法是proto2。由於proto3比proto2支援的語言更多，語法更簡潔，本文使用的是proto3。
- 其次有一個package domain;定義。此配置用於巢狀生成的類/物件。
- 有一個option java_package定義。生成器還使用此配置來巢狀生成的源。此處的區別在於這僅適用於Java。在使用Java建立程式碼和使用JavaScript建立程式碼時，使用了兩種配置來使生成器的行為有所不同。也就是說，Java類是在包com.protobuf.generated.domain下建立的，而JavaScript物件是在包domain下建立的。
ProtoBuf 提供了更多選項和資料型別，本文不做詳細介紹，感興趣可以參考這裡。
3.3 程式碼生成
首先安裝 ProtoBuf 編譯器 protoc，這裡有詳細的安裝教程，安裝完成後，可以使用以下命令生成 Java 原始碼：
protoc --java_out=./src/main/java ./src/main/idl/customer.proto
從專案的根路徑執行該命令，並新增了兩個引數：java_out，定義./src/main/java/為Java程式碼的輸出目錄；而./src/main/idl/customer.proto是.proto檔案所在目錄。
生成的程式碼非常複雜，但是幸運的是它的用法卻非常簡單。
CustomerProtos.Customer.EmailAddress email = CustomerProtos.Customer.EmailAddress.newBuilder()
.setType(CustomerProtos.Customer.EmailType.PROFESSIONAL)
.setEmail("crichardson@email.com").build();
CustomerProtos.Customer customer = CustomerProtos.Customer.newBuilder()
.setId(1)
.setFirstName("Lee")
.setLastName("Richardson")
.addEmail(email)
.build();
// 序列化
byte[] binaryInfo = customer.toByteArray();
System.out.println(bytes_String16(binaryInfo));
System.out.println(customer.toByteArray().length);
// 反序列化
CustomerProtos.Customer anotherCustomer = CustomerProtos.Customer.parseFrom(binaryInfo);
System.out.println(anotherCustomer.toString());
3.4 效能資料
我們簡單地以Customers為模型，分別構造、選取小物件、普通物件、大物件進行效能對比。
序列化耗時以及序列化後資料大小對比
反序列化耗時
更多效能資料可以參考官方 Benchmark
四、總結
上面介紹了 ProtoBuf 是什麼、產生的背景、基本用法，我們再總結下。
優點：
1. 效率高
從序列化後的資料體積角度，與XML、JSON這類文字協議相比，ProtoBuf通過T-(L)-V（TAG-LENGTH-VALUE）方式編碼，不需要", {, }, :等分隔符來結構化資訊，同時在編碼層面使用varint壓縮，所以描述同樣的資訊，ProtoBuf序列化後的體積要小很多，在網路中傳輸消耗的網路流量更少，進而對於網路資源緊張、效能要求非常高的場景，ProtoBuf協議是不錯的選擇。
// 我們簡單做個對比 // 要描述如下JSON資料 {"id":1,"firstName":"Chris","lastName":"Richardson","email":[{"type":"PROFESSIONAL","email":"crichardson@email.com"}]} # 使用JSON序列化後的資料大小為118byte 7b226964223a312c2266697273744e616d65223a224368726973222c226c6173744e616d65223a2252696368617264736f6e222c22656d61696c223a5b7b22747970
65223a2250524f46455353494f4e414c222c22656d61696c223a226372696368617264736f6e40656d61696c2e636f6d227d5d7d # 而使用ProtoBuf序列化後的資料大小為48byte 0801120543687269731a0a52696368617264736f6e2a190a156372696368617264736f6e40656d61696c2e636f6d1001從序列化/反序列化速度角度，與XML、JSON相比，ProtoBuf序列化/反序列化的速度更快，比XML要快20-100倍。
2. 支援跨平臺、多語言
ProtoBuf是平臺無關的，無論是Android與PC，還是C#與Java都可以利用ProtoBuf進行無障礙通訊。
proto3支援C++, Java, Python, Go, Ruby, Objective-C, C#。
3. 擴充套件性、相容性好
具有向後相容的特性，更新資料結構以後，老版本依舊可以相容，這也是ProtoBuf誕生之初被寄予解決的問題。因為編譯器對不識別的新增欄位會跳過不處理。
4. 使用簡單
ProtoBuf 提供了一套編譯工具，可以自動生成序列化、反序列化的樣板程式碼，這樣開發者只要關注業務資料idl，簡化了編碼解碼工作以及多語言互動的複雜度。
缺點：
可讀性差，缺乏自描述
XML，JSON是自描述的，而ProtoBuf則不是。
ProtoBuf是二進位制協議，編碼後的資料可讀性差，如果沒有idl檔案，就無法理解二進位制資料流，對除錯不友好。
不過Charles已經支援ProtoBuf協議，匯入資料的描述檔案即可，詳情可參考Charles Protocol Buffers
此外，由於沒有idl檔案無法解析二進位制資料流，ProtoBuf在一定程度上可以保護資料，提升核心資料被破解的門檻，降低核心資料被盜爬的風險。
五、參考
作者： Li Guanyun