為什麼大廠這麼愛用protobuf？ https://mp.weixin.qq.com/s/COQu3rckfZJUelSVBV6IMA
為什麼大廠這麼愛用protobuf？
話題背景
在protobuf在國內興起的時候，json over http 的 RESTful ，api也在國內同步興起了。司內也有很多api是tRPC寫的，很多是基於protobuf的，也有很多就是 json over http 的。那麼有同事就有這個疑問了：這裡面只有protobuf的資料結構最複雜，而且開啟任意一個 protobuf 的 java 檔案都會讓機器卡頓很厲害，很難想象前人在透過protobuf 來理解資料結構的時候，是不是一樣非常麻煩？
那麼推動我們使用這項技術，讓它們在很多團隊之間佔據統治地位的根本原因是什麼？是某些歷史團隊的背景偏好麼？該如何解決開啟檔案卡頓的問題？
今天就讓我們來一起聊聊“為什麼大廠這麼愛用protobuf？”
鵝廠工程師的看法
@ashui-IEG後臺開發工程師
▼
protobuf 的好處很多的，不只是序列化還有一些微服務介面宣告(IDL)。
序列化反序列化
序列化與反序列化的效能 這個不用多說，簡單瞭解下原理就能理解，效能肯定比json快。
這裡也有一個圖，之前同事分享的：
序列化：
反序列化：
這些在內部一些rpc 請求之間還是很可觀的。
IDL (Interface description language)
我們不妨回顧一下 如果 直接使用 json over http 開發介面的過程。
1. 編寫介面 定義路由 eg: /a/b/c
2. 定義好入參/出參結構 req struct rsp struct
3. 解析入參(解析http從 query or body 拿到入參 放入 req
4. 業務處理邏輯
5. 準備rsp struct 返回
對於小規模業務來說，或者說不怎麼迭代的系統來說，這樣確實還行。
但是隨著業務的發展，你現在有100個介面你其實根本無法維護這些介面的，比如 前端來找你 要知道 /a/b/c 介面的入參出參（介面文件），如果你們有維護 swagger 那還好說，不然你只能說一句我先去看下程式碼.....protobuf 的好處透過 pb 去定義Interface ，並且提供外掛能力能讓你自己去解析pb，開發自己。
比如 trpc-go 就是基於pb的介面定義+自行開發的外掛 去生成程式碼樁。
甚至如果你真的還是想用 json over http 的模式也行，用 pb 定義介面，透過自己開發外掛將 pb 生成http 程式碼樁，業務開發只需要關注 核心的 業務處理邏輯，其他都可以程式碼生成。
對於介面文件的維護完全都不需要專門去寫文件，你改了pb，文件就自己生成了....
當然你也可以去生成 swagger，前端 ts 結構，客戶端 java 介面..... 一套pb 大家一起享福。
隨著這些外掛開發的越多(生態也就好起來了）
@titus-IEG運營開發工程師
▼
說實話，我覺得jce比protobuf要好用，但是沒辦法，生態位置還是領先，開源元件全在用它。
@thomas-TEG後臺開發工程師
▼
舉個例子，json 沒有 schema，今天加個欄位，明天改個型別，到時候上下游對接都不知道 json裡面到底傳什麼型別。選 protobuf，變更的時候在程式碼倉庫裡至少知道改了那個欄位，上下游對接只要根據 schema 定義就知道。
@jinlong-PCG後臺開發工程師
▼
上家公司用過json，在c++裡面解析json簡直就是災難，因為不知道上游會傳過來啥，每次要先判斷是否存在這個欄位，然後再判斷型別是否正確，稍不注意就可能導致core。pb強 schema 且強制相容，在開發的時候能省不少工作量，減少一些異常失誤。當然缺點就是要看裡面的內容每次都要解析。
@ronaldo-IEG後臺開發工程師
▼
絕大多數用pb的團隊，考慮的首要問題都不是序列化效能。主要考慮
1. 需要一種統一的程式語言無關的方式來定義服務的介面，它就是文件，而且一定是最新的文件。它需要足夠有表達力，又足夠簡潔明瞭，其實就是IDL（可選：pb thrift）
2. 在IDL的前提下，找生態最好的，支援語言最多的（pb）
3. 在2的前提下找效能儘可能高的（不用挑了）
@erien-TEG資料工程師
▼
主要是強schema化吧，跨語言序列化需求才是其次的。資料結構復不復雜是業務的問題，你說的proto是ams大倉裡的proto吧，經過了這麼多年迭代也正常，idea使用的話建議忽略編譯生成的java檔案，直接用proto外掛識別proto檔案裡的欄位。
@andy-TEG應用研究工程師
▼
如果從實際使用情況來看：
1. rpc上的 capn proto, flatbuffers這些效率更高但社群不夠大
2. big data上基本都用上arrow了，protobuf現在很少了
3. web和相關的社群一直是json為主
另外從純編解碼效率來看，protobuf對比json的優勢不是格式問題而是實現問題(如果不是用json over http1.1 vs protobuf vs http2 aka grpc來對比的話)，所以感覺還是各個社群的歷史原因吧。
@quinn-TEG應用開發工程師
▼
Json重在可讀性，一般前端互動用很廣泛，小巧且便於除錯。Protobuf重在高效能，在效能要求較高的地方，比如後端協議這塊比較有優勢，除錯起來沒json順手，因為是二進位制的，非明文。
@chair -IEG SRE工程師
▼
手遊當年剛起來的時候， 世界行動網路大多處於2G和3G的狀態，當時我去了神奇公司內，入職要算八字的那家。他們的大廳就是用json傳的資料。我過去之後，看了一下pb的特徵，就選定用pb替換json。結果原本要12秒才載入完畢的大廳列表，用了pb，3秒，使用者反應快了很多。