IM通訊協議專題學習(二)：快速理解Protobuf的背景、原理、使用、優缺點

Posted on 2022-11-17 10:52 Jack Jiang 閱讀(92) 評論(0) 編輯收藏

本文由vivo技術團隊Li Guanyun分享，為了提升閱讀體驗，行了較多修訂和重新排版。

1、引言

Protobuf 作為一種跨平臺、語言無關、可擴展的序列化結構數據通訊協議，已廣泛應用于網絡數據交換的場景中（比如IM通信、分布式RPC調用等）。

隨著互聯網的發展，分布式系統的異構性會愈發突出，跨語言的需求會愈加明顯，同時 gRPC 也大有取代Restful之勢，而 Protobuf 作為gRPC 跨語言、高性能的法寶，我們技術人有必要深入理解 Protobuf 原理，為以后的技術更新和選型打下基礎。

借此機會，我將個人的Protobuf學習過程以及實踐經驗，總結成文，與大家一起探討學習。本篇主要從Protobuf的基礎概念開始，包括技術背景、技術原理、使用方法和優缺點。

PS：本篇本跟上篇《Protobuf從入門到精通，一篇就夠！》類似，都適合作為Protobuf的入門文章，但本篇力求簡潔，盡量不涉及Protobuf的具體技術細節，目的是降低閱讀的門檻、提升閱讀效果，希望對你有用。

學習交流：

- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）

（本文已同步發布于：http://www.52im.net/thread-4081-1-1.html）

2、系列文章

本文是系列文章中的第 2 篇，本系列總目錄如下：

《IM通訊協議專題學習(一)：Protobuf從入門到精通，一篇就夠！》
《IM通訊協議專題學習(二)：快速理解Protobuf的背景、原理、使用、優缺點》（* 本文）
《IM通訊協議專題學習(三)：由淺入深，從通信編解碼原理上理解Protobuf》（稍后發布..）
《IM通訊協議專題學習(四)：從Base64到Protobuf，詳解Protobuf的數據編碼原理》（稍后發布..）
《IM通訊協議專題學習(五)：Protobuf到底比JSON快幾倍？請看全方位實測！》（稍后發布..）
《IM通訊協議專題學習(六)：手把手教你如何在Android上從零使用Protobuf》（稍后發布..）
《IM通訊協議專題學習(七)：手把手教你如何在NodeJS中從零使用Protobuf》（稍后發布..）
《IM通訊協議專題學習(八)：金蝶隨手記團隊的Protobuf應用實踐(原理篇) 》（稍后發布..）
《IM通訊協議專題學習(九)：金蝶隨手記團隊的Protobuf應用實踐(實戰篇) 》（稍后發布..）

3、什么是Protobuf？

Protobuf（全稱是Protocol Buffers）是一種跨平臺、語言無關、可擴展的序列化結構數據的方法，可用于網絡通信數據交換及存儲。

在序列化結構化數據的機制中，Protobuf是靈活、高效、自動化的，相對常見的XML、JSON，描述同樣的信息，Protobuf序列化后數據量更小、序列化/反序列化速度更快、更簡單。

一旦定義了要處理的數據的數據結構之后，就可以利用Protobuf的代碼生成工具生成相關的代碼。只需使用 Protobuf 對數據結構進行一次描述，即可利用各種不同語言（proto3支持C++, Java, Python, Go, Ruby, Objective-C, C#）或從各種不同流中對你的結構化數據輕松讀寫。

PS：類似的介紹，在上篇《Protobuf從入門到精通，一篇就夠！》中也有涉及，有興趣可以一并閱讀之。

4、為什么是 Protobuf？

4.1 技術背景

大家可能會覺得 Google 發明 Protobuf 是為了解決序列化速度的，其實真實的原因并不是這樣的。

Protobuf最先開始是 Google用來解決索引服務器 request/response 協議的。

在沒有Protobuf之前，Google 已經存在了一種 request/response 格式，用于手動處理 request/response 的編解碼。

這種sstk式也能支持多版本協議，不過代碼不夠優雅：

if(protocolVersion=1) {
doSomething();
} elseif(protocolVersion=2) {
doOtherThing();
} ...

如果是非常明確的格式化協議，會使新協議變得非常復雜。因為開發人員必須確保請求發起者與處理請求的實際服務器之間的所有服務器都能理解新協議，然后才能切換開關以開始使用新協議。

