來源：小技術君

在之前的文章中，我們全面介紹了gRPC，在這一部分中，我們將涵蓋Protocol Buffer，也稱為Protobuf。

Protobuf標誌

“Protocol Buffers”這個名字有著獨特的起源。

在早期，它指的是一個名為“ProtocolBuffer”的類，充當了單個方法呼叫的緩衝區。使用者可以向此緩衝區新增標籤/值對，原始位元組會儲存在其中，直到構建訊息後被寫出。儘管名稱中的“buffers”部分失去了原始含義，但它一直存在。今天，我們通常使用“協議訊息”來指代抽象意義上的訊息，“協議緩衝區”來指代序列化訊息，以及“協議訊息物件”來指代解析後的記憶體表示。

什麼是Protocol Buffers？

Protocol Buffers是一種簡單的語言中立和平臺中立的介面定義語言（IDL），用於定義資料結構模式和程式設計介面。它支援二進位制和文字線路格式，並可以與不同平臺上的許多不同線路協議一起工作。例如，看看這個簡單的proto檔案（person.proto），定義了一個名為'Person'的訊息。這個訊息描述了一個人的屬性，包括名字，ID和可選的電子郵件地址。message Person { required string name = 1; required int32 id = 2; optional string email = 3; } 這個person.proto檔案用作伺服器和客戶端之間的契約。如果您想要更改這個“Person”實體的結構，或者更改請求和響應的外觀，您需要修改proto檔案。Protobuf編譯器protoc由Google維護，儘管也有可選的實現。生成的程式碼經過最佳化，以實現資料的快速序列化和反序列化。

為什麼選擇Protocol Buffers（Protobuf）而不是JSON？

Proto vs JSON

你可能會想，既然已經有廣泛使用的序列化格式JSON，為什麼要選擇Protocol Buffers（Protobuf）呢？

讓我們深入探討Protobuf為什麼是一個出色的選擇，以及它在解決常見資料序列化挑戰方面與JSON相比的情況：

在總結一下，Protobuf和JSON各有各自的獨特優勢，Protobuf在需要效率、跨平臺相容性和結構化資料至關重要的情況下表現出色。

另一方面，當您需要可讀性強的資料或輕量級格式的簡單性更合適時，JSON仍然是一個很好的選擇。

Protobuf語法

這個快速介紹為您提供了Protobuf的語法和核心概念的味道。如果您想進一步探索，我鼓勵您檢視官方Protocol Buffers文件。***

訊息：資料藍圖

將Protobuf訊息視為資料結構的藍圖。它們告訴您資料應該如何組織。

message Recipe {string dish_name = 1;repeated string ingredients = 2;double preparation_time_minutes = 3;}

在這個例子中，我們建立了一個名為Recipe的訊息，其中包含三個欄位：dish_name表示菜名，ingredients表示配料列表（可以有多個），preparation_time_minutes表示製作這道菜所需的時間。每個欄位都有一個唯一的編號（例如，1，2，3），用於組織。

欄位型別

Protobuf支援各種欄位型別，如字串、整數、浮點數、列舉等等。您甚至可以巢狀訊息以建立複雜的資料結構。這些欄位型別確保資料結構良好，型別正確。

欄位標籤

訊息中的欄位可以具有標籤，確定它們是required、optional還是repeated（用於列表）：

•Required欄位：這些欄位必須始終出現在此型別的訊息中。如果在序列化訊息時缺少一個必需欄位，將導致錯誤。•Optional欄位：它們可以包含在訊息中，但不是必需的。如果在序列化訊息時省略了可選欄位，它將被視為具有預設值。•Repeated欄位：重複欄位允許在單個欄位中具有相同型別的多個值。它們用於資料的列表或陣列。

列舉

列舉允許您定義一組命名的常量值。當您有一個欄位具有預定義選項集，例如一週的日期或產品類別時，它非常有用。

