一. protocol buffers 是什么?

Protocol buffers 是一種語(yǔ)言中立，平臺(tái)無(wú)關(guān)，可擴(kuò)展的序列化數(shù)據(jù)的格式，可用于通信協(xié)議，數(shù)據(jù)存儲(chǔ)等。

Protocol buffers 在序列化數(shù)據(jù)方面，它是靈活的，高效的。相比于 XML 來(lái)說(shuō)，Protocol buffers 更加小巧，更加快速，更加簡(jiǎn)單。一旦定義了要處理的數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)之后，就可以利用 Protocol buffers 的代碼生成工具生成相關(guān)的代碼。甚至可以在無(wú)需重新部署程序的情況下更新數(shù)據(jù)結(jié)構(gòu)。只需使用 Protobuf 對(duì)數(shù)據(jù)結(jié)構(gòu)進(jìn)行一次描述，即可利用各種不同語(yǔ)言或從各種不同數(shù)據(jù)流中對(duì)你的結(jié)構(gòu)化數(shù)據(jù)輕松讀寫(xiě)。

Protocol buffers 很適合做數(shù)據(jù)存儲(chǔ)或 RPC 數(shù)據(jù)交換格式?？捎糜谕ㄓ崊f(xié)議、數(shù)據(jù)存儲(chǔ)等領(lǐng)域的語(yǔ)言無(wú)關(guān)、平臺(tái)無(wú)關(guān)、可擴(kuò)展的序列化結(jié)構(gòu)數(shù)據(jù)格式 。

二. 為什么要發(fā)明 protocol buffers ?

 

大家可能會(huì)覺(jué)得 Google 發(fā)明 protocol buffers 是為了解決序列化速度的，其實(shí)真實(shí)的原因并不是這樣的。

protocol buffers ***開(kāi)始是 google 用來(lái)解決索引服務(wù)器 request/response 協(xié)議的。沒(méi)有 protocol buffers 之前，google 已經(jīng)存在了一種 request/response 格式，用于手動(dòng)處理 request/response 的編組和反編組。它也能支持多版本協(xié)議，不過(guò)代碼比較丑陋：

 

if (version == 3) { 
  ... 
} else if (version > 4) { if (version == 5) { 
    ... 
  } 
  ... 
} 

如果非常明確的格式化協(xié)議，會(huì)使新協(xié)議變得非常復(fù)雜。因?yàn)殚_(kāi)發(fā)人員必須確保請(qǐng)求發(fā)起者與處理請(qǐng)求的實(shí)際服務(wù)器之間的所有服務(wù)器都能理解新協(xié)議，然后才能切換開(kāi)關(guān)以開(kāi)始使用新協(xié)議。

這也就是每個(gè)服務(wù)器開(kāi)發(fā)人員都遇到過(guò)的低版本兼容、新舊協(xié)議兼容相關(guān)的問(wèn)題。

protocol buffers 為了解決這些問(wèn)題，于是就誕生了。protocol buffers 被寄予一下 2 個(gè)特點(diǎn)：

• 可以很容易地引入新的字段，并且不需要檢查數(shù)據(jù)的中間服務(wù)器可以簡(jiǎn)單地解析并傳遞數(shù)據(jù)，而無(wú)需了解所有字段。
• 數(shù)據(jù)格式更加具有自我描述性，可以用各種語(yǔ)言來(lái)處理(C++, Java 等各種語(yǔ)言)
• 這個(gè)版本的 protocol buffers 仍需要自己手寫(xiě)解析的代碼。
• 不過(guò)隨著系統(tǒng)慢慢發(fā)展，演進(jìn)，protocol buffers 目前具有了更多的特性：
• 自動(dòng)生成的序列化和反序列化代碼避免了手動(dòng)解析的需要。(官方提供自動(dòng)生成代碼工具，各個(gè)語(yǔ)言平臺(tái)的基本都有)
• 除了用于 RPC(遠(yuǎn)程過(guò)程調(diào)用)請(qǐng)求之外，人們開(kāi)始將 protocol buffers 用作持久存儲(chǔ)數(shù)據(jù)的便捷自描述格式(例如，在Bigtable中)。
• 服務(wù)器的 RPC 接口可以先聲明為協(xié)議的一部分，然后用 protocol compiler 生成基類，用戶可以使用服務(wù)器接口的實(shí)際實(shí)現(xiàn)來(lái)覆蓋它們。

protocol buffers 現(xiàn)在是 Google 用于數(shù)據(jù)的通用語(yǔ)言。在撰寫(xiě)本文時(shí)，谷歌代碼樹(shù)中定義了 48162 種不同的消息類型，包括 12183 個(gè) .proto 文件。它們既用于 RPC 系統(tǒng)，也用于在各種存儲(chǔ)系統(tǒng)中持久存儲(chǔ)數(shù)據(jù)。

小結(jié)：

protocol buffers 誕生之初是為了解決服務(wù)器端新舊協(xié)議(高低版本)兼容性問(wèn)題，名字也很體貼，“協(xié)議緩沖區(qū)”。只不過(guò)后期慢慢發(fā)展成用于傳輸數(shù)據(jù) 。

Protocol Buffers 命名由來(lái)：

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.

這個(gè)名字起源于 format 早期，在我們有 protocol buffer 編譯器為我們生成類之前。當(dāng)時(shí)，有一個(gè)名為 ProtocolBuffer 的類，它實(shí)際上充當(dāng)了單個(gè)方法的緩沖區(qū)。用戶可以通過(guò)調(diào)用像 AddValue(tag,value) 這樣的方法分別將標(biāo)簽/值對(duì)添加到此緩沖區(qū)。原始字節(jié)存儲(chǔ)在一個(gè)緩沖區(qū)中，一旦構(gòu)建消息就可以將其寫(xiě)出。

從那時(shí)起，名為“緩沖”的部分已經(jīng)失去了意義，但它仍然是我們使用的名稱。今天，人們通常使用術(shù)語(yǔ)“protocol message”來(lái)指代抽象意義上的消息，“protocol buffer”指的是消息的序列化副本，而“protocol message object”指的是代表內(nèi)存中對(duì)象解析的消息。

三. proto3 定義 message

 

目前 protocol buffers ***版本是 proto3，與老的版本 proto2 還是有些區(qū)別的。這兩個(gè)版本的 API 不完全兼容。

