资讯专栏INFORMATION COLUMN

一个Flask应用运行过程剖析

shmily / 402人阅读

摘要:本文就主要针对一个应用的运行过程进行简要分析,后续文章还会对框架的一些具体问题进行分析。所有的请求处理过程,都会在这个上下文对象中进行。和一些全局变量注意当进入这个上下文对象时,会触发。

相信很多初学Flask的同学(包括我自己),在阅读官方文档或者Flask的学习资料时,对于它的认识是从以下的一段代码开始的:

from flask import Flask

app = Flask(__name__)

@app.route("/")
def index():
    return "Hello World!"

if __name__ == "__main__":
    app.run()

运行如上代码,在浏览器中访问http://localhost:5000/,便可以看到Hello World!出现了。这是一个很简单的Flask的应用。

然而,这段代码怎么运行起来的呢?一个Flask应用运转的背后又有哪些逻辑呢?如果你只关心Web应用,那对这些问题不关注也可以,但从整个Web编程的角度来看,这些问题非常有意义。本文就主要针对一个Flask应用的运行过程进行简要分析,后续文章还会对Flask框架的一些具体问题进行分析。

为了分析方便,本文采用 Flask 0.1版本 的源码进行相关问题的探索。

一些准备知识

在正式分析Flask之前,有一些准备知识需要先了解一下:

使用Flask框架开发的属于Web应用。由于Python使用WSGI网关,所以这个应用也可以叫WSGI应用;

服务器、Web应用的设计应该遵循网关接口的一些规范。对于WSGI网关,要求Web应用实现一个函数或者一个可调用对象webapp(environ, start_response)。服务器或网关中要定义start_response函数并且调用Web应用。关于这部分的内容可以参考:wsgiref包——符合WSGI标准的Web服务实现(一)。

Flask依赖于底层库werkzeug。相关内容可以参考:Werkzeug库简介。

本文暂时不对服务器或网关的具体内容进行介绍,只需对服务器、网关、Web应用之间有怎样的关系,以及它们之间如何调用有一个了解即可。

一个Flask应用运行的过程 1. 实例化一个Flask应用

使用app = Flask(__name__),可以实例化一个Flask应用。实例化的Flask应用有一些要点或特性需要注意一下:

对于请求和响应的处理,Flask使用werkzeug库中的Request类和Response类。对于这两个类的相关内容可以参考:Werkzeug库——wrappers模块。

对于URL模式的处理,Flask应用使用werkzeug库中的Map类和Rule类,每一个URL模式对应一个Rule实例,这些Rule实例最终会作为参数传递给Map类构造包含所有URL模式的一个“地图”。这个地图可以用来匹配请求中的URL信息,关于Map类和Rule类的相关知识可以参考:Werkzeug库——routing模块。

当实例化一个Flask应用app(这个应用的名字可以随便定义)之后,对于如何添加URL模式,Flask采取了一种更加优雅的模式,对于这点可以和Django的做法进行比较。Flask采取装饰器的方法,将URL规则和视图函数结合在一起写,其中主要的函数是route。在上面例子中:

@app.route("/")
def index():
    pass

这样写视图函数,会将"/"这条URL规则和视图函数index()联系起来,并且会形成一个Rule实例,再添加进Map实例中去。当访问"/"时,会执行index()。关于Flask匹配URL的内容,可以参考后续文章。

实例化Flask应用时,会创造一个Jinja环境,这是Flask自带的一种模板引擎。可以查看Jinja文档,这里先暂时不做相关介绍。

实例化的Flask应用是一个可调用对象。在前面讲到,Web应用要遵循WSGI规范,就要实现一个函数或者一个可调用对象webapp(environ, start_response),以方便服务器或网关调用。Flask应用通过__call__(environ, start_response)方法可以让它被服务器或网关调用。

def __call__(self, environ, start_response):
    """Shortcut for :attr:`wsgi_app`"""
    return self.wsgi_app(environ, start_response)

