译者: | fermin.yang#gmail.com |
---|
你的应用程序越搞越大越来越复杂了?如果你某天猛然意识到基于这种方式的Flask编程对于 你的应用程序已经不够给力怎么办?别慌,Flask还是搞得定!
Flask基于Werkzeug和Jinja2技术,这两套类库已经广泛应用于许多正在运行的大型网站系统, 而Flask则将二者有机的融合在一起。作为一个微型的框架,Flask除了整合已有的类库外其他 没有瞎掺和 - 代码不是特别多啦。 就是说项目即使搞大了也可以非常方便地将自己的代码抽出 然后封装到某一个新应用程序的模块里且加以扩展。
Flask在设计初时就考虑到了扩展和修改的可能性,可以用下列方法来搞定这个问题:
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扩展的程序员提高,把应用程 序搞得更大的最佳途径。