proto2 和 proto3 的名字看起來(lái)有點(diǎn)撲朔迷離，那是因?yàn)楫?dāng)我們最初開(kāi)源的 protocol buffers 時(shí)，它實(shí)際上是 Google 的第二個(gè)版本了，所以被稱為 proto2，這也是我們的開(kāi)源版本號(hào)從 v2 開(kāi)始的原因。初始版名為 proto1，從 2001 年初開(kāi)始在谷歌開(kāi)發(fā)的。

在 proto 中，所有結(jié)構(gòu)化的數(shù)據(jù)都被稱為 message。

 

message helloworld  
{  
   required int32     id = 1; // ID  required string    str = 2; // str  optional int32     opt = 3; //optional field  } 

上面這幾行語(yǔ)句，定義了一個(gè)消息 helloworld，該消息有三個(gè)成員，類型為 int32 的 id，另一個(gè)為類型為 string 的成員 str。opt 是一個(gè)可選的成員，即消息中可以不包含該成員。

接下來(lái)說(shuō)明一些 proto3 中需要注意的地方。

 

syntax = "proto3"; message SearchRequest { 
  string query = 1; 
  int32 page_number = 2; 
  int32 result_per_page = 3; 
} 

如果開(kāi)頭***行不聲明 syntax = "proto3";，則默認(rèn)使用 proto2 進(jìn)行解析。

1. 分配字段編號(hào)

每個(gè)消息定義中的每個(gè)字段都有 唯一的編號(hào) 。這些字段編號(hào)用于標(biāo)識(shí)消息二進(jìn)制格式中的字段，并且在使用消息類型后不應(yīng)更改。請(qǐng)注意，范圍 1 到 15 中的字段編號(hào)需要一個(gè)字節(jié)進(jìn)行編碼，包括字段編號(hào)和字段類型(具體原因見(jiàn) Protocol Buffer 編碼原理 這一章節(jié))。范圍 16 至 2047 中的字段編號(hào)需要兩個(gè)字節(jié)。所以你應(yīng)該保留數(shù)字 1 到 15 作為非常頻繁出現(xiàn)的消息元素。請(qǐng)記住為將來(lái)可能添加的頻繁出現(xiàn)的元素留出一些空間。

可以指定的最小字段編號(hào)為1，***字段編號(hào)為2^29^-1 或 536,870,911。也不能使用數(shù)字 19000 到 19999(FieldDescriptor :: kFirstReservedNumber 到 FieldDescriptor :: kLastReservedNumber)，因?yàn)樗鼈兪菫?Protocol Buffers實(shí)現(xiàn)保留的。

如果在 .proto 中使用這些保留數(shù)字中的一個(gè)，Protocol Buffers 編譯的時(shí)候會(huì)報(bào)錯(cuò)。

同樣，您不能使用任何以前 Protocol Buffers 保留的一些字段號(hào)碼。保留字段是什么，下一節(jié)詳細(xì)說(shuō)明。

2. 保留字段

如果您通過(guò)完全刪除某個(gè)字段或?qū)⑵渥⑨尩魜?lái)更新消息類型，那么未來(lái)的用戶可以在對(duì)該類型進(jìn)行自己的更新時(shí)重新使用該字段號(hào)。如果稍后加載到了的舊版本 .proto 文件，則會(huì)導(dǎo)致服務(wù)器出現(xiàn)嚴(yán)重問(wèn)題，例如數(shù)據(jù)混亂，隱私錯(cuò)誤等等。確保這種情況不會(huì)發(fā)生的一種方法是指定刪除字段的字段編號(hào)(或名稱，這也可能會(huì)導(dǎo)致 JSON 序列化問(wèn)題)為 reserved。如果將來(lái)的任何用戶試圖使用這些字段標(biāo)識(shí)符，Protocol Buffers 編譯器將會(huì)報(bào)錯(cuò)。

 

message Foo { 
  reserved 2, 15, 9 to 11; 
  reserved "foo", "bar"; 
} 

注意，不能在同一個(gè) reserved 語(yǔ)句中混合字段名稱和字段編號(hào) 。如有需要需要像上面這個(gè)例子這樣寫(xiě)。

3. 默認(rèn)字段規(guī)則

• 字段名不能重復(fù)，必須唯一。
• repeated 字段：可以在一個(gè) message 中重復(fù)任何數(shù)字多次(包括 0 )，不過(guò)這些重復(fù)值的順序被保留。

在 proto3 中，純數(shù)字類型的 repeated 字段編碼時(shí)候默認(rèn)采用 packed 編碼(具體原因見(jiàn) Protocol Buffer 編碼原理 這一章節(jié))

4. 各個(gè)語(yǔ)言標(biāo)量類型對(duì)應(yīng)關(guān)系

 

5. 枚舉

在 message 中可以嵌入枚舉類型。

 

message SearchRequest { 
  string query = 1; 
  int32 page_number = 2; 
  int32 result_per_page = 3; enum Corpus { UNIVERSAL = 0; WEB = 1; IMAGES = 2; LOCAL = 3; NEWS = 4; PRODUCTS = 5; VIDEO = 6; 
  } 
  Corpus corpus = 4; 
} 

• 枚舉類型需要注意的是，一定要有 0 值。
• 枚舉為 0 的是作為零值，當(dāng)不賦值的時(shí)候，就會(huì)是零值。

為了和 proto2 兼容。在 proto2 中，零值必須是***個(gè)值。

另外在反序列化的過(guò)程中，無(wú)法被識(shí)別的枚舉值，將會(huì)被保留在 messaage 中。因?yàn)橄⒎葱蛄谢瘯r(shí)如何表示是依賴于語(yǔ)言的。在支持指定符號(hào)范圍之外的值的開(kāi)放枚舉類型的語(yǔ)言中，例如 C++ 和 Go，未知的枚舉值只是存儲(chǔ)為其基礎(chǔ)整數(shù)表示。在諸如 Java 之類的封閉枚舉類型的語(yǔ)言中，枚舉值會(huì)被用來(lái)標(biāo)識(shí)未識(shí)別的值，并且特殊的訪問(wèn)器可以訪問(wèn)到底層整數(shù)。

在其他情況下，如果消息被序列化，則無(wú)法識(shí)別的值仍將與消息一起序列化。

5. 枚舉中的保留值