注意到调用该方法会执行wsgi_app(environ, start_response)方法,之所以这样设计是为了在应用正式处理请求之前,可以加载一些“中间件”,以此改变Flask应用的相关特性。对于这一点后续会详细分析。

Flask应用还有一些其他的属性或方法,用于整个请求和响应过程。

2.调用Flask应用时会发生什么

上面部分分析了实例化的Flask应用长什么样子。当一个完整的Flask应用实例化后,可以通过调用app.run()方法运行这个应用。

Flask应用的run()方法会调用werkzeug.serving模块中的run_simple方法。这个方法会创建一个本地的测试服务器,并且在这个服务器中运行Flask应用。关于服务器的创建这里不做说明,可以查看werkzeug.serving模块的有关文档。

当服务器开始调用Flask应用后,便会触发Flask应用的__call__(environ, start_response)方法。其中environ由服务器产生,start_response在服务器中定义。

上面我们分析到当Flask应用被调用时会执行wsgi_app(environ, start_response)方法。可以看出,wsgi_app是真正被调用的WSGI应用,之所以这样设计,就是为了在应用正式处理请求之前,wsgi_app可以被一些“中间件”装饰,以便先行处理一些操作。为了便于理解,这里先举两个例子进行说明。

例子一: 中间件SharedDataMiddleware

中间件SharedDataMiddlewarewerkzeug.wsgi模块中的一个类。该类可以为Web应用提供静态内容的支持。例如:

import os
from werkzeug.wsgi import SharedDataMiddleware

app = SharedDataMiddleware(app, {
    "/shared": os.path.join(os.path.dirname(__file__), "shared")
})

Flask应用通过以上的代码,app便会成为一个SharedDataMiddleware实例,之后便可以在http://example.com/shared/中访问shared文件夹下的内容。

对于中间件SharedDataMiddleware,Flask应用在初始实例化的时候便有所应用。其中有这样一段代码:

self.wsgi_app = SharedDataMiddleware(self.wsgi_app, {
                self.static_path: target
            })

这段代码显然会将wsgi_app变成一个SharedDataMiddleware对象,这个对象为Flask应用提供一个静态文件夹/static。这样,当整个Flask应用被调用时,self.wsgi_app(environ, start_response)会执行。由于此时self.wsgi_app是一个SharedDataMiddleware对象,所以会先触发SharedDataMiddleware对象的__call__(environ, start_response)方法。如果此时的请示是要访问/static这个文件夹,SharedDataMiddleware对象会直接返回响应;如果不是,则才会调用Flask应用的wsgi_app(environ.start_response)方法继续处理请求。

例子二: 中间件DispatcherMiddleware

中间件DispatcherMiddleware也是werkzeug.wsgi模块中的一个类。这个类可以讲不同的应用“合并”起来。以下是一个使用中间件DispatcherMiddleware的例子。

from flask import Flask
from werkzeug import DispatcherMiddleware

app1 = Flask(__name__)
app2 = Flask(__name__)
app = Flask(__name__)

@app1.route("/")
def index():
    return "This is app1!"

@app2.route("/")
def index():
    return "This is app2!"

@app.route("/")
def index():
    return "This is app!"

app = DispatcherMiddleware(app, {
            "/app1":        app1,
            "/app2":        app2
        })

if __name__ == "__main__":
    from werkzeug.serving import run_simple
    run_simple("localhost", 5000, app)

在上面的例子中,我们首先创建了三个不同的Flask应用,并为每个应用创建了一个视图函数。但是,我们使用了DispatcherMiddleware,将app1app2app合并起来。这样,此时的app便成为一个DispatcherMiddleware对象。

当在服务器中调用app时,由于它是一个DispatcherMiddleware对象,所以首先会触发它的__call__(environ, start_response)方法。然后根据请求URL中的信息来确定要调用哪个应用。例如:

如果访问/,则会触发app(environ, start_response)注意: 此时app是一个Flask对象),进而处理要访问app的请求;

如果访问/app1,则会触发app1(environ, start_response),进而处理要访问app1的请求。访问/app2同理。

