相信很多初學Flask的同學（包括我自己），在閱讀官方文件或者Flask的學習資料時，對於它的認識是從以下的一段程式碼開始的：
|
1 2 3 4 5 6 7 8 9 10 |
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。在上面例子中：
123@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)方法可以讓它被伺服器或閘道器呼叫。
123def __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
中介軟體SharedDataMiddleware是werkzeug.wsgi模組中的一個類。該類可以為Web應用提供靜態內容的支援。例如：
|
1 2 3 4 5 6 |
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應用在初始例項化的時候便有所應用。其中有這樣一段程式碼：
|
1 2 3 |
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的例子。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
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，將app1、app2和app合併起來。這樣，此時的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)被呼叫。這個函式是按照下面的方式執行的：
|
1 2 3 |
def wsgi_app(environ, start_response): with self.request_context(environ): ... |
請求上下文
可以看到，當Flask應用處理一個請求時，會構造一個上下文物件。所有的請求處理過程，都會在這個上下文物件中進行。這個上下文物件是_RequestContext類的例項。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
# 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。
|
1 |
_request_ctx_stack = LocalStack() |
關於LocalStack，可以參考：Werkzeug庫——local模組。LocalStack是一種棧結構，每當處理一個請求時，請求上下文物件_RequestContext會被放入這個棧結構中。資料在棧中儲存的形式表現成如下：
|
1 |
{880: {'stack': [<flask._RequestContext object>]}, 13232: {'stack': [<flask._RequestContext object>]}} |
這是一個字典形式的結構，鍵代表當前執行緒/協程的標識數值，值代表當前執行緒/協程儲存的變數。werkzeug.local模組構造的這種結構，很容易實現執行緒/協程的分離。也正是這種特性，使得可以在Flask中訪問以下的“全域性變數”：
|
1 2 3 4 |
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始終指向當前執行緒/協程中儲存的“請求上下文”，這樣像app、request、session、g等都可以以“全域性”的形式存在。這裡“全域性”是指在當前執行緒或協程當中。
由此可以看出，當處理請求時：
- 首先，會生成一個請求上下文物件，這個上下文物件包含請求相關的資訊。並且在進入上下文環境時，
LocalStack會將這個上下文物件推入棧結構中以儲存這個物件； - 在這個上下文環境中可以進行請求處理過程，這個稍後再介紹。不過可以以一種“全域性”的方式訪問上下文物件中的變數，例如
app、request、session、g等； - 當請求結束，退出上下文環境時，
LocalStack會清理當前執行緒/協程產生的資料（請求上下文物件）； - Flask 0.1版本只有“請求上下文”的概念，在Flask 0.9版本中又增加了“應用上下文”的概念。關於“應用上下文”，以後再加以分析。
4. 在上下文環境中處理請求
處理請求的過程定義在wsgi_app方法中，具體如下：
|
1 2 3 4 5 6 7 8 |
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會清理當前執行緒/協程產生的資料（請求上下文物件）。