Django 실행 방법 및 프로세스 요약(xianglong.me)

앞서 인터넷에서 Django 처리 요청의 절차와 Django 원본 구조를 소개하는 글을 봤는데 이런 내용을 알아보는 것이 Django 프로젝트 개발에 도움이 될 것 같습니다.그래서 저는 자신의 논리에 따라 Django 프로젝트의 운영 방식과 Request에 대한 기본적인 처리 절차를 정리했습니다.
1. Django의 운행 방식
Django 프로젝트를 실행하는 방법은 매우 많은데, 여기서 주로 자주 사용하는 방법을 소개한다.하나는 개발과 디버깅에서runserver 방법을 자주 사용하고 Django 자신의 웹 서버를 사용하는 것이다.다른 하나는fastcgi, uWSGit 등 프로토콜을 사용하여Django 프로젝트를 실행하는 것이다. 여기서uWSGit를 예로 들 수 있다.
1. runserver 방법
runserver 방법은 Django를 디버깅할 때 자주 사용하는 실행 방식입니다. Django가 자체로 가지고 있는 WSGI Server를 사용하여 실행되며 주로 테스트와 개발에 사용됩니다. 사용 방법은 다음과 같습니다.

Usage: manage.py runserver [options] [optional port number, or ipaddr:port]
# python manager.py runserver    # default port is 8000
# python manager.py runserver 8080
# python manager.py runserver 127.0.0.1:9090