3. 和请求处理相关的上下文对象

当Flask应用真正处理请求时,wsgi_app(environ, start_response)被调用。这个函数是按照下面的方式运行的:

def wsgi_app(environ, start_response):
    with self.request_context(environ):
        ...
请求上下文

可以看到,当Flask应用处理一个请求时,会构造一个上下文对象。所有的请求处理过程,都会在这个上下文对象中进行。这个上下文对象是_RequestContext类的实例。

# Flask v0.1
class _RequestContext(object):
    """The request context contains all request relevant information.  It is
    created at the beginning of the request and pushed to the
    `_request_ctx_stack` and removed at the end of it.  It will create the
    URL adapter and request object for the WSGI environment provided.
    """

    def __init__(self, app, environ):
        self.app = app
        self.url_adapter = app.url_map.bind_to_environ(environ)
        self.request = app.request_class(environ)
        self.session = app.open_session(self.request)
        self.g = _RequestGlobals()
        self.flashes = None

    def __enter__(self):
        _request_ctx_stack.push(self)

    def __exit__(self, exc_type, exc_value, tb):
        # do not pop the request stack if we are in debug mode and an
        # exception happened.  This will allow the debugger to still
        # access the request object in the interactive shell.
        if tb is None or not self.app.debug:
            _request_ctx_stack.pop()

根据_RequestContext上下文对象的定义,可以发现,在构造这个对象的时候添加了和Flask应用相关的一些属性:

app ——上下文对象的app属性是当前的Flask应用;

url_adapter ——上下文对象的url_adapter属性是通过Flask应用中的Map实例构造成一个MapAdapter实例,主要功能是将请求中的URL和Map实例中的URL规则进行匹配;

request ——上下文对象的request属性是通过Request类构造的实例,反映请求的信息;

session ——上下文对象的session属性存储请求的会话信息;

g ——上下文对象的g属性可以存储全局的一些变量。

flashes ——消息闪现的信息。

LocalStack和一些“全局变量”

注意: 当进入这个上下文对象时,会触发_request_ctx_stack.push(self)。在这里需要注意Flask中使用了werkzeug库中定义的一种数据结构LocalStack

_request_ctx_stack = LocalStack()

关于LocalStack,可以参考:Werkzeug库——local模块。LocalStack是一种栈结构,每当处理一个请求时,请求上下文对象_RequestContext会被放入这个栈结构中。数据在栈中存储的形式表现成如下:

{880: {"stack": []}, 13232: {"stack": []}}

这是一个字典形式的结构,键代表当前线程/协程的标识数值,值代表当前线程/协程存储的变量。werkzeug.local模块构造的这种结构,很容易实现线程/协程的分离。也正是这种特性,使得可以在Flask中访问以下的“全局变量”:

current_app = LocalProxy(lambda: _request_ctx_stack.top.app)
request = LocalProxy(lambda: _request_ctx_stack.top.request)
session = LocalProxy(lambda: _request_ctx_stack.top.session)
g = LocalProxy(lambda: _request_ctx_stack.top.g)

其中_request_ctx_stack.top始终指向当前线程/协程中存储的“请求上下文”,这样像apprequestsessiong等都可以以“全局”的形式存在。这里“全局”是指在当前线程或协程当中。

由此可以看出,当处理请求时:

首先,会生成一个请求上下文对象,这个上下文对象包含请求相关的信息。并且在进入上下文环境时,LocalStack会将这个上下文对象推入栈结构中以存储这个对象;

在这个上下文环境中可以进行请求处理过程,这个稍后再介绍。不过可以以一种“全局”的方式访问上下文对象中的变量,例如apprequestsessiong等;

当请求结束,退出上下文环境时,LocalStack会清理当前线程/协程产生的数据(请求上下文对象);

Flask 0.1版本只有“请求上下文”的概念,在Flask 0.9版本中又增加了“应用上下文”的概念。关于“应用上下文”,以后再加以分析。

4. 在上下文环境中处理请求

处理请求的过程定义在wsgi_app方法中,具体如下:

