标签归档:flask

RSS feed of flask

最后更新于 .

最近在做游戏服务分层的时候,一直想把mysql的访问独立成一个单独的服务DBGate,原因如下:

  1. 请求收拢到DBGate,可以使DBGate变为无状态的,方便横向扩展
  2. 当请求量或者存储量变大时,mysql需要做分库分表,DBGate可以内部直接处理,外界无感知
  3. 通过restful限制对数据请求的形式,仅支持简单的get/post/patch/put 进行增删改查,并不支持复杂查询。这个也是和游戏业务的特性有关,如果网站等需要复杂查询的业务,对此并不适合
  4. DBGate使用多进程模式,方便控制与mysql之间的链接数,进行mysql访问量阀值保护
  5. 方便在DBGate上进行访问量统计,慢查询统计、权限控制等等一系列逻辑
  6. 目前是使用python,以后要使用其他语言进行mysql操作时,只要进行标准的http请求即可,不会出现不兼容的情况

当然坏处也是有的:

  1. 首当其冲就是单次请求的响应时间变长,毕竟中间加了一层服务,并且还是http格式
  2. 部署上比原来复杂了一些,很多对mysql直接操作的思维需要进行转变,一开始可能会有些不适

不过总的来说,还是利大于弊,所以最终还是决定搭建DBGate

当然,我们不可能去手工挨个写每个库表对应的restful服务,值得庆幸的是django和flask都提供了对应的解决方案,我们一个个介绍.

Flask

参考链接: flask-restless

flask-restless使用方法比较简单,我直接贴一下代码即可:

# -*- coding: utf-8 -*-

import datetime
from flask ...

最后更新于 .

测了一下django、flask、bottle、tornado 框架本身最简单的性能。对django的性能完全无语了。

django、flask、bottle 均使用gunicorn+gevent启动,单进程,并且关闭DEBUG,请求均只返回一个字符串ok。

tornado直接自己启动,其他内容一致。

测试软件为 siege,测试os为cenos6 64位,测试命令为:

siege -c 100 -r 100 -b http://127.0.0.1:5000/

django测试结果为:

Transactions:		       10000 hits
Availability:		      100.00 %
Elapsed time:		       18.51 secs
Data transferred:	        0.02 MB
Response time:		        0.18 secs ...

最后更新于 .

之前对bottle做过不少的介绍,也写过一些文章来说明bottle的缺点,最近发现其实之前有些地方说的不太公平,所以趁此机会也来更正一下。

  • bottle是支持类似flask url_for的语法的,具体使用方法在下文介绍
  • bottle的request.query之类的参数默认是str类型,也是有原因的,比如我在给google做代理的时候,编码就不一定是utf8的,如果强制转化utf8就会报错
  • 之前的bug也得到了修正,比如mount('/x',app)之后,/x/和/x都可以访问到

OK,现在正式进入主题,我们来介绍一些bottle的一些高级使用

一. 智能创建url

这部分在bottle的文档上是没有介绍的(其实bottle明明实现了很多贴心的功能,不知道为啥都不写在文档上)。 在Bottle类里,有一个成员函数:

def get_url(self, routename, **kargs):
    """ Return a string that matches a named route """
    scriptname = request.environ.get('SCRIPT_NAME', '' ...

最后更新于 .

其实之前就有写过关于python web开发框架选择的文章,之前最终选择了bottle,并给出了bottle开发的物理设计,详见之前的文章:回归简单,向Django说再见bottle做web开发的物理设计,然而经过最近两个星期的实践,又有了一些新的想法。

Bottle作为一个微框架,本身确实有些小型项目的缺点,尝试列举如下:


  • 没有原生支持unicode

  • 例如route('/')获取的name并不是unicode类型,get和post的参数也默认并非unicode类型,虽然作者后来在0.10版本中给query和forms加入attr方式来解决这个问题,但是还是有所限制
    而flask则是 unicode based,对unicode支持的非常好
  • 影响力小,与其他组件的结合比较差

  • 一个典型的例子就是wtforms不支持bottle的files字段,而flask虽然也不支持,但是flask的插件flask-wtforms则完美修正了这个问题
  • 功能太基本

  • 关于这一点,可以说是优点也可以说是缺点。绝对的纯粹看起来是件好事,但是真正开发起来又发现完全不是那么回事,自己要重新开发的轮子实在太多了。比如session的支持
  • bottle由个人开发,有些地方并不那么专业

  • 比如route的参数method=['GET','POST'],因为是数组,所以用methods更合适;request.forms其实用request.form更合适
    再比如static_file函数,必须要求传入一个root_path和一个filename;而flask则有两个函数一个send_file和send_from_directory,支持直接返回file内容

反观flask,不能说flask的一切都是好的,但是确实在这几点上要比bottle做的要好一些,而且flask还有一些很实用的功能,比如实时debug ...

最后更新于 .

我这几天在微博上写了一句话: 回归简单,即便开始反而会变得更加复杂。 回想起当年刚用Django写素材管理系统还历历在目,最近却已经逐渐脱离Django了。 成长总是分阶段的吧,勇敢的抛弃一些东西,接纳新的东西,也许就是成长了。 至于原因呢,也是我一直在总结的,大家可以一起看一下。 Django适合做中型项目,但却不适合小型和大型项目 为什么这么说呢?

  • 对于中型项目来说,Django可以说提供了你需要用到的一切,session,orm,admin等等,只要你按照Django规定的思路来,你会发现开发和维护是如此顺手。
  • 但是如果是小型项目呢? 我可能不需要session,我也不需要数据库,但是我却要为Django那些繁琐的东西配置半天。当我被这些繁琐而无用的东西搞晕的时候,我感觉更像是在搭积木,而不是在创造一个伟大的东西。
  • 而对于大型项目来说,Django默认带的组件又满足不了需求,甚至连架构都可能要被替换,所以Django所自带的很多特性都将无法使用。 由于工作的关系,在大型项目中,有一类不得不说的服务,那就是SNS应用。 SNS应用的特点是什么?注册用户量极大,活跃很少。大批的用户蜂拥进入可能只是看一眼就再没回来,但是你的数据却因为这些无用的用户变得庞大无比。进而导致Django默认的那些Model,admin全部都形同虚设,Django的那些所谓的优势荡然无存。 博友反馈这里没说清楚,我再描述一下:
    1. 互联网的数据模型与关系数据模型不匹配。互联网数据更适合NoSQL,所以Admin对关系(外键、关联)的处理就没有任何用处了,而直接展示一个blob字段也并没有比用sql语句直观多少。(BTW ...