协议演变

    搬过来广州一个多月了，50号人。这样搬迁。不知道老板是如何想的。托词是广州easy招到人，也问过我是愿意到广州还是留在珠海。一个月前婆婆还在世，当然选择近一点的广州，如今的话。去哪都一样，跑到深圳，或者是苏杭体验一下生活，也非常不错。至于安居乐业，暂难打算。

    这段时间是跟着需求改啊改，新增些什么功能。修些什么BUG，隔三差五就部署部署。进度缓下来了，然后又说转golang。这，真要想想。收获也并非没有。仅仅是也慢了下来，对协议扩展性、存储扩展性能等的问题考虑也更加多了点，保守来算个人能力肯定也是上去了些吧，至少说什么千万级亿级用户什么的，也不是那么胆怯，毕竟扩展方案就在这。

    协议的变化跟需求关系有点密切。由于项目上传量巨大。所以正常的http协议好像真有点食不消，详细往下看。

    这一開始项目是直接套上HTTP协议，用上最传统的传输方法，application/x-www-form-urlencoded。由于開始时候接口定义就是用户注冊。登录，简单的申请带的POST參数十分少。接着POST的内容多了。底层的协议也懒得改了，參数来直接就塞一个urlencoded的JSON进去... 高速开发嘛... 由于当时定义參数的时候各种校验參数与固定參数好几项，改成POST一个JSON感觉就是折腾，事实上这期间也想过改别的对象协议，不用JSON，但计划赶不上变化，需求一罗罗，仅仅能这样了。况且JSON各种支持也比較好，包含流式解析什么的都有了。就不折腾了。

    慢慢地，各种需求搞得上传量越来越大，调用各种接口越来越多，简化了一下下。开发了个新接口取代了所有相似的接口。

既然都这样变化了。自然也就想着一大块JSON上传上来，离奇的是，我们想到在request里面也加个gzip，详细达到多少字节才压缩这个也不好说，由于字符串短的时候压缩是多余的。这样事实上就对http协议做了非常大修改了，为了高速开发（又是为了快-。-）。竟然gzip压缩仅仅是直接压缩一个最大块头的參数，其它各种校验參数也原封不懂，好吧。人类你们赢了。

    非常好的想法再一次被人类的懒惰打赢。搞得协议光怪陆离，事实上这变得这么多，根本就没有必要用HTTP协议的了，各种HTTP头也是废的。干脆也是别要算了，直接上TCP+JSON，协议用透了，各种什么长连接特性什么的，也离不开TCP完整的支持，技术上来之后，事实上直接用所谓的低级协议。事实上不会不比上层协议靠谱，考虑肯定要比上层协议要好，尽管可能仅仅是一点点。

    像这样的特殊项目事实上一開始就不应该上HTTP。不是一个站点就不应该拿HTTP来干。如今的各种HTTP JSON API事实上都属于有点诡异，上HTTP的原因是一開始就交给我这么一个菜鸟去做，还要求原型出得快。从还有一个角度看这里一半的过程也是必经的，虽然你有经验了，项目角度还是须要逐步尝试，不是一蹶已就的，直接用最优的方法，开发速度还是会慢一点。