def wsgi_app(environ, start_response):
    with self.request_context(environ):
        rv = self.preprocess_request()
        if rv is None:
            rv = self.dispatch_request()
        response = self.make_response(rv)
        response = self.process_response(response)
        return response(environ, start_response)

从代码可以看出,在上下文对象中处理请求的过程分为以下几个步骤:

在请求正式被处理之前的一些操作,调用preprocess_request()方法,例如打开一个数据库连接等操作;

正式处理请求。这个过程调用dispatch_request()方法,这个方法会根据URL匹配的情况调用相关的视图函数;

将从视图函数返回的值转变为一个Response对象;

在响应被发送到WSGI服务器之前,调用process_response(response)做一些后续处理过程;

调用response(environ, start_response)方法将响应发送回WSGI服务器。关于此方法的使用,可以参考:Werkzeug库——wrappers模块;

退出上下文环境时,LocalStack会清理当前线程/协程产生的数据(请求上下文对象)。

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/38605.html

相关文章

  • Flask中的请求上下文和应用上下文

    摘要:并且栈顶的元素都是的请求上下文和应用上下文之后,我们再在这个环境中嵌套的应用上下文。这时查看两个栈的内容,发现两个栈中只有的请求的请求上下文对象和应用上下文对象。而等一直指向栈顶的请求上下文对象,分别引用请求上下文的和。 在Flask中处理请求时,应用会生成一个请求上下文对象。整个请求的处理过程,都会在这个上下文对象中进行。这保证了请求的处理过程不被干扰。处理请求的具体代码如下: de...

    sourcenode 评论0 收藏0
  • 蠎周刊 2015 年度最赞

    摘要:蠎周刊年度最赞亲俺们又来回顾又一个伟大的年份儿包去年最受欢迎的文章和项目如果你错过了几期就这一期不会丢失最好的嗯哼还为你和你的准备了一批纪念裇从这儿获取任何时候如果想分享好物给大家在这儿提交喜欢我们收集的任何意见建议通过来吧原文 Title: 蠎周刊 2015 年度最赞Date: 2016-01-09 Tags: Weekly,Pycoder,Zh Slug: issue-198-to...

    young.li 评论0 收藏0
  • flask 爬坑指南(一)如何开始一个flask应用

    摘要:前言去年十月开始学习一开始写了一个的爬虫将自己在过程中的一些经验写了下来没想到那么多人支持。但目前也只是处于能用状态。及如何将一个文件夹下文件变成一个包呢。而不仅仅是一个服务器无法理解此请求。 前言 去年十月开始学习python一开始写了一个python的爬虫 将自己在过程中的一些经验写了下来没想到那么多人支 持。之后因为一些实验室的需求就转投python的web开发 一开...

    Michael_Lin 评论0 收藏0
  • 使用 Vue.js 和 Flask 来构建一个单页的App

    摘要:我们将创建一个简单的,它将从到返回一个随机数。我们来改变组件显示随机数在这个阶段,我们只是模仿客户端的随机数生成过程。 在这个教程中,我们将讲解如何将vue.js单页应用与Flask后端进行连接。 一般来说,如果你只是想通过Flask模板使用vue.js库也是没有问题的。但是,实际上是一个很明显的问题那就是,Jinja(模板引擎)也和Vue.js一样采用双大括号用于渲染,但只是一个还算...

    LiuZh 评论0 收藏0
  • 在 Visual Studio Code 中配置 Python Flask 环境

    摘要:更改执行策略可能会产生安全风险,如中的帮助主题所述。如果出现选择环境,我们选择。在中,我们仅保留这一段。在中,我们新建一个文件,名为。到此,我们的环境配置就完成了。 在 Visual Studio Code 中配置 Python Flask 环境 本文由 赤石俊哉 原创编写,您可以在学习交流用途以内自由使用文章。 但是禁止抄袭文章,转载时,请注明来源地址,谢谢。最后更新时间: 20...

    gself 评论0 收藏0

发表评论

0条评论

shmily

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<