在之前的文章中,我們全面介紹了gRPC,在這一部分中,我們將涵蓋Protocol Buffer,也稱為Protobuf。
Protobuf標志
“Protocol Buffers”這個名字有著獨特的起源。
在早期,它指的是一個名為“ProtocolBuffer”的類,充當了單個方法調用的緩沖區。用戶可以向此緩沖區添加標簽/值對,原始字節會存儲在其中,直到構建消息后被寫出。盡管名稱中的“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維護,盡管也有可選的實現。生成的代碼經過優化,以實現數據的快速序列化和反序列化。
Proto vs JSON
你可能會想,既然已經有廣泛使用的序列化格式JSON,為什么要選擇Protocol Buffers(Protobuf)呢?
讓我們深入探討Protobuf為什么是一個出色的選擇,以及它在解決常見數據序列化挑戰方面與JSON相比的情況:
在總結一下,Protobuf和JSON各有各自的獨特優勢,Protobuf在需要效率、跨平臺兼容性和結構化數據至關重要的情況下表現出色。
另一方面,當您需要可讀性強的數據或輕量級格式的簡單性更合適時,JSON仍然是一個很好的選擇。
這個快速介紹為您提供了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(用于列表):
枚舉允許您定義一組命名的常量值。當您有一個字段具有預定義選項集,例如一周的日期或產品類別時,它非常有用。
enum DayOfWeek {MONDAY = 1;TUESDAY = 2;// ...}
您可以在Protobuf定義中包含注釋,以更好地解釋您的消息和字段。注釋可以以//開始,也可以包裝在/* ... */中。
Protobuf提供不同的語法版本,其中proto2和`proto3`是最常見的。這些版本定義了您可以在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網站上了解更多信息。
Protocol Buffers(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文檔是深入了解這項技術的綜合指南。
本文鏈接:http://www.tebozhan.com/showinfo-26-14809-0.html解密gRPC:Protocol Buffer
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。郵件:2376512515@qq.com