MSGPACK和PROTOBUF的故事(MSGPACK明显生产力不足)

作者曾经在2014年测试出MSGPACK的关键字和中文字符有很大的冲突,所以后来放弃了,本文为很多年前写的一个对比,后来我们一直在使用HTTP协议和PROTOBUF。

看看MSGPACK的文档,自称效率高于其他同类产品最高8倍,很诱人吧?来看看我的故事吧

首先很多项目是跨语言的,我们也不例外前端AS3,后端C++,本身我是冲着MSGPACK支持语言多,效率高用的,因为都知道AS3本身效率很低,如果解析效率低就悲剧了,这个时候我还没开始使用PROTOBUF,也从来没用过PROTOBUF,至少我否定了很多开发者说要用PROTOBUF的观点,然后强压下迫使他们使用MSGPACK,接着开始了漫长的整合,不要迷信官方的那些第三方库,大部分都不更新了这是其次,重点是你自己是需要做出很多修改的,我们为了让他可以完整的支持跨语言对应对象,对AS3我们做出大量修改,最终可以勉强对应部分内容,但是要注意的事情还是很多,这个时候的MSGPACK还是很脆弱的,至少在AS3上来说。

 

接着第一个悲剧发生了,这里其实我比较庆幸他发生在项目初期而不是项目中后期,根据快速开发原则,如果发生在中后期我所付出的成本远远要大于开发这个系统本身3~15倍甚至还多,这个悲剧就是中文发送文本出现截断,而截断的发生方是服务器端,也就是C++版本由官方提供的解析类库,你以为我会马上放弃MSGPACK?你错了,我马上去找了解决方法,调试,读MSGPACK大量文档,最终我发现的GBK的文本中含某个汉字拆开的字节中含有0xce,而这个实际上是代表MSGPACK的UINT32的,所以可想而知这里开始发生截断,无法继续分析,接着服务器端崩溃。

 

不幸的是这不是最大的问题,接着我的确找到的解决方案BASE64,方案的代价是我必须多写一个LAYER来处理BASE64的转换,其次使用复杂度和自由度上明显出现差别,数据包略微增大,此劫暂时渡过了,接下来我发现,我需要教会其他人怎么使用MSGPACK来打包数据包。

 

接下来的几天内我又写了更加简单的组合类,但是我发现还是很复杂,至少需要3行才能发送一个MSGPACK,但是还好至少三行了。

接着其他人开始学习使用MSGPACK,这时距离我刚刚选定MSGPACK已经过去2周了,当然我觉得这是新东西应该这样,接下来的噩梦来了。

第一个包LOGIN_SYN,我们开始协调每个细节可有一个很麻烦的问题,SESSION CODE是INT64,如何对应AS3,我们测试很久后来还是自己写了BIGINT类,然后完成对应,噩梦越来越多。

 

直到有一天,所有人开始抱怨这东西难用,要写很多额外的PROTOCOL类的时候,迫于团队压力我决定试试PROTOBUF。

 

而接下来我感到震惊从使用开始到直接投入生产,我们仅仅用了4个小时,而这4个小时我们大部分时间花费在让PROTOBUF的工具可以产生AS3的协议类。

我们做法是:

1、找到最新的PROTOBUF官方源码 (5分钟左右,含下载时间)

2、编译C++版本的WINDOWS工具(10~15分钟左右,含编译时间,全版本编译包括C++类库)

3、找到AS3生成类和AS3的解析类放入AS3项目(2个小时左右,下载与项目整合,修改底层时间)

4、接着编译和整合C++版本的工具(1小时20分左右,把AS3的生成代码放入工具,整合修改C++底层,然后编译)

5、接下来发送第一个包(30分钟左右,写一个协议并生成,做个批处理自动生成AS3和C++类)

*以上记时是为某人无聊记得,这里刚好拿来用了,他是PROTOBUF主张派,非要记录时间看看能缩短多少。

前后我们仅仅用了4个小时,我是第一次使用PROTOBUF,但是它简单到让我震惊,我真的从没想过写协议可以如此简单。

 

接着我仅仅封装了一下我的协议和AS3的发送类做对接整合,仅需2行代码,就可以发送完整包,而所有的写类均可以通过工具生成整合,整个研发时间缩短了太多太多,而且几乎不用教学,所有新手学会如何使用PROTOBUF。

 

看到上面你们就知道,对于生产力的问题上,效率上说的天花乱坠也是扯淡,现在回想使用MSGPACK生产,光写PROTOCOL的类我想我们的成本就不知道要多少,而且我们要重新维护一个HTML的协议文档或WIKI(方便在线查阅),让前端同事明白,否则必定大乱。

 

目前我们已经使用PROTOBUF整合了40几个数据包,包括服务器之间,客户端服务器之间等,我们仅仅需要一个叫做SVN的东西就可以让客户端同事100%明白这个协议发来的是什么和他要处理什么,我一直是写自有协议的总是要解释很多,还要加很多注释,可我现在认为PROTOBUF才是王道啊,太快了。

 

如果你是负责的总监或负责的老板,请不要让员工浪费时间在毫无意义的事情上,甚至为此付出巨大的代价,而生产力低下往往会拖垮你整合项目甚至让你破产。

 

由此深刻的感受到,MSGPACK实际生产力相对于PROTOBUF并不高,不管效率如何高,其实对于多人协调的项目以及跨语言项目他仍旧是个很麻烦的东西。

 

这两者最大的区别应该是PROTOBUF是为了快速生产而诞生的,而MSGPACK不是,所以在正规项目中用MSGPACK和PROTOBUF也毫无疑问的是PROTOBUF 

你可能感兴趣的:(MSGPACK和PROTOBUF的故事(MSGPACK明显生产力不足))