Flask教程:大型应用

以下是一些建议,当你的代码库日益壮大或者应用需要规划时可以参考。

阅读源代码¶

Werkzeug ( WSGI )和 Jinja (模板)是两个被广泛使用的工具,而 Flask 起源就是
用于展示如何基于这两个工具创建你自己的框架。随着不断地开发, Flask 被越来越多
的人认可了。当你的代码库日益壮大时,不应当仅仅是使用 Flask ,而更应当理解它。
阅读 Flask 的源代码吧。 Flask 的源代码阅读方便,文档公开,有利于你直接使用内部
的 API 。 Flask 坚持把上游库的 API 文档化,并文档化自己内部的工具,方便按你的
需要找到挂接点。

挂接,扩展¶

API 文档随处可见可用重载、挂接点和 信号 。你可以定制类似请求
或响应对象的自定义类。请深入研究你所使用的 API ,并在 Flask 发行版中有哪些可以
立即使用的可定制部分。请研究你的哪些项目可以重构为工具集或 Flask 扩展。你可以在
社区中探索许多 扩展 <http://flask.pocoo.org/extensions/> 。如果找不到满意的,
那就写一个你自己的吧。

继承¶

Flask 类有许多方法专门为继承而设计。你可通过继承
Flask (参见链接的方法文档)快速的添加或者定制行为,并把子类
实例化为一个应用类。这种方法同样适用于 应用工厂

用中间件包装¶

应用调度 一文中详细阐述了如何使用中间件。你可以引入中间件来包装你的
Flask 实例,在你的应用和 HTTP 服务器之间的层有所作为。
Werkzeug 包含许多 中间件

派生¶

如果以下建议都没有用,那么直接派生 Flask 吧。 Flask 的主要代码都在 Werkzeug 和
Jinja2 这两个库内。这两个库起了主要作用。 Flask 只是把它们粘合在一起而已。对于
一个项目来讲,底层框架的切入点很重要。因为如果不重视这一点,那么框架会变得非常
复杂,势必带来陡峭的学习曲线,从而吓退用户。

Flask 并不推崇唯一版本。许多人为了避免缺陷,都使用打过补丁或修改过的版本。这个
理念在 Flask 的许可中也有所体现:你不必返回你对框架所做的修改。

分支的缺点是大多数扩展都会失效,因为新的框架会使用不同的导入名称。更进一步:
整合上游的变动将会变得十分复杂,上游变动越多,则整合越复杂。因此,创建分支一般
是不得不为之的最后一招。

专家级的伸缩性¶

对于大多数网络应用来说,最复杂的莫过于对于用户量和数据量提供良好的伸缩性。
Flask 本身具有良好的伸缩性,其伸缩性受限于你的应用代码、所使用的数据储存方式、
Python 实现和应用所运行的服务器。

如果服务器数量增加一倍,你的应用性能就增加一倍,那么就代表伸缩性好。如果伸缩性
不好,那么即使增加服务器的数量,也不会得到更好的性能。伸缩性更差的甚至不支持增加
第二台服务器。

Flask 中唯一影响伸缩性的因素是环境本地代理。Flask 中的环境本地代理可以被定义为
线程、进程或 greenlet 。如果你的服务器不支持这些,那么 Flask 就不能支持全局代理。
但是,当今主流的服务器都支持线程、进程或 greenlet ,以提高并发性。 Flask 的基础
库 Werkzeug 对于线程、进程或 greenlet 都能够提供良好的支持。

与社区沟通¶

不管你的代码库是否强大, Flask 开发者总是保持框架的可操作性。如果发现 Flask 有
什么问题,请立即通过邮件列表或 IRC 与社区进行沟通。对于 Flask 及其扩展的开发都
来说,提升其在大型应用中的功能的最佳途径是倾听用户的心声。