最近项目架构及协议决策

 

 

最近给自己换了个老板，忙了一段时间，所以有几个月没写博客，今后还是要争取多写啊，呵呵。

 

换来新地方，第一件大的事情就是修改后端架构和通信协议，架构也设计得很普通，因为这边的业务不需要太过复杂的后端，所以就简单设计了一下，基本是参照web的模型，符合我一贯的向web学习的思想，弄了个gate管理入口，相当于web下的webserver，后端其他服务器挂在该gate下，相当于web模型下的appserver，或者fastcgi模型的fastcgi进程，gate上管理连接、合法性检测、登录、加密、压缩、缓存。Gate和后端通信本来想参照fastcgi协议，但看了之后觉得fastcgi协议还是复杂了，所以就设计了一个更简单的协议，gate和后端server之间可传递key:value型数据对，value不局限于字符串，可以是任意数据，这样基本满足了当前的需求，第一版放上去之后也运行良好，到今天也基本持续稳定运行快一个月了，没出过什么事情。由于在gate这边缓冲了job管理，所以后端server升级很方便，随时可关闭更新，gate会在窗口时间内将未执行完成的任务重新提交，有此功能可放心大胆的升级后端，这个月这样的工作做了几次，在架构修改之前这样的事情几乎是不敢做的，因为一旦升级所有用户全部断开连接，而现在用户则基本无感觉。Gate上的缓存层为后端减少了一些压力，这个缓存是按照请求的md5为key做的，并根据协议配置时效，有此cache后端大多数服务可不设计缓存或降低缓存设计的复杂度。Gate上针对敏感数据统一做了加密处理，主要是辛辛苦苦整理的数据不能轻易让竞争对手窃去了，呵呵。Gate也做了压缩，现在是针对>=128长度的包进行压缩，使用了qlz，压缩效率还是很不错的，速度很快。目前gate后端挂接的既有win上的server也有linux上的server，这是一开始就这么规划的，现在看来当初的目的达到了，混合发挥各自的优势，有的项目在原有系统上跑得好好的，没必要重新开发嘛。

 

协议设计上本来我是计划二进制混合json格式，以二进制为主，但尝试了一个协议之后发现，这边的小伙子们对直接操纵内存普遍技术不过关，他们大多是从java开始的，后来才学习c，对字符串用得很熟练，权衡之下采用了json为主，混合二进制为辅的方案，这样修改之后的协议和他们之前使用的xml类似，就是更小更紧凑一点，使用方法上很类似，从现在的效果看还行，使用json格式为主的协议当然不能跟使用pb之类的相比，解析效率上大约单线程每秒解析20来万10个obj的对象，速度上不算太快但也不算太慢，对付一秒至多几万数据包的应用来说还是够的，因为现在cpu计算能力普遍过剩，使用json的另个好处就是增删字段很方便，各个版本之间不需要太考虑版本的问题，要是全用二进制格式就要麻烦很多了，在使用压缩之后，目前的json格式协议比之前的xml协议减少了2/3的带宽使用，总体效果还是可以的。使用json调试也很方便，我提供了一个工具，写后端的就直接用该工具按照json格式收发数据，无需等client开发好了再去做后端，之后做client也很方便，请求发过去之后返回来的就是标准的json格式数据，同样的解析方法，每个不同的应用就按照不同的格式处理下即可，和web等模块交互也很方便，这可算是额外的好处了。

 

总之，虽然json格式存储效率和解析效率跟二进制方式还差半个量级到一个量级，但合理使用还是可以的，特别是跟xml相比优势很明显，权衡使用吧，当然追求极致效率可能还是用pb之类的更合适一些，或者自己设计tlv格式。