• 幕客老师召集小伙伴
  • 运维高手36项修炼
  • python自动化运维项目实战
  • nginx从入门到实战
  • 阿里云与Centos7实战

论手游后台接口构建库开发设计

 

[申明:欢迎转载,但请注明出处 http://imoocc.com]

 

 

 

一、摘要

    2015年,今年随着国家对传统经济体模式提出“互联网+”、“工业4.0”发展方向建议,鼓励更过的传统企业改革和创新的互联网创新思路,人们对于网络的依赖不再简单的停留在一种内容体验。在这样的背景下,我公司作为国内传统的视频互联网行业领头羊,开始探索发展视频生态业务,并取得了良好的效果和成绩,我所在的部门就是其中的核心业务对象,负责手机游戏联运业务平台,让用户边看边玩,实现内容多元化。通过对业务特性,需求分析,我们决定最终采用基于构建的开发模式,理由如下:

        从业务类型考虑:主要用户请求来自于后台的API接口,获取授权运营的游戏业务,业务涉及到连接很多第三方的接口,而且需要自己的管理后台及数据库存储,项目要求在短的时间内上线,所以,需要采用成熟的、或者可靠的开源应用构建来满足需求,实现快速开发上线。

        从性能方面考虑:由于所有手机APP端,用户访问首页、详情页都会发起请求到游戏后台接口,等同于通过客户端的几个主要访流量倒流,预计将每日的总接口日请求量将达到亿级别。性能上需要我们着重考虑,为此需要我们对现有的无线后端接口进行抽取,然后对于原有构建进行性能优化。

         从维护性和可扩展性考虑:为了方便后期的开发迭代及应用维护,对于架构设计上,我们基于构建开发,可以将单个构建接口化封装,并且松散耦合剂高度模块内聚设计,还有方便独立优化并部署。

 


 

 

二、正文

    通过基于构建的开发模式,我们顺利完成公司的绩效任务。由于设计的内容太多,下面我主要通过:一、构建库提取  二、构建库优化   三、辅助快速构建手段 这三个方面阐述此次的开发构建:

    一、构件库选用及抽取

           手游联运的平台采用多层的CS模式,我们需要按照层次进行构建提取。

           首先,重点在于应用逻辑层,我们采用python的开发框架,tornado2.0和django1.6版本,tornado采用非阻塞的方式以及对epoll的运用,使得tornado成为一款每秒处理上千并发的web服务。django是一个基于mvc的思想框架,Django自带一个ADMIN site,不仅能满足手游联运后台业务运用此框架进行开发,而且由于ORM的代码组织框架及中间层等机制,能帮助有效的解决安全问题,例如:SQL注入或者权限控制。两种框架都是基于python语言开发,Python语言是这种面向对象而且健壮的语言,加上这两个框架奠定了我们开发构建基石。

           然后,在构建提取步骤中,我们对原有的开发构建,首先,进行了代码逻辑和数据模型的抽取。然后对我们业务特性进行了详细的需求分析,从而进行软件开发设计。在这一阶段,我们按照业务分组,将逻辑进行重组分类,尽量将通用的功能服务化,接口间通过json串的方式互调用,完成框架代码重组。最后,制定代码结构规则,配置文件构建、日志构建、缓存构建、静态资源构建等相关构建分目录从组,这样方便代码的扩展、维护及跨平台迁移。

    二、构建库优化

    对于构建的优化上,我们从linux 系统、网络环境、数据库系统、代码结构都作了很多完善工作,但是我们这个业务很需要注重的一点就是后台结构性能优化,由于没有类似于web页面的展现,很多功能都以json串的形式传输到前端APP。另外一个方面,前端无论对于静态资源还是数据的实时性都要求非常高,需要满足毫秒级的响应。为此,接下来将以我们是如何使用缓存优化为例来提高用户时实行体验。

       1、数据基本的缓存构建,我们采用了memcache、RedisDB作为我们的缓存数据容器,依赖于这种键/值类型的数据库减轻后端RDBMS的负载请求压力。在这块工作上,作了两个明显的代码层次的改进,首先、在key的选择上,采用了两个key,一个新key、一个老key。两个采用不同的时间过期机制,这样当新key更新时,或者意外失效,老的key仍然可以维持,保证不受影响。然后、缓存冗余方面,老得策略是用的哈希取模,这样当一台cache出现问题时,所有cache将失效导致缓存整体不可用,所以我们改变的缓存策略,使用一致性哈希的算法,这样保证整体数据不受别的节点影响。

       2、页面数据缓存构建,这里我们主要是利用varnish,为的就是使一些可以缓存的接口直接在接入初期返回给前端,减少后端应用的逻辑处理。在缓存的维度选择上,为了最大的提高缓存命中率,我们选用了三个维度,一个基于制定的URL及相关请求接口参数请求,第二种是头信息Accept-Encoding,最后一个维度为User-Agent。这样,既做到了确保主要的调用接口能被缓存,也能使针对客户端Agent代理请求能被缓存。若要控制varnish数据有效缓存时间,在代码接口代码中用父类中,定义一个总的方法,控制Cache-Control头的Etag参数,从而实现缓存的时间维度。

       3、静态资源构建,在这么高的访问量下,集中的部署请求方式是无法满足用户的请求的,为此我对于静态资源比需要考虑用到CDN的模式,我们的静态元素主要分为两类,一类是图片元素,另一类是APK游戏安装包。图片元素可以通过接口方式,通过后台上传统一处理并上传到CDN图片资源库。对于APK包,由于单个数据包大小过大而且同一时间使用量不确定,其流量的占用也不能确定,不能准确的预估到流程带宽成本,所以在这个静态资源上,不适合采用自己的CDN,经过讨论,我们决定采用和商业CDN来合作模式对接。

    三、辅助快速构建手段

      1、使用可靠性高的开源应用,这有助于我们减少很多成本,如在操作系统的选择上,我们会更有可能的使用稳定的linux系统, 负载均衡上我们会才用开源并成熟的lvs方案、在web服务上,会主要采用轻量级的Nginx等等。

      2、辅助测试开发系统使用,原由的一套自动生成测试接口,自动化生产我们接口参数及按钮功能,我们的开发人员不需要再自己手动的拼接。jira平台的使用,有助于产品、测试、开发人员打通各项处理流程。这些措施,有助于缩短开发周期。

 


 

三、总结

   在整个软件的构建开发过程中,也有一些不足之处,在性能上:比如我们一直考虑用到的缓存化,采用一致性哈希虽然防止了单点的大面积影响,但是却容易造成hash计算后的key不均匀,从而导致使用后端的memcachedb容量不均。另外,由于过度的追求接口的响应速度,忽略数据的安全及加密。这些问题,都是我们需要在后续的工作中需要重点解决的。

   这一次负责的项目完成后,并且顺利上线,按照预期完成协助了产品同事及老板的预定目标任务,采用构建的开发模式,让我们在较小的成本输出控制条件下,为公司带来了可观的新的收入。

             

 

论手游后台接口构建库开发设计

Pingbacks已打开。

引用地址

暂无评论

发表评论