這也就是每個服務器開發人員都遇到過的低版本兼容、新舊協議兼容相關的問題。

為了解決這些問題，于是Protobuf就誕生了。

4.2 Protobuf 誕生了

Protobuf 最初被寄予以下 2 個期望：

1）更容易引入新的字段，并且不需要檢查數據的中間服務器可以簡單地解析并傳遞數據（而無需了解所有字段）；
2）數據格式更加具有自我描述性，可以用各種語言來處理（比如C++, Java 等各種語言）。

但這個版本的 Protobuf 仍需要自己手寫解析的代碼。

隨著Protobuf的發展、演進，它具有了更多的特性：

1）自動生成的序列化和反序列化代碼（避免了手動解析的需要。官方提供自動生成代碼工具，各個語言平臺的基本都有）；
2）除了用于數據交換之外，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.

4.3 Protobuf 在谷歌業務中的地位

Protobuf 現在是 Google 用于數據交換和存儲的通用語言。

谷歌代碼樹中定義了 48162 種不同的消息類型，包括 12183 個 .proto 文件。它們既用于 RPC 系統，也用于在各種存儲系統中持久存儲數據。

Protobuf 誕生之初是為了解決服務器端新舊協議（高低版本）兼容性問題，名字也很體貼——“協議緩沖區”，只不過后期慢慢發展成用于傳輸數據。

5、Protobuf 協議的工作原理

如下圖所示：可以看到，對于序列化協議來說，使用方只需要關注業務對象本身，即 idl 定義，序列化和反序列化的代碼只需要通過工具生成即可。

6、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的集合）。

除了上述定義外，文件頂部還有三行可幫助代碼生成器的申明：

1）syntax = "proto3"：用于idl語法版本，目前有兩個版本proto2和proto3，兩個版本語法不兼容，如果不指定，默認語法是proto2（由于proto3比proto2支持的語言更多，語法更簡潔，本文使用的是proto3）；
2）package domain：此配置用于嵌套生成的類/對象；
3）option java_package：生成器還使用此配置來嵌套生成的源（此處的區別在于這僅適用于Java，在使用Java創建代碼和使用JavaScript創建代碼時，使用了兩種配置來使生成器的行為有所不同。也就是說，Java類是在包com.Protobuf.generated.domain下創建的，而JavaScript對象是在包domain下創建的）。

Protobuf 提供了更多選項和數據類型，本文不做詳細介紹，感興趣可以參考官方文檔。

7、Protobuf 的代碼生成

首先安裝 Protobuf 編譯器 protoc（點這里有詳細的安裝教程）。

安裝完成后，可以使用以下命令生成 Java 源代碼：

1protoc --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());

8、Protobuf 的性能數據

我們簡單地以上述Customers為模型，分別構造、選取小對象、普通對象、大對象進行性能對比。

序列化耗時以及序列化后數據大小對比：

反序列化耗時：

更多性能數據可以參考官方的測試Benchmark。

9、Protobuf 的優點

9.1效率高

從序列化后的數據體積角度，與XML、JSON這類文本協議相比，Protobuf通過 T-(L)-V（TAG-LENGTH-VALUE）方式編碼，不需要", {, }, :等分隔符來結構化信息。同時在編碼層面使用varint壓縮。

所以描述同樣的信息，Protobuf序列化后的體積要小很多，在網絡中傳輸消耗的網絡流量更少，進而對于網絡資源緊張、性能要求非常高的場景。比如在移動網絡下的IM即時通訊應用中，Protobuf協議就是非常不錯的選擇（PS：這也是我為什么著手分享Protobuf系列文章的原因啦）。

我們來簡單做個對比。

要描述如下JSON數據：

1{"id":1,"firstName":"Chris","lastName":"Richardson","email":[{"type":"PROFESSIONAL","email":"crichardson@email.com"}]}

使用JSON序列化后的數據大小為118byte：

7b226964223a312c2266697273744e616d65223a224368726973222c226c6173744e616d65223a2252696368617264736f6e222c22656d61696c223a5b7b2274797065223a2250524f46455353494f4e414c222c22656d61696c223a226372696368617264736f6e40656d61696c2e636f6d227d5d7d

而使用Protobuf序列化后的數據大小為48byte：