最近在做游戏服务分层的时候，一直想把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 ...