为什么选择protobuf
目前java常用的编解码方案有：
xml
java序列化
xml
json
msgPack
thrift
protobuf
选择编解码方案的主要维度：
1.编码后占用空间：
xml，java序列化 out！
2.编解码速度，占用内存：
xml，java序列化 out！out！
3.多种编程语言支持：
java序列化 out！out！out！
xml，json best！
msgPack，thrift，protobuf good！
4.是否追求可读性：
json，xml good！
msgPack，thrift，protobuf bad！
5.社区关注度
以下是截止目前github上的数据
MsgPack:
msgPack关注度不少，但截止目前github最近一次更新是2018年。慎选。
Thrift:
Protobuf：
Flatbuffers:
可以看出主流的几个编解码方案github关注度都挺高，其中protobuf关注度度最高。
性能对比
综合上面各个维度的权衡，protobuf、msgPack和thrift都是比较有前途的编解码方案。如果要兼顾可读性的话，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本身也足够优秀。