搞大了？！

译者:fermin.yang#gmail.com

你的应用程序越搞越大越来越复杂了？如果你某天猛然意识到基于这种方式的Flask编程对于 你的应用程序已经不够给力怎么办？别慌，Flask还是搞得定！

Flask基于Werkzeug和Jinja2技术，这两套类库已经广泛应用于许多正在运行的大型网站系统， 而Flask则将二者有机的融合在一起。作为一个微型的框架，Flask除了整合已有的类库外其他 没有瞎掺和 - 代码不是特别多啦。 就是说项目即使搞大了也可以非常方便地将自己的代码抽出 然后封装到某一个新应用程序的模块里且加以扩展。

Flask在设计初时就考虑到了扩展和修改的可能性，可以用下列方法来搞定这个问题：

• Flask 扩展. 你可以针对大量可重复利用的代码功能进行扩展，之后在整个Flask环境内 就会产生很多附带信号和回调功能的钩子可供使用。
• 子类化. 大多数的功能都能通过创建 Flask 的子类和重载 针对此目的方法来进行个性改装。
• 开分舵. 如果实在没办法搞定你还可以在Flask的代码库的指定的位置选择一些源码(文件) 复制/粘贴到你的应用程序(目录)中然后进行修改。Flask在设计时已经考虑到你可能会这么 干所以一定会让你干的很爽。你要做的仅仅是选定几个包然后复制到应用程序代码文件（文件夹） 里，并且对其重命名（例如`framework`）。然后你可以在那里对代码做进一步的修改。

干嘛要开分舵?

Flask的主要代码是由Werkzeug和Jinja2组成的。这两个类库搞定了绝大部分的工作。Flask只是 负责粘贴并且将二者紧密联系在一起。自古对于许多项目来说存在这么一个观点，那就是底层框架“卖艺 不卖身”，往往感觉像是个鸡肋（基于假定初始开发人员碰到这个问题）。这样看来允许开“分舵”形式的产 生就很自然而然了，因为如果不这么干，框架就会变得非常复杂很难入手，会造成框架的学习曲线十分陡峭， 许多使用者信心大减等不和谐的问题。

这个问题不是Flask独有的。许多人通过对它们的框架打补丁或更新版本来弥补不足。这个概念在Flask 的授权协议里也有体现。你在决定并更改已经属于你应用程序一部分的“分舵”框架时，无需向我们提交任何 “保护费”（信息）。

开“分舵”当然也有他的缺点，那就是Flask“总舵”的更新可能会变更导入命名，这样会使得大多数的Flask扩展 不能使用。此外，与“总舵”的新版本整合可能是一个非常复杂的过程，这个要根据更新的数量进行估算。总之， “开分舵”应该是最后一招，不得已而为之的。

像大师一样游刃有余

对于许多Web应用程序来说，代码的复杂度和处理响应多到爆的用户或数据请求相比，简直是小巫见大巫。 Flask自身仅根据你的应用程序代码，你使用的数据存储方式，Python的执行效率和你挂载的Web服务器 的不同而受到限制。

好的延展性举例说明就是如果你将你的服务器的数量翻倍，你马上获得了双倍的运行表现。相对的，差的 延展性就是即使你买了新的服务器也不能给你带来什么帮助或者你的应用程序根本不支持多服务器负载。

在Flask只有一个限制因素与延展有关，那就是上下文本地代理（context local proxies）。他们基于 Flask里那些被定义为线程，进程或者greenlet（python的一个扩展模块）的上下文。如果你的服务器进 行用某种不是基于线程或者greenlets的并发处理时，Flask不会支持这些全局代理。然而大多数服务器只 能通过使用线程，greenlet或者独立进程来实现并发，且底层的Werkzeug类库对这些方法都提供了很好 的支持。

通过网络社区进行交流

Flask的开发人员一直认为大家开发的爽就是自己爽，所以一旦你碰到任何因为Flask导致的问题，不要憋着， 通过邮件列表发邮件或者上IRC频道炮轰我们吧。这也是促使编写Flask和Flask扩展的程序员提高，把应用程 序搞得更大的最佳途径。