protocbuf的简单理解

　　之前通信协议替换为protocbuf！新老交替，很多不同看法，也提出来一些负面因数：

　　1、老的内部通信协议体已经有一段时间了，稳定熟悉！

　　2、通过通信结构体进行交互，实际上并没有序列化和反序列化的过程！性能几乎零损耗

　　3、通信异常直接可以通过日志打印出来，定位问题时候可以直接查看关键信息

　　4、由于老代码用的是内部封装的通信结构体，几乎所有的老代码都直接或间接的引用了老通信协议体，替换工作量比较大

　　也存在另外一种正面意见：

　　1、老代码陈旧冗余，新增接口或修改接口让人头疼

　　2、需要业务层考虑字节序问题

　　3、由于是内存偏移操作，程序员风格的差异让整个协议文件变的很乱！更致命的是一旦发生错误定位起来非常困难

　　4、另外还有一些内部通信体限制问题

 

　　无论替换过程怎样，项目的车轮还在前进！protocbuf已经在产品中落地生根，一小段周期的接触，总结下：

　　protocbuf是google的一个开源项目，很多互联网公司早就在用了，像百度、腾讯这些巨头，而且在github里面的关注度也是一直颇高。

　　它也有很多的优势，从我的角度看最明显的是序列化速度快，而且序列化之后字节非常少。

　　就我之前所接触的几种序列化，JSON、SAMP、ASN.1性能都不如protocbuf，ASN.1和protocbuf组织有点像，都是树状结构！

　　但是ASN.1协议体除了TAG还需要一些辅助信息，对数据的编码也缺少压缩，像DCC、SOAP等网络协议性能更低。

　　另外protocbuf还有缓存机制、结构体式接口、兼容性等等一系列的优点

 

　　虽然protocbuf有着明显性能和压缩的优势，虽然这种网络通信里面至关重要，但是我们更关注其缺点：

　　1、protocbuf只提供序列化和反序列化的能力，如果用在网络通信里面，需要再封装。

　　2、protocbuf序列化之后可读性差，对抓包后面的码流分析起来非常困难，毕竟有时候工具不是万能的，手工是终极绝招

　　3、protocbuf描述性文档比较少，目前也没有普遍推广

　　另外是开发过程中的一些问题

　　4、protocbuf repeated类型，如果想替换已经加入的一个子元素，那几乎要重写所有的元素

　　5、protocbuf在没有数据传输的时候，序列化出来的长度是0.虽然这种做法提高了序列化性能和压缩了数据，但是在空数据的情况下，占位符对程序设计影响颇大

　　6、protocbuf版本在hp主机上要修改之后才能用

 

　　暂时就这么多吧，我也不知道还要多少坑等着我们，路过的兄弟请提点！