protocbuf的簡單理解

　　以前通訊協議替換爲protocbuf！新老交替，不少不一樣見解，也提出來一些負面因數：

　　一、老的內部通訊協議體已經有一段時間了，穩定熟悉！

　　二、經過通訊結構體進行交互，實際上並無序列化和反序列化的過程！性能幾乎零損耗

　　三、通訊異常直接能夠經過日誌打印出來，定位問題時候能夠直接查看關鍵信息

　　四、因爲老代碼用的是內部封裝的通訊結構體，幾乎全部的老代碼都直接或間接的引用了老通訊協議體，替換工做量比較大

　　也存在另一種正面意見：

　　一、老代碼陳舊冗餘，新增接口或修改接口讓人頭疼

　　二、須要業務層考慮字節序問題

　　三、因爲是內存偏移操做，程序員風格的差別讓整個協議文件變的很亂！更致命的是一旦發生錯誤定位起來很是困難

　　四、另外還有一些內部通訊體限制問題

 

　　不管替換過程怎樣，項目的車輪還在前進！protocbuf已經在產品中落地生根，一小段週期的接觸，總結下：

　　protocbuf是google的一個開源項目，不少互聯網公司早就在用了，像百度、騰訊這些巨頭，並且在github裏面的關注度也是一直頗高。

　　它也有不少的優點，從個人角度看最明顯的是序列化速度快，並且序列化以後字節很是少。

　　就我以前所接觸的幾種序列化，JSON、SAMP、ASN.1性能都不如protocbuf，ASN.1和protocbuf組織有點像，都是樹狀結構！

　　可是ASN.1協議體除了TAG還須要一些輔助信息，對數據的編碼也缺乏壓縮，像DCC、SOAP等網絡協議性能更低。

　　另外protocbuf還有緩存機制、結構體式接口、兼容性等等一系列的優勢

 

　　雖然protocbuf有着明顯性能和壓縮的優點，雖然這種網絡通訊裏面相當重要，可是咱們更關注其缺點：

　　一、protocbuf只提供序列化和反序列化的能力，若是用在網絡通訊裏面，須要再封裝。

　　二、protocbuf序列化以後可讀性差，對抓包後面的碼流分析起來很是困難，畢竟有時候工具不是萬能的，手工是終極絕招

　　三、protocbuf描述性文檔比較少，目前也沒有廣泛推廣

　　另外是開發過程當中的一些問題

　　四、protocbuf repeated類型，若是想替換已經加入的一個子元素，那幾乎要重寫全部的元素

　　五、protocbuf在沒有數據傳輸的時候，序列化出來的長度是0.雖然這種作法提升了序列化性能和壓縮了數據，可是在空數據的狀況下，佔位符對程序設計影響頗大

　　六、protocbuf版本在hp主機上要修改以後才能用

 

　　暫時就這麼多吧，我也不知道還要多少坑等着咱們，路過的兄弟請提點！