為什麼選擇protobuf
目前java常用的編解碼方案有：
xml
java序列化
xml
json
msgPack
protobuf
選擇編解碼方案的主要次元：
1.編碼後占用空間：
xml，java序列化 out！
2.編解碼速度，占用記憶體：
xml，java序列化 out！out！
3.多種程式設計語言支援：
java序列化 out！out！out！
xml，json best！
msgPack，protobuf good！
4.是否追求可讀性：
json，xml good！
msgPack，protobuf bad！
5.社群關注度
以下是截止目前github上的資料
MsgPack:
msgPack關注度不少，但截止目前github最近一次更新是2018年。慎選。
Protobuf：
Flatbuffers:
可以看出主流的幾個編解碼方案github關注度都挺高，其中protobuf關注度度最高。
性能對比
綜合上面各個次元的權衡，protobuf、msgPack都是比較有前途的編解碼方案。如果要兼顧可讀性的話，json編解碼方式還是可以的。
從網上查了下集中編解碼方案的性能對比。找到一個19年的文章，隻有有限的實驗對照，個人認為不嚴謹。僅做參考。
連結：【優化】序列化庫的選擇(FlatBuffers,ProtoBuf,MessagePack,Json)
另外一篇實驗了json，protobuf和msgPack間的性能比較，從小檔案，大檔案，請求數量，編解碼速度，錯誤率等多個次元進行了對照。結論是msgPack和protobuf都明顯優于json，msgPack在小檔案下更有優勢。
連結：The need for speed — Experimenting with message serialization
netty上編解碼方案選擇
優先選protobuf。無他，netty對protobuf編解碼方案做了非常漂亮的內建，其次protobuf本身也足夠優秀。