为什么选择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本身也足够优秀。