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主机上要修改以后才能用

 

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