Django執行方式及處理流程總結
Django執行方式及處理流程總結
一 Django執行方式
一種是在開發和除錯中經常用到的runserver方法,使用django自己的web server
第二種使用fastcgi, uWSGIt等協議執行的Django專案
1. runserver方法
runserver方法是除錯Django時經常用到的執行方式，它使用Django自帶的WSGI Server執行，主要在測試和開發中使用，使用方法如下：
Usage: manage.py runserver [options] [optional port number, or ipaddr:port] 看一下manager.py的原始碼，你會發現上面的命令其實是通過Django的execute_from_command_line方法執行了內部實現的runserver命令
runserver命令主要做了兩件事情：
- 解析引數，並通過
django.core.servers.basehttp.get_internal_wsgi_application方法獲取wsgi handler; - 根據ip_address和port生成一個WSGIServer物件，接受使用者請求
get_internal_wsgi_application 的原始碼如下：
def get_internal_wsgi_application():
"""
Loads and returns the WSGI application as configured by the user in
``settings.WSGI_APPLICATION``. With the default ``startproject`` layout,
this will be the ``application`` object in ``projectname/wsgi.py``.
This function, and the ``WSGI_APPLICATION`` setting itself, are only useful
for Django's internal server (runserver); external WSGI servers should just
be configured to point to the correct application object directly.
If settings.WSGI_APPLICATION is not set (is ``None``), we just return
whatever ``django.core.wsgi.get_wsgi_application`` returns.
""" 通過上面的程式碼我們可以知道，Django會先根據settings中的WSGI_APPLICATION來獲取handler；在建立project的時候，Django會預設建立一個wsgi.py檔案，而settings中的WSGI_APPLICATION配置也會預設指向這個檔案。看一下這個wsgi.py檔案，其實它也和上面的邏輯一樣，最終呼叫get_wsgi_application實現。
2. uWSGI方法
uWSGI+Nginx的方法是現在最常見的在生產環境中執行Django的方法,要了解這種方法，首先要了解一下WSGI和uWSGI協議。
WSGI，全稱Web Server Gateway Interface，或者Python Web Server Gateway Interface，是為Python語言定義的Web伺服器和Web應用程式或框架之間的一種簡單而通用的介面，基於現存的CGI標準而設計的。WSGI其實就是一個閘道器(Gateway)，其作用就是在協議之間進行轉換.
uWSGI是一個Web伺服器，它實現了WSGI協議、uwsgi、http等協議。注意uwsgi是一種通訊協議，而uWSGI是實現uwsgi協議和WSGI協議的Web伺服器。uWSGI具有超快的效能、低記憶體佔用和多app管理等優點。例子，uWSGI的xml配置如下：
<uwsgi>
<!-- 埠 -->
<socket>:7600</socket>
<stats>:40000</stats>
<!-- 系統環境變數 -->
<env>DJANGO_SETTINGS_MODULE=geek_blog.settings</env>
<!-- 指定的python WSGI模組 -->
<module>django.core.handlers.wsgi:WSGIHandler()</module>
<processes>6</processes>
<master />
<master-as-root />
<!-- 超時設定 -->
<harakiri>60</harakiri>
<harakiri-verbose/>
<daemonize>/var/app/log/blog/uwsgi.log</daemonize>
<!-- socket的監聽佇列大小 -->
<listen>32768</listen>
<!-- 內部超時時間 -->
<socket-timeout>60</socket-timeout>
</uwsgi>
以上就是uWSGI xml配置的寫法，也可以使用ini的方式。安裝uWSGI和執行的命令如下：
sudo pip install uwsgi
uwsgi --pidfile=/var/run/geek-blog.pid -x uwsgi.xml --uid blog --gid nogroup
https://uwsgi-docs-zh.readthedocs.io/zh_CN/latest/Configuration.html
uWSGI和Nginx一起使用的配置方法就不在這裡說明了，網上教程很多．
二 HTTP請求處理流程
Django和其他Web框架一樣，HTTP的處理流程基本類似：接受request，返回response內容。Django的具體處理流程大致如下圖所示：
載入project settings
在通過django-admin.py建立project的時候，Django會自動生成預設的settings檔案和manager.py等檔案，在建立WSGIServer之前會執行下面的引用：
from django.conf import settings
上面引用在執行時，會讀取os.environ中的DJANGO_SETTINGS_MODULE配置，載入專案配置檔案，生成settings物件。所以，在manager.py檔案中你可以看到，在獲取WSGIServer之前，會先將project的settings路徑加到os路徑中。
建立WSGIServer
不管是使用runserver還是uWSGI執行Django專案，在啟動時都會呼叫django.core.servers.basehttp中的run()方法，建立一個django.core.servers.basehttp.WSGIServer類的例項，之後呼叫其serve_forever()方法啟動HTTP服務。run方法的原始碼如下:
def run(addr, port, wsgi_handler, ipv6=False, threading=False, server_cls=WSGIServer):
server_address = (addr, port)
if threading:
httpd_cls = type(str('WSGIServer'), (socketserver.ThreadingMixIn, server_cls), {})
else:
httpd_cls = server_cls
httpd = httpd_cls(server_address, WSGIRequestHandler, ipv6=ipv6)
if threading:
# ThreadingMixIn.daemon_threads indicates how threads will behave on an
# abrupt shutdown; like quitting the server by the user or restarting
# by the auto-reloader. True means the server will not wait for thread
# termination before it quits. This will make auto-reloader faster
# and will prevent the need to kill the server manually if a thread
# isn't terminating correctly.
httpd.daemon_threads = True
httpd.set_app(wsgi_handler)
httpd.serve_forever()
如上，我們可以看到：在建立WSGIServer例項的時候會指定HTTP請求的Handler，上述程式碼使用WSGIRequestHandler。當用戶的HTTP請求到達伺服器時，WSGIServer會建立WSGIRequestHandler例項，使用其handler方法來處理HTTP請求(其實最終是呼叫wsgiref.handlers.BaseHandler中的run方法處理)。WSGIServer通過set_app方法設定一個可呼叫(callable)的物件作為application，上面提到的handler方法最終會呼叫設定的application處理request，並返回response
其中，WSGIServer繼承自wsgiref.simple_server.WSGIServer，而WSGIRequestHandler繼承自wsgiref.simple_server.WSGIRequestHandler，wsgiref是Python標準庫給出的WSGI的參考實現。其原始碼可自行到wsgiref參看，這裡不再細說。
處理Request
第二步中說到的application，在Django中一般是django.core.handlers.wsgi.WSGIHandler物件，WSGIHandler繼承自django.core.handlers.base.BaseHandler，這個是Django處理request的核心邏輯，它會建立一個WSGIRequest例項，而WSGIRequest是從http.HttpRequest繼承而來
返回Response
上面提到的BaseHandler中有個get_response方法，該方法會先載入Django專案的ROOT_URLCONF，然後根據url規則找到對應的view方法(類)，view邏輯會根據request例項生成並返回具體的response。
在Django返回結果之後，第二步中提到wsgiref.handlers.BaseHandler.run方法會呼叫finish_response結束請求，並將內容返回給使用者。
三 Django處理Request的詳細流程
上述的第三步和第四步邏輯只是大致說了一下處理過程，Django在處理request的時候其實做了很多事情，下面我們詳細的過一下。首先給大家分享兩個網上看到的Django流程圖：
django流程1
django流程2
django流程3
flask流程
上面的兩張流程圖可以大致描述Django處理request的流程，按照流程圖2的標註，可以分為以下幾個步驟:
1. 使用者通過瀏覽器請求一個頁面
2. 請求到達Request Middlewares，中介軟體對request做一些預處理或者直接response請求
3. URLConf通過urls.py檔案和請求的URL找到相應的View
4. View Middlewares被訪問，它同樣可以對request做一些處理或者直接返回response
5. 呼叫View中的函式
6. View中的方法可以選擇性的通過Models訪問底層的資料
7. 所有的Model-to-DB的互動都是通過manager完成的
8. 如果需要，Views可以使用一個特殊的Context
9. Context被傳給Template用來生成頁面
a. Template使用Filters和Tags去渲染輸出
b. 輸出被返回到View
c. HTTPResponse被髮送到Response Middlewares
d. 任何Response Middlewares都可以豐富response或者返回一個完全不同的response
e. Response返回到瀏覽器，呈現給使用者
上述流程中最主要的幾個部分分別是：Middleware(中介軟體，包括request, view, exception, response)，URLConf(url對映關係)，Template(模板系統)，下面一一介紹一下:
1 Middleware(中介軟體)
Middleware並不是Django所獨有的東西，在其他的Web框架中也有這種概念。在Django中，Middleware可以滲入處理流程的四個階段：request，view，response和exception，相應的，在每個Middleware類中都有rocess_request，process_view， process_response 和 process_exception這四個方法。你可以定義其中任意一個活多個方法，這取決於你希望該Middleware作用於哪個處理階段。每個方法都可以直接返回response物件。
Middleware是在Django BaseHandler的load_middleware方法執行時載入的，載入之後會建立四個列表作為處理器的例項變數：
_request_middleware：process_request方法的列表
_view_middleware：process_view方法的列表
_response_middleware：process_response方法的列表
_exception_middleware：process_exception方法的列表
Django的中介軟體是在其配置檔案(settings.py)的MIDDLEWARE_CLASSES元組中定義的。在MIDDLEWARE_CLASSES中，中介軟體元件用字串表示：指向中介軟體類名的完整Python路徑。例如專案的配置：
MIDDLEWARE = [
'django.middleware.security.SecurityMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
]
Django專案的安裝並不強制要求任何中介軟體，如果你願意，MIDDLEWARE_CLASSES可以為空。中介軟體出現的順序非常重要：在request和view的處理階段，Django按照MIDDLEWARE_CLASSES中出現的順序來應用中介軟體，而在response和exception異常處理階段，Django則按逆序來呼叫它們。也就是說，Django將MIDDLEWARE_CLASSES視為view函式外層的順序包裝子：在request階段按順序從上到下穿過，而在response則反過來。以下兩張圖可以更好地幫助你理解：
2 URLConf(URL對映)
如果處理request的中介軟體都沒有直接返回response，那麼Django會去解析使用者請求的URL。URLconf就是Django所支撐網站的目錄。它的本質是URL模式以及要為該URL模式呼叫的檢視函式之間的對映表。通過這種方式可以告訴Django，對於這個URL呼叫這段程式碼，對於那個URL呼叫那段程式碼。具體的，在Django專案的配置檔案中有ROOT_URLCONF常量，這個常量加上根目錄"/"，作為引數來建立django.core.urlresolvers.RegexURLResolver的例項，然後通過它的resolve方法解析使用者請求的URL，找到第一個匹配的view。
其他有關URLConf的內容，這裡不再具體介紹，大家可以看DjangoBook瞭解。
3、Template(模板)
大部分web框架都有自己的Template(模板)系統，Django也是。但是，Django模板不同於Mako模板和jinja2模板，在Django模板不能直接寫Python程式碼，只能通過額外的定義filter和template tag實現。由於本文主要介紹Django流程，模板內容就不過多介紹。
PS: 以上程式碼和內容都是基於Django 1.1.11版本，其他版本可能與其不同，請參考閱讀