如果您通過(guò)完全刪除枚舉條目或?qū)⑵渥⑨尩魜?lái)更新枚舉類型，未來(lái)的用戶可以在對(duì)該類型進(jìn)行自己的更新時(shí)重新使用數(shù)值。如果稍后加載到了的舊版本 .proto 文件，則會(huì)導(dǎo)致服務(wù)器出現(xiàn)嚴(yán)重問(wèn)題，例如數(shù)據(jù)混亂，隱私錯(cuò)誤等等。確保這種情況不會(huì)發(fā)生的一種方法是指定已刪除條目的數(shù)字值(或名稱，這也可能會(huì)導(dǎo)致JSON序列化問(wèn)題)為 reserved。如果將來(lái)的任何用戶試圖使用這些字段標(biāo)識(shí)符，Protocol Buffers 編譯器將會(huì)報(bào)錯(cuò)。您可以使用 max 關(guān)鍵字指定您的保留數(shù)值范圍上升到***可能值。

 

enum Foo { 
  reserved 2, 15, 9 to 11, 40 to max; 
  reserved "FOO", "BAR"; 
} 

注意，不能在同一個(gè) reserved 語(yǔ)句中混合字段名稱和字段編號(hào) 。如有需要需要像上面這個(gè)例子這樣寫(xiě)。

6. 允許嵌套

Protocol Buffers 定義 message 允許嵌套組合成更加復(fù)雜的消息。

 

message SearchResponse { repeated Result results = 1; 
} message Result { 
  string url = 1; 
  string title = 2; repeated string snippets = 3; 
} 

上面的例子中，SearchResponse 中嵌套使用了 Result 。

更多的例子：

 

message SearchResponse { message Result { 
    string url = 1; 
    string title = 2; repeated string snippets = 3; 
  } repeated Result results = 1; 
} message SomeOtherMessage { 
  SearchResponse.Result result = 1; 
} 
 
message Outer { // Level 0 message MiddleAA { // Level 1 message Inner { // Level 2 int64 ival = 1; 
      bool  booly = 2; 
    } 
  } message MiddleBB { // Level 1 message Inner { // Level 2 int32 ival = 1; 
      bool  booly = 2; 
    } 
  } 
} 

7. 枚舉不兼容性

可以導(dǎo)入 proto2 消息類型并在 proto3 消息中使用它們，反之亦然。然而，proto2 枚舉不能直接用在 proto3 語(yǔ)法中(但是如果導(dǎo)入的proto2消息使用它們，這是可以的)。

8. 更新 message

如果后面發(fā)現(xiàn)之前定義 message 需要增加字段了，這個(gè)時(shí)候就體現(xiàn)出 Protocol Buffer 的優(yōu)勢(shì)了，不需要改動(dòng)之前的代碼。不過(guò)需要滿足以下 10 條規(guī)則：

1. 不要改動(dòng)原有字段的數(shù)據(jù)結(jié)構(gòu)。
2. 如果您添加新字段，則任何由代碼使用“舊”消息格式序列化的消息仍然可以通過(guò)新生成的代碼進(jìn)行分析。您應(yīng)該記住這些元素的默認(rèn)值，以便新代碼可以正確地與舊代碼生成的消息進(jìn)行交互。同樣，由新代碼創(chuàng)建的消息可以由舊代碼解析：舊的二進(jìn)制文件在解析時(shí)會(huì)簡(jiǎn)單地忽略新字段。(具體原因見(jiàn) 未知字段 這一章節(jié))
3. 只要字段號(hào)在更新的消息類型中不再使用，字段可以被刪除。您可能需要重命名該字段，可能會(huì)添加前綴“OBSOLETE_”，或者標(biāo)記成保留字段號(hào) reserved，以便將來(lái)的 .proto 用戶不會(huì)意外重復(fù)使用該號(hào)碼。
4. int32，uint32，int64，uint64 和 bool 全都兼容。這意味著您可以將字段從這些類型之一更改為另一個(gè)字段而不破壞向前或向后兼容性。如果一個(gè)數(shù)字從不適合相應(yīng)類型的線路中解析出來(lái)，則會(huì)得到與在 C++ 中將該數(shù)字轉(zhuǎn)換為該類型相同的效果(例如，如果將 64 位數(shù)字讀為 int32，它將被截?cái)酁?32 位)。
5. sint32 和 sint64 相互兼容，但與其他整數(shù)類型不兼容。
6. 只要字節(jié)是有效的UTF-8，string 和 bytes 是兼容的。
7. 嵌入式 message 與 bytes 兼容，如果 bytes 包含 message 的 encoded version。
8. fixed32與sfixed32兼容，而fixed64與sfixed64兼容。
9. enum 就數(shù)組而言，是可以與 int32，uint32，int64 和 uint64 兼容(請(qǐng)注意，如果它們不適合，值將被截?cái)?。但是請(qǐng)注意，當(dāng)消息反序列化時(shí)，客戶端代碼可能會(huì)以不同的方式對(duì)待它們：例如，未識(shí)別的 proto3 枚舉類型將保留在消息中，但消息反序列化時(shí)如何表示是與語(yǔ)言相關(guān)的。(這點(diǎn)和語(yǔ)言相關(guān)，上面提到過(guò)了)Int 域始終只保留它們的值。
10. 將單個(gè) 值 更改為新的成員是安全和二進(jìn)制兼容的。如果您確定一次沒(méi)有代碼設(shè)置多個(gè) 字段 ，則將多個(gè)字段移至新的字段可能是安全的。將任何 字段 移到現(xiàn)有字段中都是不安全的。(注意字段和值的區(qū)別，字段是 field，值是 value)

9. 未知字段

未知數(shù)字段是 protocol buffers 序列化的數(shù)據(jù)，表示解析器無(wú)法識(shí)別的字段。例如，當(dāng)一個(gè)舊的二進(jìn)制文件解析由新的二進(jìn)制文件發(fā)送的新數(shù)據(jù)的數(shù)據(jù)時(shí)，這些新的字段將成為舊的二進(jìn)制文件中的未知字段。

Proto3 實(shí)現(xiàn)可以成功解析未知字段的消息，但是，實(shí)現(xiàn)可能會(huì)或可能不會(huì)支持保留這些未知字段。你不應(yīng)該依賴保存或刪除未知域。對(duì)于大多數(shù) Google protocol buffers 實(shí)現(xiàn)，未知字段在 proto3 中無(wú)法通過(guò)相應(yīng)的 proto 運(yùn)行時(shí)訪問(wèn)，并且在反序列化時(shí)被丟棄和遺忘。這是與 proto2 的不同行為，其中未知字段總是與消息一起保存并序列化。

10. Map 類型

repeated 類型可以用來(lái)表示數(shù)組，Map 類型則可以用來(lái)表示字典。

 

map  
map_field = N;  
map  
projects = 3; 