enum DayOfWeek {MONDAY = 1;TUESDAY = 2;// ...}

註釋

您可以在Protobuf定義中包含註釋，以更好地解釋您的訊息和欄位。註釋可以以//開始，也可以包裝在/* ... */中。

語法版本：規則和特性

Protobuf提供不同的語法版本，其中proto2和`proto

3`是最常見的。這些版本定義了您可以在Protobuf定義中使用的規則和特性。

注意：建議gRPC API使用Protocol Buffers版本3（proto3）來定義API

匯入其他檔案：保持組織

對於更大的專案，您可以將Protobuf定義分成多個檔案，並使用import語句將它們組合在一起。

序列化和反序列化

Protobuf的線路格式是二進位制編碼，因此處理起來更快。它使用一些巧妙的技巧來最小化用於表示訊息的位元組數。不需要了解二進位制編碼格式的知識來使用Protobuf。

為了真正理解Protocol Buffers（Protobuf）的威力，讓我們透過一個示例，演示資料是如何序列化和編碼，以及隨後如何解碼回來的。

考慮以下資料：

（我們使用前面定義的person.proto）

{"name": "Ankit","id": 21,"email": "username@gmail.com"}

序列化和編碼

Protobuf將此JSON資料轉換為一個既高效又節省空間的二進位制格式。在這種情況下，Protobuf編碼如下：

0a 05 41 6e 6b 69 74 10 15 1a 12 75 73 65 72 6e 61 6d 65 40 67 6d 61 69 6c 2e 63 6f 6d

解碼

現在，讓我們顛倒這個過程，將這個Protobuf資料解碼回其原始形式：

這個解碼過程使Protobuf如此高效和強大。它確保資料保持一致和結構化，即使在編碼和解碼後，這使得它成為各種場景中資料傳輸的首選選擇。

這只是一個簡單的示例，如果您有興趣，可以在Protocol Buffers網站上了解更多資訊。

gRPC中的Protocol Buffers

Protocol Buffers（Protobuf）在gRPC中至關重要，為客戶端和伺服器之間提供了高效和一致的通訊。以下是它們至關重要的原因：

•API契約定義：Protobuf為gRPC定義了訊息結構，確保了高效和無錯誤的資料傳輸。•高效的序列化：Protobuf的二進位制格式加速了資料序列化和反序列化，提高了gRPC的效能。•語言中立性：Protobuf的語言不可知性使其能夠無縫整合到各種程式語言中。•高效性：Protobuf的二進位制格式減少了網路使用，使資料傳輸更快。•互操作性：Protobuf充當通用翻譯器，使gRPC服務能夠在不同語言和平臺之間輕鬆通訊。•向後相容性：Protobuf的版本支援允許API演進而不破壞現有客戶端。•程式碼生成：Protobuf簡化了訊息結構程式碼生成，簡化了開發流程。•效能：Protobuf的高效序列化和反序列化增強了gRPC服務的整體效能。

讓我們包括一個使用Protocol Buffers（Protobuf）定義的gRPC服務的示例。假設我們正在構建一個帶有使用者身份驗證的聊天應用程式。

這是我們服務的Protobuf定義：

syntax = "proto3";message User {string id = 1;string username = 2;}message Message {string id = 1;string text = 2;User sender = 3;}service ChatService {rpc SendMessage(Message) returns (Message);rpc GetMessages(User) returns (stream Message);}

在這個示例中，我們定義了兩種訊息型別，User和Message，以及一個允許傳送和接收訊息的ChatService。使用Protobuf，這個服務定義清晰、簡潔，並且可以輕鬆地生成成各種程式語言的程式碼。

總之，Protocol Buffers（Protobuf）已經徹底改變了資料序列化、傳輸和在不同系統中的理解方式。它們的效率、跨平臺相容性和結構化資料處理使它們成為現代應用程式的強大選擇。

透過了解Protobuf的語法、核心概念以及它在gRPC中的作用，您可以充分利用它的功能。在探索Protobuf的世界時，請記住官方Protocol Buffers文件是深入瞭解這項技術的綜合指南。