轉自

從runserver說起

ruserver是使用django自己的web server,主要用於開發和除錯中, 部署到線上環境一般使用nginx+uwsgi模式

manage.py 探祕

看一下manager.py的原始碼,你會發現上面的命令其實是通過Django的execute_from_command_line方法執行了內部實現的runserver命令,那麼現在看一下runserver具體做了什麼。。
通過原始碼分析可知, ruserserver主要完成兩件事:

1). 解析引數,並通過django.core.servers.basehttp.get_internal_wsgi_application方法獲取wsgi handler;
2). 根據ip_address和port生成一個WSGIServer物件,接受使用者請求

get_internal_wsgi_application的原始碼如下:

image

通過上面的程式碼我們可以知道,Django會先根據settings中的WSGI_APPLICATION來獲取handler;
在建立project的時候,Django會預設建立一個wsgi.py檔案,而settings中的WSGI_APPLICATION配置也會預設指向這個檔案。看一下這個wsgi.py檔案,其實它也和上面的邏輯一樣,最終呼叫get_wsgi_application實現。

django http請求處理流程

Django和其他Web框架一樣,HTTP的處理流程基本類似:接受request,返回response內容。Django的具體處理流程大致如下:

1. 載入settings.py

在通過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路徑中。

2. 建立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_address = (addr, port)
    if threading:
        httpd_cls = type(str('WSGIServer'), (socketserver.ThreadingMixIn, WSGIServer), {})
    else:
        httpd_cls = WSGIServer
    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參看,這裡不再細說。

3. 處理Request

第二步中說到的application,在Django中一般是django.core.handlers.wsgi.WSGIHandler物件,WSGIHandler繼承自django.core.handlers.base.BaseHandler,這個是Django處理request的核心邏輯,它會建立一個WSGIRequest例項,而WSGIRequest是從http.HttpRequest繼承而來

4. 返回Response

上面提到的BaseHandler中有個get_response方法,該方法會先載入Django專案的ROOT_URLCONF,然後根據url規則找到對應的view方法(類),view邏輯會根據request例項生成並返回具體的response。

在Django返回結果之後,第二步中提到wsgiref.handlers.BaseHandler.run方法會呼叫finish_response結束請求,並將內容返回給使用者

Django處理Request的詳細流程

首先給大家分享兩個網上看到的Django流程圖:

mark
流程圖一

image
流程圖二

上面的兩張流程圖可以大致描述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_CLASSES = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
    '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則反過來。以下這張圖可以更好地幫助你理解:

image

  1. URLConf(URL對映)
如果處理request的中介軟體都沒有直接返回response,那麼Django會去解析使用者請求的URL。URLconf就是Django所支撐網站的目錄。它的本質是URL模式以及要為該URL模式呼叫的檢視函式之間的對映表。通過這種方式可以告訴Django,對於這個URL呼叫這段程式碼,對於那個URL呼叫那段程式碼。具體的,在Django專案的配置檔案中有ROOT_URLCONF常量,這個常量加上根目錄"/",作為引數來建立django.core.urlresolvers.RegexURLResolver的例項,然後通過它的resolve方法解析使用者請求的URL,找到第一個匹配的view。

有關urlconf的內容,大家可以參考 [理解curlConf]()
  1. Template(模板)
大部分web框架都有自己的Template(模板)系統,Django也是。但是,Django模板不同於Mako模板和jinja2模板,在Django模板不能直接寫Python程式碼,只能通過額外的定義filter和template tag實現。由於本文主要介紹Django流程,模板內容就不過多介紹。
.