key_type 可以是任何 int 或者 string 類型(任何的標(biāo)量類型，具體可以見(jiàn)上面標(biāo)量類型對(duì)應(yīng)表格，但是要除去 float、double 和 bytes)

枚舉值也不能作為 key 。

key_type 可以是除去 map 以外的任何類型。

需要特別注意的是 ：

• map 是不能用 repeated 修飾的。
• 線性數(shù)組和 map 迭代順序的是不確定的，所以你不能依靠你的 map 是在一個(gè)特定的順序。
• 為 .proto 生成文本格式時(shí)，map 按 key 排序。數(shù)字的 key 按數(shù)字排序。
• 從數(shù)組中解析或合并時(shí)，如果有重復(fù)的 key，則使用所看到的***一個(gè) key(覆蓋原則)。從文本格式解析映射時(shí)，如果有重復(fù)的 key，解析可能會(huì)失敗。

Protocol Buffer 雖然不支持 map 類型的數(shù)組，但是可以轉(zhuǎn)換一下，用以下思路實(shí)現(xiàn) maps 數(shù)組：

 

message MapFieldEntry { 
  key_type key = 1; 
  value_type value = 2; 
} 
 
repeated MapFieldEntry map_field = N; 

上述寫(xiě)法和 map 數(shù)組是完全等價(jià)的，所以用 repeated 巧妙的實(shí)現(xiàn)了 maps 數(shù)組的需求。

11. JSON Mapping

Proto3 支持 JSON 中的規(guī)范編碼，使系統(tǒng)之間共享數(shù)據(jù)變得更加容易。編碼在下表中按類型逐個(gè)描述。

如果 JSON 編碼數(shù)據(jù)中缺少值或其值為空，則在解析為 protocol buffer 時(shí)，它將被解釋為適當(dāng)?shù)哪J(rèn)值。如果一個(gè)字段在協(xié)議緩沖區(qū)中具有默認(rèn)值，默認(rèn)情況下它將在 JSON 編碼數(shù)據(jù)中省略以節(jié)省空間。具體 Mapping 的實(shí)現(xiàn)可以提供選項(xiàng)決定是否在 JSON 編碼的輸出中發(fā)送具有默認(rèn)值的字段。

 

proto3 的 JSON 實(shí)現(xiàn)中提供了以下 4 中 options:

• 使用默認(rèn)值發(fā)送字段：在默認(rèn)情況下，默認(rèn)值的字段在 proto3 JSON 輸出中被忽略。一個(gè)實(shí)現(xiàn)可以提供一個(gè)選項(xiàng)來(lái)覆蓋這個(gè)行為，并使用它們的默認(rèn)值輸出字段。
• 忽略未知字段：默認(rèn)情況下，Proto3 JSON 解析器應(yīng)拒絕未知字段，但可能提供一個(gè)選項(xiàng)來(lái)忽略解析中的未知字段。
• 使用 proto 字段名稱而不是 lowerCamelCase 名稱：默認(rèn)情況下，proto3 JSON 的 printer 將字段名稱轉(zhuǎn)換為 lowerCamelCase 并將其用作 JSON 名稱。實(shí)現(xiàn)可能會(huì)提供一個(gè)選項(xiàng)，將原始字段名稱用作 JSON 名稱。 Proto3 JSON 解析器需要接受轉(zhuǎn)換后的 lowerCamelCase 名稱和原始字段名稱。
• 發(fā)送枚舉形式的枚舉值而不是字符串：在 JSON 輸出中默認(rèn)使用枚舉值的名稱?？梢蕴峁┮粋€(gè)選項(xiàng)來(lái)使用枚舉值的數(shù)值。

四. proto3 定義 Services

如果要使用 RPC(遠(yuǎn)程過(guò)程調(diào)用)系統(tǒng)的消息類型，可以在 .proto 文件中定義 RPC 服務(wù)接口，protocol buffer 編譯器將使用所選語(yǔ)言生成服務(wù)接口代碼和 stubs。所以，例如，如果你定義一個(gè) RPC 服務(wù)，入?yún)⑹?SearchRequest 返回值是 SearchResponse，你可以在你的 .proto 文件中定義它，如下所示：

 

service SearchService { rpc Search (SearchRequest) returns (SearchResponse); 
} 

與 protocol buffer 一起使用的最直接的 RPC 系統(tǒng)是 gRPC：在谷歌開(kāi)發(fā)的語(yǔ)言和平臺(tái)中立的開(kāi)源 RPC 系統(tǒng)。gRPC 在 protocol buffer 中工作得非常好，并且允許你通過(guò)使用特殊的 protocol buffer 編譯插件，直接從 .proto 文件中生成 RPC 相關(guān)的代碼。

如果你不想使用 gRPC，也可以在你自己的 RPC 實(shí)現(xiàn)中使用 protocol buffers。您可以在 Proto2 語(yǔ)言指南中找到更多關(guān)于這些相關(guān)的信息。

還有一些正在進(jìn)行的第三方項(xiàng)目為 Protocol Buffers 開(kāi)發(fā) RPC 實(shí)現(xiàn)。

五. Protocol Buffer 命名規(guī)范

message 采用駝峰命名法。message 首字母大寫(xiě)開(kāi)頭。字段名采用下劃線分隔法命名。

 

message SongServerRequest { required string song_name = 1; 
} 

枚舉類型采用駝峰命名法。枚舉類型首字母大寫(xiě)開(kāi)頭。每個(gè)枚舉值全部大寫(xiě)，并且采用下劃線分隔法命名。

 

enum Foo { FIRST_VALUE = 0; SECOND_VALUE = 1; 
} 

每個(gè)枚舉值用分號(hào)結(jié)束，不是逗號(hào) 。

服務(wù)名和方法名都采用駝峰命名法。并且首字母都大寫(xiě)開(kāi)頭。

 

service FooService { 
  rpc GetSomething(FooRequest) returns (FooResponse); 
} 

六. Protocol Buffer 編碼原理

在討論 Protocol Buffer 編碼原理之前，必須先談?wù)?Varints 編碼。

Base 128 Varints 編碼

Varint 是一種緊湊的表示數(shù)字的方法。它用一個(gè)或多個(gè)字節(jié)來(lái)表示一個(gè)數(shù)字，值越小的數(shù)字使用越少的字節(jié)數(shù)。這能減少用來(lái)表示數(shù)字的字節(jié)數(shù)。