관리자를 보십시오.py의 원본 코드, 위의 명령이 사실 Django의execute를 통과한 것을 발견할 수 있습니다from_command_라인 방법은 내부에서 실행된runserver 명령을 실행했습니다. 그럼 지금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 servers (runserver, runfcgi); 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.

    """
    from django.conf import settings
    app_path = getattr(settings, 'WSGI_APPLICATION')
    if app_path is None:
        return get_wsgi_application()

    return import_by_path(
        app_path,
        error_prefix="WSGI application '%s' could not be loaded; " % app_path
    )

위의 코드를 통해 알 수 있듯이 Django는 settings의 WSGI 에 따라APPLICATION에서handler를 얻기;프로젝트를 만들 때, Django는 기본적으로 wsgi를 만듭니다.py 파일, settings의 WSGIAPPLICATION 구성도 기본적으로 이 파일을 가리킵니다.이 wsgi를 보세요.py 파일, 사실 그것도 위의 논리와 마찬가지로 최종 호출getwsgi_응용 프로그램 구현.
2. uWSGI 방법
uWSGI+Nginx의 방법은 현재 가장 흔히 볼 수 있는 생산 환경에서 Django를 운행하는 방법이다. 본인의 블로그도 이런 방법으로 운행한다. 이런 방법을 이해하려면 먼저 WSGI와 uWSGI 프로토콜을 알아야 한다.
WSGI는 전체 명칭이 웹 서버 Gateway Interface 또는 Python 웹 서버 Gateway Interface로 Python 언어에 정의된 웹 서버와 웹 응용 프로그램이나 프레임워크 간의 간단하고 통용되는 인터페이스로 기존의 CGI 표준을 바탕으로 설계되었다.WSGI는 사실 하나의 게이트웨이(Gateway)로 그 역할은 협의 간에 전환을 하는 것이다.(PS: WSGI에 대한 간단한 설명만 하고 더 많은 내용을 알고 싶으면 스스로 검색할 수 있습니다)
uWSGI는 웹 서버로 WSGI 프로토콜, uwsgi, http 등 프로토콜을 실현했다.uwsgi는 통신 프로토콜이고 uWSGI는 uwsgi 프로토콜과 WSGI 프로토콜을 실현하는 웹 서버입니다.uWSGI는 초고속 성능, 낮은 메모리 점유율, 다중 앱 관리 등의 장점을 가지고 있다.내 블로그의 경우 uWSGI의 xml 구성은 다음과 같습니다.

    
    :7600
    :40000
    
    DJANGO_SETTINGS_MODULE=geek_blog.settings
    
    django.core.handlers.wsgi:WSGIHandler()
    6
    
    
    
    60
    
    /var/app/log/blog/uwsgi.log
    
    32768
    
    60

이상은 uWSGI xml 설정의 쓰기 방법입니다. ini를 사용할 수도 있습니다.uWSGI를 설치하고 실행하는 명령은 다음과 같습니다.

sudo pip install uwsgi
uwsgi --pidfile=/var/run/geek-blog.pid -x uwsgi.xml --uid blog --gid nogroup

uWSGI와 Nginx가 함께 사용하는 설정 방법은 여기서 설명하지 않겠습니다. 인터넷 강좌는 매우 많고 필요한 것은 스스로 검색할 수 있습니다.
2. HTTP 요청 처리 프로세스
Django는 다른 웹 프레임워크와 마찬가지로 HTTP의 처리 절차는 기본적으로 Request를 받아들이고response 내용을 되돌려줍니다.Django의 구체적인 처리 프로세스는 다음과 같습니다.
프로젝트 settings 로드
django-admin을 통해서.py에서 프로젝트를 만들 때 Django는 기본 settings 파일과 관리자를 자동으로 생성합니다.py 등 파일, WSGIServer를 만들기 전에 다음 참조를 실행합니다:from django.conf import settings에서 인용이 실행될 때 os를 읽습니다.environ의 DJANGOSETTINGS_MODULE 구성, 프로젝트 구성 파일을 로드하고 settings 객체를 생성합니다.그래서 관리자에서.py 파일에서 WSGI 서버를 가져오기 전에 프로젝트의 settings 경로를 os 경로에 추가하는 것을 볼 수 있습니다.
WSGIServer 만들기
runserver를 사용하든 uWSGI를 사용하든 Django 프로젝트를 실행하든 시작할 때django를 호출합니다.core.servers.basehttp의run() 방법,django를 만듭니다.core.servers.basehttp.WSGIServer 클래스의 인스턴스 다음에 해당 서버를 호출합니다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)
    # Sets the callable application as the WSGI application that will receive requests
    httpd.set_app(wsgi_handler)
    httpd.serve_forever()

위에서 보듯이, WSGIServer 실례를 만들 때 HTTP에서 요청한Handler를 지정하고, 상기 코드는 WSGIRequestHandler를 사용합니다.사용자의 HTTP 요청이 서버에 도착했을 때, WSGIServer는 WSGIRequestHandler 실례를 만들고,handler 방법으로 HTTP 요청을 처리합니다. (사실은 최종적으로 wsgiref.handlers.BaseHandler의run 방법을 호출합니다.)WSGIServer는 set 을 통해app 방법은 호출 가능한 대상을 응용 프로그램으로 설정합니다. 위에서 언급한handler 방법은 최종적으로 설정된 응용 프로그램 처리 리퀘스트를 호출하고response를 되돌려줍니다.
여기서 WSGIServer는 wsgiref에서 상속됩니다.simple_server.WSGIServer, WSGIRequestHandler는 wsgiref.simple_server.WSGIRequestHandler, wsgiref는 Python 표준 라이브러리에서 제시한 WSGI의 참고 실현입니다.그 원본 코드는 wsgiref에 직접 가서 참고할 수 있으며, 여기서는 더 이상 자세히 설명하지 않습니다.
Request 작업
두 번째 단계에서 말한 응용 프로그램은 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 방법은finishresponse가 요청을 종료하고 사용자에게 내용을 되돌려줍니다.
3. Django가 Request를 처리하는 상세한 절차
상술한 세 번째 단계와 네 번째 단계의 논리는 대충 처리 과정을 말했을 뿐이다. Django는 Request를 처리할 때 사실 많은 일을 했다. 다음은 우리가 상세하게 살펴보자.먼저 온라인에서 볼 수 있는 두 개의 Django 프로세스를 공유합니다.
Django 흐름도 1
Django 흐름도 2
위의 두 프로세스 다이어그램은 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만의 것이 아니라 다른 웹 프레임워크에서도 이런 개념이 있다.Django에서 Middleware는 처리 프로세스의 네 가지 단계에 스며들 수 있습니다: Request,view,response,exception. 상응하는 것은 모든 Middleware 클래스에rocessrequest,process_view, process_response 및 processexception 이 네 가지 방법.이 Middleware가 어떤 처리 단계에 작용하기를 원하느냐에 따라 임의로 여러 가지 방법을 정의할 수 있습니다.모든 방법은response 대상을 직접 되돌릴 수 있습니다.Middleware는 Django BaseHandler의 loadmiddleware 메서드가 실행될 때 로드됩니다. 로드 후에 프로세서의 인스턴스 변수로 4개의 목록이 만들어집니다.

_request_middleware：process_request     
_view_middleware：process_view     
_response_middleware：process_response     
_exception_middleware：process_exception     

Django의 중간부품은 설정 파일(settings.py)의 MIDDLEWARECLASSES 모듈에 정의되어 있습니다.MIDDLEWARE에서...CLASSES에서 중간부품 구성 요소는 문자열로 표시됩니다. 중간부품 클래스의 전체 Python 경로를 가리킵니다.예를 들어 GeekBlog 프로젝트의 구성:

MIDDLEWARE_CLASSES = (
    'django.middleware.cache.UpdateCacheMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.cache.FetchFromCacheMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.locale.LocaleMiddleware',
    'geek_blog.middlewares.MobileDetectionMiddleware',    #     Middleware
)

Django 프로젝트의 설치는 어떤 중간부품도 강제로 요구하지 않습니다. 원한다면 MIDDLEWARECLASSES는 비어 있을 수 있습니다.중간부품이 나타나는 순서가 매우 중요합니다: Request와view의 처리 단계에서 Django는 MIDDLEWARE 에 따라CLASSES에 나타나는 순서는 중간부품을 적용하고,response와 exception 이상 처리 단계에서는 Django가 역순으로 호출합니다.즉, Django는 MIDDLEWARE 를CLASSES는view 함수 바깥쪽의 순서 패키지로 간주됩니다. Request 단계에서는 위에서 아래로 순서대로 통과하고response에서는 반대로 통과합니다.다음 두 장의 그림은 당신의 이해에 더욱 도움이 될 것입니다.
Django Middleware 프로세스 1
Django Middleware 순서도 2
2, URLconf(URL 매핑)
리퀘스트를 처리하는 중간부품이response로 직접 되돌아오지 않으면, Django는 사용자가 요청한 URL을 분석합니다.URLconf는 Django가 지탱하는 사이트의 디렉터리입니다.본질은 URL 모드와 URL 모드를 호출할 뷰 함수 사이의 매핑 테이블입니다.이런 방식으로 Django에게 이 URL에 대해서는 이 코드를 호출하고, 그 URL에 대해서는 그 코드를 호출한다고 알릴 수 있다.구체적으로 Django 프로젝트의 프로필에 ROOTURLCONF 상수, 이 상수에 루트 디렉터리 "/"를 더해서 매개 변수로 django를 만듭니다.core.urlresolvers.RegexURLResolver의 실례를 분석한 다음, 리소스 방법으로 사용자가 요청한 URL을 분석하여 일치하는 첫 번째view를 찾습니다.
기타 URLconf에 관한 내용은 여기서 구체적으로 소개하지 않겠습니다. 여러분들은 DjangoBook을 보시면 알 수 있습니다.
3. Template(템플릿)
대부분의 웹 프레임워크는 자신의 Template (템플릿) 시스템을 가지고 있으며, Django도 마찬가지다.그러나 Django 템플릿은 Mako 템플릿과jinja2 템플릿과 다르기 때문에 Django 템플릿에서 Python 코드를 직접 쓸 수 없고 추가 정의 Filter와template tag를 통해서만 가능합니다.본고는 주로 Django 프로세스를 소개하기 때문에 템플릿 내용은 여러 가지 소개에 불과하다.
PS: 위 코드와 내용은 모두 Django 1.6.5 버전을 기반으로 한 것으로 다른 버전과 다를 수 있으니 참고하여 보십시오.
Over!