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

 

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

 

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

 

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

 

Posted on 2011-01-11 13:33 袁斌 阅读(2507) 评论(3)  编辑 收藏 引用 所属分类: c++

Feedback

# re: 最近项目架构及协议决策  回复  更多评论   

2011-01-11 18:11 by true
经验之谈,我之前有个服务器内部的交互接口,就是传的std::map<string,string>,文本协议的动态性方面有优势

# re: 最近项目架构及协议决策  回复  更多评论   

2011-01-14 13:03 by ouyang
怎么做到更新时用户不断线的?架构上是怎么安排的?最好有点图片辅助一下,这块没看太懂。谢谢!

# re: 最近项目架构及协议决策  回复  更多评论   

2011-01-14 13:09 by 袁斌
@ouyang
gate升级还是会断线啊,后端服务器升级用户不断线,因为gate维护和客户端的连接,gate做了job的管理,在后端服务器升级好之后又重新分派job,这样给用户的感觉就是执行稍慢了一点。

只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理