Varint 中的每個(gè)字節(jié)(***一個(gè)字節(jié)除外)都設(shè)置了***有效位(msb)，這一位表示還會(huì)有更多字節(jié)出現(xiàn)。每個(gè)字節(jié)的低 7 位用于以 7 位組的形式存儲(chǔ)數(shù)字的二進(jìn)制補(bǔ)碼表示，***有效組首位。

如果用不到 1 個(gè)字節(jié)，那么***有效位設(shè)為 0 ，如下面這個(gè)例子，1 用一個(gè)字節(jié)就可以表示，所以 msb 為 0.

如果需要多個(gè)字節(jié)表示，msb 就應(yīng)該設(shè)置為 1 。例如 300，如果用 Varint 表示的話：

如果按照正常的二進(jìn)制計(jì)算的話，這個(gè)表示的是 88068(65536 + 16384 + 4096 + 2048 + 4)。

那 Varint 是怎么編碼的呢?

下面代碼是 Varint int 32 的編碼計(jì)算方法。

 

char* EncodeVarint32(char* dst, uint32_t v) { // Operate on characters as unsigneds unsigned char* ptr = reinterpret_cast  
(dst); static const int B = 128; if (v < (1<<7)) {  
*(ptr++) = v;  
} else if (v < (1<<14)) {  
*(ptr++) = v | B;  
*(ptr++) = v>>7;  
} else if (v < (1<<21)) {  
*(ptr++) = v | B;  
*(ptr++) = (v>>7) | B;  
*(ptr++) = v>>14;  
} else if (v < (1<<28)) {  
*(ptr++) = v | B;  
*(ptr++) = (v>>7) | B;  
*(ptr++) = (v>>14) | B;  
*(ptr++) = v>>21;  
} else {  
*(ptr++) = v | B;  
*(ptr++) = (v>>7) | B;  
*(ptr++) = (v>>14) | B;  
*(ptr++) = (v>>21) | B;  
*(ptr++) = v>>28;  
} return reinterpret_cast  
(ptr);  
}  
300 = 100101100 

由于 300 超過(guò)了 7 位(Varint 一個(gè)字節(jié)只有 7 位能用來(lái)表示數(shù)字，***位 msb 用來(lái)表示后面是否有更多字節(jié))，所以 300 需要用 2 個(gè)字節(jié)來(lái)表示。

Varint 的編碼，以 300 舉例：

100101100 | 10000000 = 1 1010 1100 2. 110101100 >> 7 = 1010 1100 3. 100101100 >> 7 = 10 = 0000 0010 4. 1010 1100 0000 0010 (最終 Varint 結(jié)果) 

Varint 的解碼算法應(yīng)該是這樣的：(實(shí)際就是編碼的逆過(guò)程)

如果是多個(gè)字節(jié)，先去掉每個(gè)字節(jié)的 msb(通過(guò)邏輯或運(yùn)算)，每個(gè)字節(jié)只留下 7 位。

逆序整個(gè)結(jié)果，最多是 5 個(gè)字節(jié)，排序是 1-2-3-4-5，逆序之后就是 5-4-3-2-1，字節(jié)內(nèi)部的二進(jìn)制位的順序不變，變的是字節(jié)的相對(duì)位置。

解碼過(guò)程調(diào)用 GetVarint32Ptr 函數(shù)，如果是大于一個(gè)字節(jié)的情況，會(huì)調(diào)用 GetVarint32PtrFallback 來(lái)處理。

 

inline const char* GetVarint32Ptr(const char* p, const char* limit, uint32_t* value) { if (p < limit) { uint32_t result = *(reinterpret_cast  
(p)); if ((result & 128) == 0) {  
*value = result; return p + 1;  
}  
} return GetVarint32PtrFallback(p, limit, value);  
} const char* GetVarint32PtrFallback(const char* p, const char* limit, uint32_t* value) { uint32_t result = 0; for (uint32_t shift = 0; shift <= 28 && p < limit; shift += 7) { uint32_t byte = *(reinterpret_cast 
(p));  
p++; if (byte & 128) { // More bytes are present result |= ((byte & 127) << shift);  
} else {  
result |= (byte << shift);  
*value = result; return reinterpret_cast  
(p);  
}  
} return NULL;  
} 

至此，Varint 處理過(guò)程讀者應(yīng)該都熟悉了。上面列舉出了 Varint 32 的算法，64 位的同理，只不過(guò)不再用 10 個(gè)分支來(lái)寫(xiě)代碼了，太丑了。(32位 是 5 個(gè) 字節(jié)，64位 是 10 個(gè)字節(jié))

64 位 Varint 編碼實(shí)現(xiàn)：

 

char* EncodeVarint64(char* dst, uint64_t v) { static const int B = 128; unsigned char* ptr = reinterpret_cast  
(dst); while (v >= B) {  
*(ptr++) = (v & (B-1)) | B;  
v >>= 7;  
}  
*(ptr++) = static_cast  
(v); return reinterpret_cast  
(ptr);  
} 

原理不變，只不過(guò)用循環(huán)來(lái)解決了。

64 位 Varint 解碼實(shí)現(xiàn)：

 

const char* GetVarint64Ptr(const char* p, const char* limit, uint64_t* value) { uint64_t result = 0; for (uint32_t shift = 0; shift <= 63 && p < limit; shift += 7) { uint64_t byte = *(reinterpret_cast  
  (p));       
    p++; if (byte & 128) { // More bytes are present result |= ((byte & 127) << shift); 
    } else { 
      result |= (byte << shift); 
      *value = result; return reinterpret_cast 
   (p); 
    }       
  } return NULL;     
} 

讀到這里可能有讀者會(huì)問(wèn)了，Varint 不是為了緊湊 int 的么?那 300 本來(lái)可以用一個(gè)字節(jié)表示，現(xiàn)在變成 2 個(gè)字節(jié)了，哪里緊湊了，花費(fèi)的空間反而變多了?!

Varint 確實(shí)是一種緊湊的表示數(shù)字的方法。它用一個(gè)或多個(gè)字節(jié)來(lái)表示一個(gè)數(shù)字，值越小的數(shù)字使用越少的字節(jié)數(shù)。這能減少用來(lái)表示數(shù)字的字節(jié)數(shù)。比如對(duì)于 int32 類型的數(shù)字，一般需要 4 個(gè) byte 來(lái)表示。但是采用 Varint，對(duì)于很小的 int32 類型的數(shù)字，則可以用 1 個(gè) byte 來(lái)表示。當(dāng)然凡事都有好的也有不好的一面，采用 Varint 表示法，大的數(shù)字則需要 5 個(gè) byte 來(lái)表示。從統(tǒng)計(jì)的角度來(lái)說(shuō)，一般不會(huì)所有的消息中的數(shù)字都是大數(shù)，因此大多數(shù)情況下，采用 Varint 后，可以用更少的字節(jié)數(shù)來(lái)表示數(shù)字信息。

