這篇文章給大家介紹ProtoBuf的底層原理是什么，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對(duì)大家能有所幫助。
成都創(chuàng)新互聯(lián)專(zhuān)注于企業(yè)網(wǎng)絡(luò)營(yíng)銷(xiāo)推廣、網(wǎng)站重做改版、黟縣網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、H5建站、成都商城網(wǎng)站開(kāi)發(fā)、集團(tuán)公司官網(wǎng)建設(shè)、成都外貿(mào)網(wǎng)站建設(shè)、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁(yè)設(shè)計(jì)等建站業(yè)務(wù)，價(jià)格優(yōu)惠性?xún)r(jià)比高，為黟縣等各大城市提供網(wǎng)站開(kāi)發(fā)制作服務(wù)。
ProtoBuf(Protocol Buffers)是一種跨平臺(tái)、語(yǔ)言無(wú)關(guān)、可擴(kuò)展的序列化結(jié)構(gòu)數(shù)據(jù)的方法，可用于網(wǎng)絡(luò)數(shù)據(jù)交換及存儲(chǔ)。
在序列化結(jié)構(gòu)化數(shù)據(jù)的機(jī)制中，ProtoBuf是靈活、高效、自動(dòng)化的，相對(duì)常見(jiàn)的XML、JSON，描述同樣的信息，ProtoBuf序列化后數(shù)據(jù)量更小、序列化/反序列化速度更快、更簡(jiǎn)單。
一旦定義了要處理的數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)之后，就可以利用ProtoBuf的代碼生成工具生成相關(guān)的代碼。只需使用 Protobuf 對(duì)數(shù)據(jù)結(jié)構(gòu)進(jìn)行一次描述，即可利用各種不同語(yǔ)言(proto3支持C++, Java, Python, Go, Ruby, Objective-C, C#)或從各種不同流中對(duì)你的結(jié)構(gòu)化數(shù)據(jù)輕松讀寫(xiě)。
大家可能會(huì)覺(jué)得 Google 發(fā)明 ProtoBuf 是為了解決序列化速度的，其實(shí)真實(shí)的原因并不是這樣的。
ProtoBuf最先開(kāi)始是 Google用來(lái)解決索引服務(wù)器 request/response 協(xié)議的。沒(méi)有ProtoBuf之前，Google 已經(jīng)存在了一種 request/response 格式，用于手動(dòng)處理 request/response 的編解碼。它也能支持多版本協(xié)議，不過(guò)代碼不夠優(yōu)雅：
重慶分公司
重慶分公司
if (protocolVersion=1) {
doSomething();
} else if (protocolVersion=2) {
doOtherThing();
} ...如果是非常明確的格式化協(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)題。
為了解決這些問(wèn)題，于是ProtoBuf就誕生了。
ProtoBuf 最初被寄予以下 2 個(gè)特點(diǎn)：
更容易引入新的字段，并且不需要檢查數(shù)據(jù)的中間服務(wù)器可以簡(jiǎn)單地解析并傳遞數(shù)據(jù)，而無(wú)需了解所有字段。
數(shù)據(jù)格式更加具有自我描述性，可以用各種語(yǔ)言來(lái)處理(C++, Java 等各種語(yǔ)言)。
這個(gè)版本的 ProtoBuf 仍需要自己手寫(xiě)解析的代碼。
不過(guò)隨著系統(tǒng)慢慢發(fā)展，演進(jìn)，ProtoBuf具有了更多的特性：
自動(dòng)生成的序列化和反序列化代碼避免了手動(dòng)解析的需要。（官方提供自動(dòng)生成代碼工具，各個(gè)語(yǔ)言平臺(tái)的基本都有）。
除了用于數(shù)據(jù)交換之外，ProtoBuf被用作持久化數(shù)據(jù)的便捷自描述格式。
ProtoBuf 現(xiàn)在是 Google 用于數(shù)據(jù)交換和存儲(chǔ)的通用語(yǔ)言。谷歌代碼樹(shù)中定義了 48162 種不同的消息類(lèi)型，包括 12183 個(gè) .proto 文件。它們既用于 RPC 系統(tǒng)，也用于在各種存儲(chǔ)系統(tǒng)中持久存儲(chǔ)數(shù)據(jù)。
ProtoBuf 誕生之初是為了解決服務(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.
可以看到，對(duì)于序列化協(xié)議來(lái)說(shuō)，使用方只需要關(guān)注業(yè)務(wù)對(duì)象本身，即 idl 定義，序列化和反序列化的代碼只需要通過(guò)工具生成即可。
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;
}上面的消息比較簡(jiǎn)單，Customers包含多個(gè)Customer，Customer包含一個(gè)id字段，一個(gè)firstName字段，一個(gè)lastName字段以及一個(gè)email的集合。
除了這些定義外，文件頂部還有三行可幫助代碼生成器：
首先，syntax = "proto3"用于idl語(yǔ)法版本，目前有兩個(gè)版本proto2和proto3，兩個(gè)版本語(yǔ)法不兼容，如果不指定，默認(rèn)語(yǔ)法是proto2。由于proto3比proto2支持的語(yǔ)言更多，語(yǔ)法更簡(jiǎn)潔，本文使用的是proto3。
其次有一個(gè)package domain;定義。此配置用于嵌套生成的類(lèi)/對(duì)象。
有一個(gè)option java_package定義。生成器還使用此配置來(lái)嵌套生成的源。此處的區(qū)別在于這僅適用于Java。在使用Java創(chuàng)建代碼和使用JavaScript創(chuàng)建代碼時(shí)，使用了兩種配置來(lái)使生成器的行為有所不同。也就是說(shuō)，Java類(lèi)是在包c(diǎn)om.protobuf.generated.domain下創(chuàng)建的，而JavaScript對(duì)象是在包domain下創(chuàng)建的。
ProtoBuf 提供了更多選項(xiàng)和數(shù)據(jù)類(lèi)型，本文不做詳細(xì)介紹，感興趣可以參考這里。
首先安裝 ProtoBuf 編譯器 protoc，這里有詳細(xì)的安裝教程，安裝完成后，可以使用以下命令生成 Java 源代碼：
protoc --java_out=./src/main/java ./src/main/idl/customer.proto
從項(xiàng)目的根路徑執(zhí)行該命令，并添加了兩個(gè)參數(shù)：java_out，定義./src/main/java/為Java代碼的輸出目錄；而./src/main/idl/customer.proto是.proto文件所在目錄。
生成的代碼非常復(fù)雜，但是幸運(yùn)的是它的用法卻非常簡(jiǎn)單。
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());我們簡(jiǎn)單地以Customers為模型，分別構(gòu)造、選取小對(duì)象、普通對(duì)象、大對(duì)象進(jìn)行性能對(duì)比。
序列化耗時(shí)以及序列化后數(shù)據(jù)大小對(duì)比
更多性能數(shù)據(jù)可以參考官方 Benchmark
上面介紹了 ProtoBuf 是什么、產(chǎn)生的背景、基本用法，我們?cè)倏偨Y(jié)下。
優(yōu)點(diǎn)：
1. 效率高
從序列化后的數(shù)據(jù)體積角度，與XML、JSON這類(lèi)文本協(xié)議相比，ProtoBuf通過(guò)T-(L)-V（TAG-LENGTH-VALUE）方式編碼，不需要", {, }, :等分隔符來(lái)結(jié)構(gòu)化信息，同時(shí)在編碼層面使用varint壓縮，所以描述同樣的信息，ProtoBuf序列化后的體積要小很多，在網(wǎng)絡(luò)中傳輸消耗的網(wǎng)絡(luò)流量更少，進(jìn)而對(duì)于網(wǎng)絡(luò)資源緊張、性能要求非常高的場(chǎng)景，ProtoBuf協(xié)議是不錯(cuò)的選擇。
// 我們簡(jiǎn)單做個(gè)對(duì)比
// 要描述如下JSON數(shù)據(jù)
{"id":1,"firstName":"Chris","lastName":"Richardson","email":[{"type":"PROFESSIONAL","email":"crichardson@email.com"}]}
# 使用JSON序列化后的數(shù)據(jù)大小為118byte
7b226964223a312c2266697273744e616d65223a224368726973222c226c6173744e616d65223a2252696368617264736f6e222c22656d61696c223a5b7b2274797065223a2250524f46455353494f4e414c222c22656d61696c223a226372696368617264736f6e40656d61696c2e636f6d227d5d7d
# 而使用ProtoBuf序列化后的數(shù)據(jù)大小為48byte
0801120543687269731a0a52696368617264736f6e2a190a156372696368617264736f6e40656d61696c2e636f6d1001從序列化/反序列化速度角度，與XML、JSON相比，ProtoBuf序列化/反序列化的速度更快，比XML要快20-100倍。
2. 支持跨平臺(tái)、多語(yǔ)言
ProtoBuf是平臺(tái)無(wú)關(guān)的，無(wú)論是Android與PC，還是C#與Java都可以利用ProtoBuf進(jìn)行無(wú)障礙通訊。
proto3支持C++, Java, Python, Go, Ruby, Objective-C, C#。
3. 擴(kuò)展性、兼容性好
具有向后兼容的特性，更新數(shù)據(jù)結(jié)構(gòu)以后，老版本依舊可以兼容，這也是ProtoBuf誕生之初被寄予解決的問(wèn)題。因?yàn)榫幾g器對(duì)不識(shí)別的新增字段會(huì)跳過(guò)不處理。
4. 使用簡(jiǎn)單
ProtoBuf 提供了一套編譯工具，可以自動(dòng)生成序列化、反序列化的樣板代碼，這樣開(kāi)發(fā)者只要關(guān)注業(yè)務(wù)數(shù)據(jù)idl，簡(jiǎn)化了編碼解碼工作以及多語(yǔ)言交互的復(fù)雜度。
缺點(diǎn)：
可讀性差，缺乏自描述
XML，JSON是自描述的，而ProtoBuf則不是。
ProtoBuf是二進(jìn)制協(xié)議，編碼后的數(shù)據(jù)可讀性差，如果沒(méi)有idl文件，就無(wú)法理解二進(jìn)制數(shù)據(jù)流，對(duì)調(diào)試不友好。
不過(guò)Charles已經(jīng)支持ProtoBuf協(xié)議，導(dǎo)入數(shù)據(jù)的描述文件即可，詳情可參考Charles Protocol Buffers
此外，由于沒(méi)有idl文件無(wú)法解析二進(jìn)制數(shù)據(jù)流，ProtoBuf在一定程度上可以保護(hù)數(shù)據(jù)，提升核心數(shù)據(jù)被破解的門(mén)檻，降低核心數(shù)據(jù)被盜爬的風(fēng)險(xiǎn)。
關(guān)于ProtoBuf的底層原理是什么就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到。
