簡(jiǎn)介protobuf-2.6.0是Google Protocol Buffers序列化框架的穩(wěn)定版本面向需要高效跨語(yǔ)言結(jié)構(gòu)化數(shù)據(jù)交換的開(kāi)發(fā)者可用于RPC通信、配置存儲(chǔ)、日志記錄及游戲數(shù)據(jù)交換等場(chǎng)景。資源包共657個(gè)文件壓縮后約3.15MB包含大量cc/h源代碼、Java與Python綁定、proto定義文件以及生成代碼所需的編譯器工程文件、configure腳本和示例測(cè)試基本覆蓋C/Java/Python多語(yǔ)言使用需求文件類(lèi)型中的sln、vcproj、cbproj等構(gòu)建工程與am、ac等自動(dòng)配置腳本能幫助理解項(xiàng)目整體結(jié)構(gòu)與編譯過(guò)程。已有215人學(xué)習(xí)下載。包內(nèi)還附有測(cè)試用例、構(gòu)建環(huán)境和說(shuō)明文檔便于本地搭建protobuf環(huán)境并驗(yàn)證序列化/反序列化功能對(duì)希望掌握.proto定義、調(diào)用各語(yǔ)言API或了解2.6.0內(nèi)部實(shí)現(xiàn)的讀者可結(jié)合源碼、示例與測(cè)試快速上手甚至借鑒其工程組織方式。該版本兼容性良好適合直接集成到現(xiàn)有項(xiàng)目中作為數(shù)據(jù)交換基礎(chǔ)組件。1. protobuf 2.6.0十年前的序列化庫(kù)為什么今天還在你的依賴(lài)樹(shù)里protobuf 2.6.0 這個(gè)版本往遠(yuǎn)了說(shuō)發(fā)布已經(jīng)超過(guò)十年但你在不少遺留系統(tǒng)的編譯清單里仍然能看到它的影子。接手別人的服務(wù)或者跟一個(gè)已經(jīng)跑了很多年的老接口做跨團(tuán)隊(duì)聯(lián)調(diào)一打開(kāi)依賴(lài)樹(shù)看到這個(gè)版本第一反應(yīng)往往是“能不能換掉”。換掉的代價(jià)很直接已落盤(pán)的存儲(chǔ)數(shù)據(jù)、已運(yùn)行的上下游服務(wù)、已編譯好的線(xiàn)上程序全都和它綁定著。本文從編譯安裝、proto2 消息定義、序列化反序列化一路講到兼容性排查和升級(jí)取舍給正被這個(gè)版本困住的從業(yè)者一條可操作的路徑。新手照著能跑通熟手可以直接跳到參數(shù)和坑的部分看。2. protobuf 2.6.0 的從源碼構(gòu)建configure 參數(shù)、make 與三種語(yǔ)言運(yùn)行時(shí)動(dòng)手之前先搞清楚一件事protobuf 2.6.0 的官方發(fā)布體系分兩部分一部分是編譯器 protoc 和 C 運(yùn)行時(shí)庫(kù)另一部分是針對(duì) Java、Python 等語(yǔ)言的運(yùn)行時(shí)。只需要其中一種語(yǔ)言就先裝 C 那部分再單獨(dú)構(gòu)建語(yǔ)言運(yùn)行時(shí)。常見(jiàn)做法是先用源碼包把 protoc 和 libprotobuf 一同裝上再處理 Java 的 jar 包或 Python 的安裝模塊。2.1 構(gòu)建前的工具鏈檢查與依賴(lài)確認(rèn)protobuf 2.6.0 從源碼包編譯時(shí)要先確認(rèn)幾個(gè)基礎(chǔ)工具在位。我一般會(huì)逐個(gè)檢查gcc --version g --version make --version autoconf --version automake --version libtoolize --version這六個(gè)命令分別驗(yàn)證 C 編譯器、C 編譯器、make、autotools 三件套是否可用。如果缺 autoconf 或 libtool用系統(tǒng)包管理器裝一下就行。protobuf 2.6.0 的構(gòu)建體系基于 autotools發(fā)布版 tar 包內(nèi)已經(jīng)包含 configure 腳本可以直接執(zhí)行但從 git 倉(cāng)庫(kù)拉的源碼沒(méi)有 configure必須先運(yùn)行 autogen.sh 生成它。這一步經(jīng)常被跳過(guò)導(dǎo)致明明源碼在手編譯卻總是提示找不到 configure。configure 是構(gòu)建流程的總?cè)肟谒鼨z測(cè)編譯器特性、檢查依賴(lài)庫(kù)、生成 config.h 和 Makefile。我的經(jīng)驗(yàn)是除非 configure 報(bào)錯(cuò)否則不要手動(dòng)改 config.h。老項(xiàng)目的配置邏輯很敏感手工改動(dòng)容易引發(fā)后續(xù)一連串鏈接錯(cuò)誤而且排查起來(lái)極費(fèi)時(shí)間。2.2 configure 與 make最小命令與關(guān)鍵參數(shù)說(shuō)明下面是一組最常用的構(gòu)建命令tar -xzf protobuf-2.6.0.tar.gz cd protobuf-2.6.0 ./configure --prefix/usr/local/protobuf-2.6.0 make -j4 make check make install逐步說(shuō)明。--prefix控制安裝位置不指定時(shí)默認(rèn)裝到 /usr/localprotoc 進(jìn) /usr/local/bin頭文件進(jìn) /usr/local/include。指定獨(dú)立 prefix 是為了避免和系統(tǒng)里可能存在的其他 protobuf 版本沖突也方便整體卸載直接刪目錄就干凈了。make -j4按 4 個(gè)并行任務(wù)編譯機(jī)器核數(shù)多可以調(diào)大。老版本 Makefile 對(duì)并行編譯支持并不完美偶爾會(huì)出現(xiàn)奇怪的依賴(lài)錯(cuò)誤失敗時(shí)去掉 -j 重新跑 make 就行。make check是官方測(cè)試套件強(qiáng)烈建議跑一遍它能提前暴露運(yùn)行時(shí)庫(kù)和編譯器不匹配的問(wèn)題。make install需要目標(biāo)目錄寫(xiě)入權(quán)限普通用戶(hù)不行就加 sudo。configure 有幾個(gè)可選參數(shù)值得關(guān)注./configure --prefix/usr/local/protobuf-2.6.0 --disable-shared --enable-staticyes--disable-shared只構(gòu)建靜態(tài)庫(kù)。線(xiàn)上服務(wù)器如果追求二進(jìn)制最小依賴(lài)、不喜歡在系統(tǒng)庫(kù)目錄里塞一堆 .so適合用靜態(tài)方式。默認(rèn)情況下 configure 會(huì)在系統(tǒng)里找 zlib用于 gzip 流支持找不到時(shí)相關(guān)功能會(huì)被禁用但基礎(chǔ)序列化不受影響。我在模擬項(xiàng)目 X 里做這套構(gòu)建時(shí)遇到過(guò)一個(gè)典型情況配置時(shí)提示找不到 libtoolize生成 Makefile 報(bào)錯(cuò)裝上對(duì)應(yīng)包之后重新跑 configure 就正常了。另一個(gè)常見(jiàn)現(xiàn)象是編譯器太新對(duì)舊代碼里某些模板推導(dǎo)不友好這個(gè)放在第五章專(zhuān)門(mén)展開(kāi)。2.3 語(yǔ)言運(yùn)行時(shí)C、Java、Python 的安裝差別protobuf 2.6.0 的源碼包結(jié)構(gòu)里C core 在根目錄Java 在 java/ 子目錄Python 在 python/ 子目錄。C 部分編譯安裝好之后protoc 已經(jīng)能用Java 和 Python 還要各自構(gòu)建一次運(yùn)行時(shí)。Java 運(yùn)行時(shí)的常見(jiàn)構(gòu)建方式是用 Mavencd java mvn install -DskipTests這條命令會(huì)生成 protobuf-java-2.6.0.jar 并安裝到本地 Maven 倉(cāng)庫(kù)。注意它依賴(lài) protoc 已裝好因?yàn)樯纱a時(shí)靠 protoc 去做編譯Maven 構(gòu)建只是把 Java 運(yùn)行時(shí)和生成邏輯打成包。Python 運(yùn)行時(shí)的構(gòu)建要進(jìn)到 python 目錄cd python python setup.py build python setup.py install有一個(gè)比較隱蔽的點(diǎn)Python 運(yùn)行時(shí)裝完后import 的模塊名是 google.protobufprotoc 生成的 _pb2.py 文件通過(guò)這個(gè)命名空間找運(yùn)行時(shí)版本必須匹配。用 pip 直接裝到別的版本再混用生成代碼真會(huì)出問(wèn)題。老版本對(duì) Python 3 的支持成熟度有限如果在 Python 3 環(huán)境跑建議先在測(cè)試環(huán)境把 setup.py 完整走一遍確認(rèn)再上線(xiàn)。代碼生成器的版本與運(yùn)行時(shí)版本必須嚴(yán)格一致這是整個(gè) protobuf 生態(tài)的第一紀(jì)律。用 2.6.0 的 protoc 生成的代碼只能在 2.6.0 的運(yùn)行時(shí)上正常工作換個(gè)新版本運(yùn)行時(shí)輕則警告重則運(yùn)行期異常。3. 用 protobuf 2.6.0 定義 proto2 消息字段約束、默認(rèn)值與 protoc 編譯protobuf 2.6.0 對(duì)應(yīng)的描述語(yǔ)言是 proto2它和后來(lái)的 proto3 語(yǔ)法差異不小。最直接的影響是required、optional、repeated 這三個(gè)語(yǔ)義在 proto2 里寫(xiě)得分明反序列化時(shí)也會(huì)嚴(yán)格按規(guī)則檢查。下面用一個(gè)實(shí)際例子說(shuō)明。3.1 一個(gè)能跑通的 .proto 示例訂單報(bào)文定義我習(xí)慣從業(yè)務(wù)里抽一個(gè)常見(jiàn)結(jié)構(gòu)——訂單包含訂單號(hào)、客戶(hù)名、金額、貨品編碼、狀態(tài)。下面是這樣一個(gè) proto2 定義syntax proto2; package demo.order; message OrderInfo { required int32 order_id 1; required string customer_name 2; optional double total_amount 3 [default 0.0]; repeated string item_codes 4; enum OrderStatus { PENDING 0; PAID 1; SHIPPED 2; } optional OrderStatus status 5 [default PENDING]; }重點(diǎn)說(shuō)明幾個(gè)語(yǔ)法元素。第一行syntax proto2;是文件級(jí)聲明老版本里可以省略默認(rèn)就是 proto2但建議顯式寫(xiě)清楚給后來(lái)讀代碼的人一個(gè)明確信號(hào)。package避免不同模塊之間消息名沖突編譯進(jìn)代碼后會(huì)變成 C 的命名空間、Java 的包名Python 里則作為模塊命名前綴。message是核心定義單位內(nèi)部可以放標(biāo)量字段、枚舉、嵌套 message。2.6.0 版本對(duì) map 的支持不完整常見(jiàn)做法是用 repeated 字段模擬鍵值對(duì)或者干脆評(píng)估升級(jí)版本這一條在第六章展開(kāi)。另一個(gè)要注意的是repeated 字段在 proto2 里默認(rèn)是“非 packed”編碼每個(gè)元素單獨(dú)攜帶 tag所以小批量高頻消息的體積會(huì)偏大如果明確加[packed true]則會(huì)用連續(xù)數(shù)組形式編碼字節(jié)數(shù)能降不少。3.2 required、optional、repeated 與字段編號(hào)規(guī)劃這三種修飾詞是老 protocol buffers 的核心細(xì)節(jié)如下修飾詞語(yǔ)義序列化時(shí)缺值的行為required必須有值序列化/反序列化都會(huì)直接報(bào)錯(cuò)optional可以有值沒(méi)有就用默認(rèn)值值不寫(xiě)入字節(jié)流反序列化取默認(rèn)值repeated可重復(fù)列表無(wú)元素時(shí)不寫(xiě)入字節(jié)流required 看起來(lái)是最自然的“必填”約束但生產(chǎn)環(huán)境里是個(gè)大坑。你想給老接口加新字段如果標(biāo)成 required而下游還沒(méi)升級(jí)反序列化時(shí)直接拋異常線(xiàn)上全線(xiàn)報(bào)錯(cuò)。后來(lái) proto3 官方把 required 移除了不是沒(méi)理由的。optional 的行為要注意沒(méi)有顯式賦值時(shí)序列化根本不寫(xiě)進(jìn)字節(jié)流讀取端拿到的是默認(rèn)值。2.6.0 里給 optional 標(biāo)[default ...]能讓默認(rèn)值意圖更清晰不標(biāo)的話(huà)數(shù)值類(lèi)型默認(rèn)是 0字符串默認(rèn)空串bool 默認(rèn) false。字段編號(hào)是字節(jié)兼容性的關(guān)鍵。1 到 15 的編號(hào)在二進(jìn)制里只占 1 個(gè)字節(jié)的 tag 開(kāi)銷(xiāo)16 以上占 2 個(gè)字節(jié)。編號(hào)一旦定下來(lái)就不能改、不能復(fù)用。同一個(gè) message 里不能有重復(fù)編號(hào)字段改了編號(hào)老數(shù)據(jù)就全讀不出來(lái)了。維護(hù) proto 文件時(shí)我會(huì)在注釋里維護(hù)一張編號(hào)占用表防止團(tuán)隊(duì)里有人隨手加編號(hào)引發(fā)沖突。3.3 protoc 編譯命令與生成文件的組織方式寫(xiě)好 .proto 文件之后用 protoc 編譯# 生成 C 代碼 protoc --cpp_out. order.proto # 生成 Java 代碼 protoc --java_out. order.proto # 生成 Python 代碼 protoc --python_out. order.proto--cpp_out后面的路徑是輸出目錄.表示當(dāng)前目錄。C 輸出的是 order.pb.h 和 order.pb.ccJava 輸出的是按 package 目錄結(jié)構(gòu)擺放的 .java 文件Python 輸出的是 order_pb2.py。生成文件的命名由 .proto 文件名決定不是由 message 名決定這一點(diǎn)在第一次用時(shí)會(huì)有點(diǎn)意外。再看另一種常見(jiàn)情形.proto 文件分散在不同目錄并且相互之間有 import就要加 -I 參數(shù)指定搜索路徑protoc -I./protos --cpp_out./build ./protos/order.proto這里的 -I 是 include pathprotoc 遇到 import 時(shí)按這個(gè)路徑找依賴(lài)。路徑寫(xiě)錯(cuò)時(shí)最常見(jiàn)的癥狀是報(bào)“File not found”但真正的 .proto 文件是存在的只是 -I 沒(méi)覆蓋到它的目錄。排查時(shí)先看 import 的路徑是相對(duì)誰(shuí)的再檢查 -I 是否指向了正確根目錄。4. protobuf 2.6.0 序列化與反序列化C / Java / Python 的三種寫(xiě)法協(xié)議定義好、代碼生成好剩下就是三類(lèi)操作賦值、序列化寫(xiě)入、反序列化讀取。同一份 OrderInfo 消息三種語(yǔ)言寫(xiě)起來(lái)風(fēng)格差異很明顯但序列化出來(lái)的字節(jié)流完全一致這是 protobuf 最實(shí)用的特性——不同語(yǔ)言的服務(wù)之間可以直接互讀。4.1 C用 SerializeToString 與文件流讀寫(xiě)C 生成代碼里每個(gè) message 對(duì)應(yīng)一個(gè)類(lèi)字段的 setter 和 getter 規(guī)則固定。下面是賦值和序列化的常見(jiàn)寫(xiě)法#include order.pb.h #include fstream #include iostream int main() { demo::order::OrderInfo order; order.set_order_id(1001); order.set_customer_name(某客戶(hù)); order.set_total_amount(199.9); order.add_item_codes(SKU-001); order.set_status(demo::order::OrderInfo::PAID); std::string buffer; if (!order.SerializeToString(buffer)) { std::cerr serialize failed std::endl; return 1; } std::ofstream out(order.bin, std::ios::binary); out.write(buffer.data(), buffer.size()); out.close(); // 反序列化 demo::order::OrderInfo parsed; std::ifstream in(order.bin, std::ios::binary); std::string data((std::istreambuf_iteratorchar(in)), std::istreambuf_iteratorchar()); if (!parsed.ParseFromString(data)) { std::cerr parse failed std::endl; return 1; } std::cout parsed.order_id() std::endl; return 0; }代碼邏輯簡(jiǎn)單但注意幾個(gè)點(diǎn)。序列化函數(shù)返回 bool不能忽略失敗原因通常是 required 字段未賦值。反序列化同樣返回 bool失敗原因最常見(jiàn)的是字節(jié)流不是合法的 protobuf 格式或 required 字段缺失。文件讀寫(xiě)務(wù)必用 binary 模式文本模式下 Windows 系統(tǒng)會(huì)做換行轉(zhuǎn)換導(dǎo)致讀進(jìn)來(lái)的數(shù)據(jù)被悄悄改壞。我排查線(xiàn)上詭異問(wèn)題十次里有幾次都?xì)w結(jié)到這類(lèi)寫(xiě)文件方式。從 2.6.0 開(kāi)始C API 還提供ParseFromArray和SerializeToArray處理已經(jīng)拿到字節(jié)數(shù)組的場(chǎng)景時(shí)不用先構(gòu)造 std::string能減少一次拷貝性能敏感路徑上值得用。4.2 JavaBuilder 模式與 toByteArrayJava 生成代碼的差異化比較大2.6.0 通常是不可變 message 類(lèi)加一個(gè)嵌套 Builder 來(lái)構(gòu)建對(duì)象import demo.order.OrderInfoOuterClass; OrderInfoOuterClass.OrderInfo order OrderInfoOuterClass.OrderInfo.newBuilder() .setOrderId(1001) .setCustomerName(某客戶(hù)) .setTotalAmount(199.9) .addItemCodes(SKU-001) .setStatus(OrderInfoOuterClass.OrderInfo.OrderStatus.PAID) .build(); byte[] data order.toByteArray(); OrderInfoOuterClass.OrderInfo parsed OrderInfoOuterClass.OrderInfo.parseFrom(data);代碼里OrderInfoOuterClass這個(gè)名字源于 proto 文件叫 order.proto生成的 Java 類(lèi)外層會(huì)包一個(gè)同文件名的 OuterClass這是 2.6.0 的默認(rèn)行為不必覺(jué)得奇怪。Java 序列化后的字節(jié)數(shù)組可以放進(jìn)流里寫(xiě)文件、發(fā)消息隊(duì)列甚至直接塞進(jìn) HTTP body。反序列化用parseFrom靜態(tài)方法入?yún)⑹?byte[]內(nèi)部會(huì)做完整校驗(yàn)。有一個(gè)點(diǎn)要提醒build()在 required 字段缺失時(shí)會(huì)拋UninitializedMessageException這一點(diǎn)和 C 的SerializeToString返回 false 是對(duì)應(yīng)的但 Java 是直接拋異常沒(méi)有返回值要敢于接住它別讓異常從服務(wù)里裸穿。4.3 Python直接屬性賦值與 ParseFromStringPython 生成代碼用起來(lái)最接近直覺(jué)import order_pb2 order order_pb2.OrderInfo() order.order_id 1001 order.customer_name 某客戶(hù) order.total_amount 199.9 order.item_codes.append(SKU-001) order.status order_pb2.OrderInfo.PAID buf order.SerializeToString() print(len(buf)) parsed order_pb2.OrderInfo() parsed.ParseFromString(buf) print(parsed.order_id, parsed.customer_name)Python 的字段賦值直接對(duì)應(yīng) .proto 字段名repeated 字段語(yǔ)法上就是列表可以 append、extend。要注意的是Python 運(yùn)行時(shí)對(duì) required 字段的檢查發(fā)生在 SerializeToString 調(diào)用時(shí)拋的是 EncodeError。我在清理舊腳本時(shí)多次踩到同一類(lèi)坑一個(gè)字段明明寫(xiě)在 proto 文件里Python 代碼里卻忘了賦值序列化時(shí)直接炸報(bào)錯(cuò)信息不會(huì)指明哪個(gè)字段排查起來(lái)只能逐字段復(fù)查。三種語(yǔ)言序列化出來(lái)的字節(jié)流完全一致同一條消息在不同語(yǔ)言間互讀沒(méi)有障礙。我經(jīng)常在一套系統(tǒng)里用 C 端寫(xiě)入、Python 端讀取做聯(lián)調(diào)只靠 protobuf 就把語(yǔ)言差異消化掉了。5. protobuf 2.6.0 常見(jiàn)問(wèn)題排查五個(gè)繞不開(kāi)的兼容性與編譯坑序列化工具總有一些讓人防不勝防的怪問(wèn)題protobuf 2.6.0 作為老版本更不例外。下面這幾條是我在不同環(huán)境里反復(fù)遇到的按“現(xiàn)象→原因→解決”的模式寫(xiě)方便直接對(duì)照。5.1 生成代碼與運(yùn)行時(shí)版本不一致報(bào)警發(fā)生在運(yùn)行期現(xiàn)象protoc 編出來(lái)的代碼編譯期正常程序一跑就報(bào) NoSuchMethodError或者 Python 端 import 時(shí)報(bào) TypeError內(nèi)容指向某個(gè)不存在的函數(shù)或?qū)傩浴Ｔ蚓幾g生成代碼時(shí)用的 protoc 是 2.6.0但程序運(yùn)行時(shí)鏈接的 libprotobuf 是系統(tǒng)里另一個(gè)版本。生成代碼依賴(lài)的 API 簽名隨版本變化老代碼調(diào)新運(yùn)行時(shí)或者新代碼調(diào)老運(yùn)行時(shí)都會(huì)在運(yùn)行期暴露缺失。解決確認(rèn)全鏈路版本一致。用構(gòu)建工具管理依賴(lài)時(shí)把 protoc 版本和運(yùn)行時(shí)版本同時(shí)鎖到一個(gè)固定值。我習(xí)慣加一條構(gòu)建檢查編譯階段輸出protoc --version再結(jié)合依賴(lài)清單打印運(yùn)行時(shí)版本從源頭避免這個(gè)問(wèn)題。5.2 required 字段缺失導(dǎo)致反序列化拒絕現(xiàn)象下游服務(wù)拿到上游消息后反序列化失敗錯(cuò)誤是 PARSE_ERROR但字節(jié)流里能看到大部分字段都對(duì)。原因message 定義里有 required 字段發(fā)送方漏填。反序列化時(shí)解析器發(fā)現(xiàn) required 字段不存在直接判定消息非法。這條規(guī)則在 2.6.0 里不可繞過(guò)。解決要么發(fā)送方把字段補(bǔ)上要么把該字段從 required 改成 optional 再重新發(fā)布。后者對(duì)已落盤(pán)的數(shù)據(jù)不友好所以更推薦的做法是制定協(xié)議時(shí)盡量避免 required。跨團(tuán)隊(duì)聯(lián)調(diào)時(shí)這個(gè)問(wèn)題最難受因?yàn)閳?bào)錯(cuò)不直接告訴你缺什么字段要寫(xiě)一段解析代碼把字節(jié)流按定義逐字段拆開(kāi)看才能定位到具體缺了誰(shuí)。5.3 現(xiàn)代編譯器編譯老版本源碼的 -Werror 翻車(chē)現(xiàn)象在較新的 Linux 發(fā)行版上用默認(rèn)參數(shù)編譯 protobuf 2.6.0 源碼make 到一半出現(xiàn)一堆 warning然后以 error 終止報(bào)錯(cuò)集中在舊代碼的模板和原子操作實(shí)現(xiàn)文件里。原因新版 GCC 或 Clang 對(duì)舊代碼中隱式類(lèi)型轉(zhuǎn)換、未使用變量和析構(gòu)函數(shù)行為的檢查更嚴(yán)格老版本構(gòu)建腳本里某些位置把 -Werror 打開(kāi)了warning 直接被當(dāng)成 error。解決用 configure 參數(shù)關(guān)掉 -Werror./configure --prefix/usr/local/protobuf-2.6.0 CXXFLAGS-Wno-error另外遇到這類(lèi)問(wèn)題make 時(shí)先不帶 -j 串行執(zhí)行方便定位具體是哪個(gè)文件掛了。這條思路適合在老版本編譯吃不消時(shí)優(yōu)先嘗試實(shí)測(cè)能解決大部分現(xiàn)代工具鏈兼容問(wèn)題。5.4 改字段編號(hào)把線(xiàn)上兼容性改丟了現(xiàn)象某天重新梳理 proto 文件把某個(gè)字段編號(hào)從 4 改成 8程序編譯正常但舊數(shù)據(jù)全部讀不出來(lái)反序列化結(jié)果錯(cuò)亂甚至出現(xiàn)字段類(lèi)型錯(cuò)配。原因protobuf 的兼容性完全依賴(lài)字段編號(hào)不依賴(lài)字段名。改名不影響兼容換編號(hào)就相當(dāng)于換了新協(xié)議。老字節(jié)流里編號(hào) 4 的字節(jié)會(huì)被當(dāng)成未知字段新協(xié)議里編號(hào) 8 的字段拿不到數(shù)據(jù)required 字段順理成章地缺失。解決維護(hù) proto 文件時(shí)把字段編號(hào)當(dāng)成不可變資產(chǎn)新增字段只能用未占用編號(hào)。歷史包袱太重時(shí)可以在文件里寫(xiě)reserved注釋或字段名標(biāo)記但絕不要復(fù)用編號(hào)。我在項(xiàng)目里定了一條規(guī)矩協(xié)議評(píng)審時(shí)先看 diff 的編號(hào)列再看字段類(lèi)型名字最后看——編號(hào)錯(cuò)了是災(zāi)難名字錯(cuò)了是小事。5.5 枚舉未知值在跨語(yǔ)言讀取時(shí)行為不一致現(xiàn)象C 服務(wù)收到一個(gè)枚舉字段的新值序列化發(fā)送給 Java 服務(wù)Java 端反序列化時(shí)拋 InvalidProtocolBufferException 或提示枚舉值非法。原因proto2 的枚舉在定義上是封閉集合但 C 實(shí)現(xiàn)往字節(jié)流里寫(xiě)整數(shù)時(shí)并不檢查它是否在定義范圍內(nèi)Java 運(yùn)行時(shí)在解析字節(jié)流時(shí)會(huì)校驗(yàn)枚舉值不在集合內(nèi)的直接報(bào)錯(cuò)。于是同一個(gè)字節(jié)流在兩種語(yǔ)言實(shí)現(xiàn)里行為不一致。解決給可能擴(kuò)展的枚舉預(yù)留一個(gè) UNKNOWN 0 值或者直接用 int32 字段替代枚舉在業(yè)務(wù)層做映射。如果協(xié)議已經(jīng)發(fā)布不能改只能在業(yè)務(wù)側(cè)約定新枚舉值必須在兩端同時(shí)升級(jí)。這個(gè)問(wèn)題在跨語(yǔ)言聯(lián)調(diào)時(shí)非常隱蔽因?yàn)?C 端自測(cè)永遠(yuǎn)測(cè)不出來(lái)。6. protobuf 2.6.0 之后的取舍升級(jí)自檢清單與字節(jié)流回放驗(yàn)證6.1 升級(jí)前先跑一遍自檢清單我面對(duì)每個(gè)遺留系統(tǒng)都會(huì)先做一個(gè)快速評(píng)估清單如下proto 文件里 required 字段的數(shù)量超過(guò) 5 個(gè)基本不建議立即升級(jí)遷移成本會(huì)集中在數(shù)據(jù)清洗有沒(méi)有依賴(lài)舊版特有的隱式默認(rèn)值、擴(kuò)展機(jī)制等特性所有使用方語(yǔ)言是否都有兼容的運(yùn)行時(shí)缺一個(gè)就可能導(dǎo)致聯(lián)調(diào)斷裂有沒(méi)有無(wú)法讀回的老數(shù)據(jù)文件有的話(huà)要先做數(shù)據(jù)遷移或兼容讀層如果 required 多、跨語(yǔ)言多、歷史數(shù)據(jù)多留在 2.6.0 反而更穩(wěn)。如果只是新業(yè)務(wù)疊加協(xié)議文件沒(méi)有老包袱那值得評(píng)估升級(jí)到新版本。6.2 用字節(jié)流回放測(cè)試驗(yàn)證兼容性驗(yàn)證升級(jí)兼容性最直接的方法是把同一批歷史字節(jié)流保存下來(lái)分別用兩代運(yùn)行時(shí)反序列化逐字段對(duì)比。下面是一個(gè)參考腳本# 保存歷史字節(jié)流并驗(yàn)證兩代運(yùn)行時(shí)解析結(jié)果 import order_pb2 payloads read_all(historical_payloads.bin) for idx, payload in enumerate(payloads): msg order_pb2.OrderInfo() if not msg.ParseFromString(payload): print(fitem {idx}: parse failed) continue print(fitem {idx}: order_id{msg.order_id}, status{msg.status})在新版本環(huán)境里跑這個(gè)腳本檢查是否存在解析失敗或字段值變化。我一般還會(huì)加一個(gè)更狠的反向測(cè)試把新版本序列化出來(lái)的字節(jié)流丟回 2.6.0 環(huán)境里解析確保雙向兼容。兩個(gè)方向都通過(guò)才有底氣切換線(xiàn)上。說(shuō)句實(shí)在話(huà)老版本不是不能用是得知道自己手里的協(xié)議資產(chǎn)有多少、坑在哪些角落。把那批歷史字節(jié)流留檔、把回放測(cè)試套件跑通、把字段編號(hào)的紀(jì)律立住剩下的就是時(shí)間問(wèn)題。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取