300 如果用 int32 表示，需要 4 個(gè)字節(jié)，現(xiàn)在用 Varint 表示，只需要 2 個(gè)字節(jié)了?？s小了一半!

1. Message Structure 編碼

protocol buffer 中 message 是一系列鍵值對(duì)。message 的二進(jìn)制版本只是使用字段號(hào)(field's number 和 wire_type)作為 key。每個(gè)字段的名稱和聲明類型只能在解碼端通過(guò)引用消息類型的定義(即 .proto 文件)來(lái)確定。這一點(diǎn)也是人們常常說(shuō)的 protocol buffer 比 JSON，XML 安全一點(diǎn)的原因，如果沒(méi)有數(shù)據(jù)結(jié)構(gòu)描述 .proto 文件，拿到數(shù)據(jù)以后是無(wú)法解釋成正常的數(shù)據(jù)的。

 

由于采用了 tag-value 的形式，所以 option 的 field 如果有，就存在在這個(gè) message buffer 中，如果沒(méi)有，就不會(huì)在這里，這一點(diǎn)也算是壓縮了 message 的大小了。

當(dāng)消息編碼時(shí)，鍵和值被連接成一個(gè)字節(jié)流。當(dāng)消息被解碼時(shí)，解析器需要能夠跳過(guò)它無(wú)法識(shí)別的字段。這樣，可以將新字段添加到消息中，而不會(huì)破壞不知道它們的舊程序。這就是所謂的 “向后”兼容性。

為此，線性的格式消息中每對(duì)的“key”實(shí)際上是兩個(gè)值，其中一個(gè)是來(lái)自.proto文件的字段編號(hào)，加上提供正好足夠的信息來(lái)查找下一個(gè)值的長(zhǎng)度。在大多數(shù)語(yǔ)言實(shí)現(xiàn)中，這個(gè) key 被稱為 tag。

 

注意上圖中，3 和 4 已經(jīng)被廢棄了，所以 wire_type 取值目前只有 0、1、2、5 。

key 的計(jì)算方法是 (field_number<<3) | wire_type，換句話說(shuō)，key 的*** 3 位表示的就是 wire_type。

舉例，一般 message 的字段號(hào)都是 1 開(kāi)始的，所以對(duì)應(yīng)的 tag 可能是這樣的：

末尾 3 位表示的是 value 的類型，這里是 000，即 0 ，代表的是 varint 值。右移 3 位，即 0001，這代表的就是字段號(hào)(field number)。tag 的例子就舉這么多，接下來(lái)舉一個(gè) value 的例子，還是用 varint 來(lái)舉例：

 

96 01 = 1001 0110 0000 0001 → 000 0001 ++ 001 0110 (drop the msb and reverse the groups of 7 bits) 
       → 10010110 → 128 + 16 + 4 + 2 = 150 

可以 96 01 代表的數(shù)據(jù)就是 150 。

 

message Test1 { required int32 a = 1; 
} 

如果存在上面這樣的一個(gè) message 的結(jié)構(gòu)，如果存入 150，在 Protocol Buffer 中顯示的二進(jìn)制應(yīng)該為 08 96 01 。

額外說(shuō)一句，type 需要注意的是 type = 2 的情況，tag 里面除了包含 field number 和 wire_type ，還需要再包含一個(gè) length，決定 value 從那一段取出來(lái)。(具體原因見(jiàn) Protocol Buffer 字符串 這一章節(jié))

2. Signed Integers 編碼

從上面的表格里面可以看到 wire_type = 0 中包含了無(wú)符號(hào)的 varints，但是如果是一個(gè)無(wú)符號(hào)數(shù)呢?

一個(gè)負(fù)數(shù)一般會(huì)被表示為一個(gè)很大的整數(shù)，因?yàn)橛?jì)算機(jī)定義負(fù)數(shù)的符號(hào)位為數(shù)字的***位。如果采用 Varint 表示一個(gè)負(fù)數(shù)，那么一定需要 10 個(gè) byte 長(zhǎng)度。為此 Google Protocol Buffer 定義了 sint32 這種類型，采用 zigzag 編碼。 將所有整數(shù)映射成無(wú)符號(hào)整數(shù)，然后再采用 varint 編碼方式編碼 ，這樣，絕對(duì)值小的整數(shù)，編碼后也會(huì)有一個(gè)較小的 varint 編碼值。

Zigzag 映射函數(shù)為：

 

Zigzag(n) = (n << 1) ^ (n >> 31), n 為 sint32 時(shí)  
Zigzag(n) = (n << 1) ^ (n >> 63), n 為 sint64 時(shí) 

按照這種方法，-1 將會(huì)被編碼成 1，1 將會(huì)被編碼成 2，-2 會(huì)被編碼成 3，如下表所示：

 

需要注意的是，第二個(gè)轉(zhuǎn)換 (n >> 31) 部分，是一個(gè)算術(shù)轉(zhuǎn)換。所以，換句話說(shuō)，移位的結(jié)果要么是一個(gè)全為0(如果n是正數(shù))，要么是全部1(如果n是負(fù)數(shù))。

當(dāng) sint32 或 sint64 被解析時(shí)，它的值被解碼回原始的帶符號(hào)的版本。

3. Non-varint Numbers

Non-varint 數(shù)字比較簡(jiǎn)單，double 、fixed64 的 wire_type 為 1，在解析時(shí)告訴解析器，該類型的數(shù)據(jù)需要一個(gè) 64 位大小的數(shù)據(jù)塊即可。同理，float 和 fixed32 的 wire_type 為5，給其 32 位數(shù)據(jù)塊即可。兩種情況下，都是高位在后，低位在前。

說(shuō) Protocol Buffer 壓縮數(shù)據(jù)沒(méi)有到極限，原因就在這里，因?yàn)椴](méi)有壓縮 float、double 這些浮點(diǎn)類型 。

4. 字符串

 

wire_type 類型為 2 的數(shù)據(jù)，是一種指定長(zhǎng)度的編碼方式：key + length + content，key 的編碼方式是統(tǒng)一的，length 采用 varints 編碼方式，content 就是由 length 指定長(zhǎng)度的 Bytes。

舉例，假設(shè)定義如下的 message 格式：

 

message Test2 { optional string b = 2; 
} 

設(shè)置該值為"testing"，二進(jìn)制格式查看：

12 07 74 65 73 74 69 6e 67 

74 65 73 74 69 6e 67 是“testing”的 UTF8 代碼。

此處，key 是16進(jìn)制表示的，所以展開(kāi)是：

12 -> 0001 0010，后三位 010 為 wire type = 2，0001 0010 右移三位為 0000 0010，即 tag = 2。

length 此處為 7，后邊跟著 7 個(gè)bytes，即我們的字符串"testing"。

所以 wire_type 類型為 2 的數(shù)據(jù)，編碼的時(shí)候會(huì)默認(rèn)轉(zhuǎn)換為 T-L-V (Tag - Length - Value)的形式 。

5. 嵌入式 message

假設(shè)，定義如下嵌套消息：

 

message Test3 { 
  optional Test1 c = 3; 
} 

設(shè)置字段為整數(shù)150，編碼后的字節(jié)為：

1a 03 08 96 01 

08 96 01 這三個(gè)代表的是 150，上面講解過(guò)，這里就不再贅述了。

1a -> 0001 1010，后三位 010 為 wire type = 2，0001 1010 右移三位為 0000 0011，即 tag = 3。

length 為 3，代表后面有 3 個(gè)字節(jié)，即 08 96 01 。

需要轉(zhuǎn)變?yōu)?T - L - V 形式的還有 string, bytes, embedded messages, packed repeated fields (即 wire_type 為 2 的形式都會(huì)轉(zhuǎn)變成 T - L - V 形式)

6. Optional 和 Repeated 的編碼

在 proto2 中定義成 repeated 的字段，(沒(méi)有加上 [packed=true] option )，編碼后的 message 有一個(gè)或者多個(gè)包含相同 tag 數(shù)字的 key-value 對(duì)。這些重復(fù)的 value 不需要連續(xù)的出現(xiàn);他們可能與其他的字段間隔的出現(xiàn)。盡管他們是無(wú)序的，但是在解析時(shí)，他們是需要有序的。在 proto3 中 repeated 字段默認(rèn)采用 packed 編碼(具體原因見(jiàn) Packed Repeated Fields 這一章節(jié))

對(duì)于 proto3 中的任何非重復(fù)字段或 proto2 中的可選字段，編碼的 message 可能有也可能沒(méi)有包含該字段號(hào)的鍵值對(duì)。

通常，編碼后的 message，其 required 字段和 optional 字段最多只有一個(gè)實(shí)例。但是解析器卻需要處理多對(duì)一的情況。對(duì)于數(shù)字類型和 string 類型，如果同一值出現(xiàn)多次，解析器接受***一個(gè)它收到的值。對(duì)于內(nèi)嵌字段，解析器合并(merge)它接收到的同一字段的多個(gè)實(shí)例。就如 MergeFrom 方法一樣，所有單數(shù)的字段，后來(lái)的會(huì)替換先前的，所有單數(shù)的內(nèi)嵌 message 都會(huì)被合并(merge)，所有的 repeated 字段，都會(huì)串聯(lián)起來(lái)。這樣的規(guī)則的結(jié)果是， 解析兩個(gè)串聯(lián)的編碼后的 message，與分別解析兩個(gè) message 然后 merge，結(jié)果是一樣的 。例如：

 

MyMessage message; 
message.ParseFromString(str1 + str2); 

等價(jià)于

 

MyMessage message, message2; 
message.ParseFromString(str1); 
message2.ParseFromString(str2); 
message.MergeFrom(message2); 

這種方法有時(shí)是非常有用的。比如，即使不知道 message 的類型，也能夠?qū)⑵浜喜ⅰ?/p>

7. Packed Repeated Fields

在 2.1.0 版本以后，protocol buffers 引入了該種類型，其與 repeated 字段一樣，只是在末尾聲明了 [packed=true]。類似 repeated 字段卻又不同。在 proto3 中 Repeated 字段默認(rèn)就是以這種方式處理。對(duì)于 packed repeated 字段，如果 message 中沒(méi)有賦值，則不會(huì)出現(xiàn)在編碼后的數(shù)據(jù)中。否則的話，該字段所有的元素會(huì)被打包到單一一個(gè) key-value 對(duì)中，且它的 wire_type=2，長(zhǎng)度確定。每個(gè)元素正常編碼，只不過(guò)其前沒(méi)有標(biāo)簽 tag。例如有如下 message 類型：

 

message Test4 { repeated int32 d = 4 [packed=true]; 
} 

構(gòu)造一個(gè) Test4 字段，并且設(shè)置 repeated 字段 d 3個(gè)值：3，270和86942，編碼后：

22 // tag 0010 0010(field number 010 0 = 4, wire type 010 = 2) 06 // payload size (設(shè)置的length = 6 bytes) 03 // first element (varint 3) 8E 02 // second element (varint 270) 9E A7 05 // third element (varint 86942) 

形成了 Tag - Length - Value - Value - Value …… 對(duì) 。

只有原始數(shù)字類型(使用varint，32位或64位)的重復(fù)字段才可以聲明為“packed”。

有一點(diǎn)需要注意，對(duì)于 packed 的 repeated 字段，盡管通常沒(méi)有理由將其編碼為多個(gè) key-value 對(duì)，編碼器必須有接收多個(gè) key-pair 對(duì)的準(zhǔn)備。這種情況下，payload 必須是串聯(lián)的，每個(gè) pair 必須包含完整的元素。

Protocol Buffer 解析器必須能夠解析被重新編譯為 packed 的字段，就像它們未被 packed 一樣，反之亦然。這允許以正向和反向兼容的方式將[packed = true]添加到現(xiàn)有字段。

8. Field Order

編碼/解碼與字段順序無(wú)關(guān)，這一點(diǎn)由 key-value 機(jī)制保證。

如果消息具有未知字段，則當(dāng)前的 Java 和 C++ 實(shí)現(xiàn)在按順序排序的已知字段之后以任意順序?qū)懭胨鼈?。?dāng)前的 Python 實(shí)現(xiàn)不會(huì)跟蹤未知字段。

七. protocol buffers 的優(yōu)缺點(diǎn)

 

protocol buffers 在序列化方面，與 XML 相比，有諸多優(yōu)點(diǎn)：

• 更加簡(jiǎn)單
• 數(shù)據(jù)體積小 3- 10 倍
• 更快的反序列化速度，提高 20 - 100 倍
• 可以自動(dòng)化生成更易于編碼方式使用的數(shù)據(jù)訪問(wèn)類

舉個(gè)例子：

如果要編碼一個(gè)用戶的名字和 email 信息，用 XML 的方式如下：

 

John Doe  
jdoe@example.com 

相同需求，如果換成 protocol buffers 來(lái)實(shí)現(xiàn)，定義文件如下：

 

# Textual representation of a protocol buffer. 
# This is *not* the binary format used on the wire. 
person { 
  name: "John Doe" email: "jdoe@example.com" } 

protocol buffers 通過(guò)編碼以后，以二進(jìn)制的方式進(jìn)行數(shù)據(jù)傳輸，最多只需要 28 bytes 空間和 100-200 ns 的反序列化時(shí)間。但是 XML 則至少需要 69 bytes 空間(經(jīng)過(guò)壓縮以后，去掉所有空格)和 5000-10000 的反序列化時(shí)間。

上面說(shuō)的是性能方面的優(yōu)勢(shì)。接下來(lái)說(shuō)說(shuō)編碼方面的優(yōu)勢(shì)。

protocol buffers 自帶代碼生成工具，可以生成友好的數(shù)據(jù)訪問(wèn)存儲(chǔ)接口。從而開(kāi)發(fā)人員使用它來(lái)編碼更加方便。例如上面的例子，如果用 C++ 的方式去讀取用戶的名字和 email，直接調(diào)用對(duì)應(yīng)的 get 方法即可(所有屬性的 get 和 set 方法的代碼都自動(dòng)生成好了，只需要調(diào)用即可)

 

cout << "Name: " << person.name() << endl; 
cout << "E-mail: " << person.email() << endl; 

而 XML 讀取數(shù)據(jù)會(huì)麻煩一些：

 

cout << "Name: " 
       << person.getElementsByTagName("name")->item(0)->innerText() 
       << endl; 
  cout << "E-mail: " 
       << person.getElementsByTagName("email")->item(0)->innerText() 
       << endl; 

Protobuf 語(yǔ)義更清晰，無(wú)需類似 XML 解析器的東西(因?yàn)?Protobuf 編譯器會(huì)將 .proto 文件編譯生成對(duì)應(yīng)的數(shù)據(jù)訪問(wèn)類以對(duì) Protobuf 數(shù)據(jù)進(jìn)行序列化、反序列化操作)。

使用 Protobuf 無(wú)需學(xué)習(xí)復(fù)雜的文檔對(duì)象模型，Protobuf 的編程模式比較友好，簡(jiǎn)單易學(xué)，同時(shí)它擁有良好的文檔和示例，對(duì)于喜歡簡(jiǎn)單事物的人們而言，Protobuf 比其他的技術(shù)更加有吸引力。

protocol buffers ***一個(gè)非常棒的特性是，即“向后”兼容性好，人們不必破壞已部署的、依靠“老”數(shù)據(jù)格式的程序就可以對(duì)數(shù)據(jù)結(jié)構(gòu)進(jìn)行升級(jí)。這樣您的程序就可以不必?fù)?dān)心因?yàn)橄⒔Y(jié)構(gòu)的改變而造成的大規(guī)模的代碼重構(gòu)或者遷移的問(wèn)題。因?yàn)樘砑有碌南⒅械? field 并不會(huì)引起已經(jīng)發(fā)布的程序的任何改變(因?yàn)榇鎯?chǔ)方式本來(lái)就是無(wú)序的，k-v 形式)。

當(dāng)然 protocol buffers 也并不是***的，在使用上存在一些局限性。

由于文本并不適合用來(lái)描述數(shù)據(jù)結(jié)構(gòu)，所以 Protobuf 也不適合用來(lái)對(duì)基于文本的標(biāo)記文檔(如 HTML)建模。另外，由于 XML 具有某種程度上的自解釋性，它可以被人直接讀取編輯，在這一點(diǎn)上 Protobuf 不行，它以二進(jìn)制的方式存儲(chǔ)，除非你有 .proto 定義，否則你沒(méi)法直接讀出 Protobuf 的任何內(nèi)容。

八. ***

讀完本篇 Protocol Buffer 編碼原理以后，讀者應(yīng)該能明白以下幾點(diǎn)：

• Protocol Buffer 利用 varint 原理壓縮數(shù)據(jù)以后，二進(jìn)制數(shù)據(jù)非常緊湊，option 也算是壓縮體積的一個(gè)舉措。所以 pb 體積更小，如果選用它作為網(wǎng)絡(luò)數(shù)據(jù)傳輸，勢(shì)必相同數(shù)據(jù)，消耗的網(wǎng)絡(luò)流量更少。但是并沒(méi)有壓縮到極限，float、double 浮點(diǎn)型都沒(méi)有壓縮。
• Protocol Buffer 比 JSON 和 XML 少了 {、}、: 這些符號(hào)，體積也減少一些。再加上 varint 壓縮，gzip 壓縮以后體積更小!
• Protocol Buffer 是 Tag - Value (Tag - Length - Value)的編碼方式的實(shí)現(xiàn)，減少了分隔符的使用，數(shù)據(jù)存儲(chǔ)更加緊湊。
• Protocol Buffer 另外一個(gè)核心價(jià)值在于提供了一套工具，一個(gè)編譯工具，自動(dòng)化生成 get/set 代碼。簡(jiǎn)化了多語(yǔ)言交互的復(fù)雜度，使得編碼解碼工作有了生產(chǎn)力。
• Protocol Buffer 不是自我描述的，離開(kāi)了數(shù)據(jù)描述 .proto 文件，就無(wú)法理解二進(jìn)制數(shù)據(jù)流。這點(diǎn)即是優(yōu)點(diǎn)，使數(shù)據(jù)具有一定的“加密性”，也是缺點(diǎn)，數(shù)據(jù)可讀性極差。所以 Protocol Buffer 非常適合內(nèi)部服務(wù)之間 RPC 調(diào)用和傳遞數(shù)據(jù)。
• Protocol Buffer 具有向后兼容的特性，更新數(shù)據(jù)結(jié)構(gòu)以后，老版本依舊可以兼容，這也是 Protocol Buffer 誕生之初被寄予解決的問(wèn)題。因?yàn)榫幾g器對(duì)不識(shí)別的新增字段會(huì)跳過(guò)不處理。
• Protocol Buffer 編碼原理篇到此結(jié)束，下篇來(lái)講講 Protocol Buffer 反序列化解包性能快的原因。

Reference：