django中wsgi怎么读？

导读：很多朋友问到关于django中wsgi怎么读的相关问题，本文首席CTO笔记就来为大家做个详细解答，供大家参考，希望对大家有所帮助！一起来看看吧！

在以前，你选择Pythonweb架构会受制于可用的web服务器，反之亦然。如果架构和服务器可以协同工作，那你就走运了：

但你有可能面对(或者曾有过)下面的问题，当要把一个服务器和一个架构结合起来是发现他们不是被设计成协同工作的：

基本上你只能用可以一起运行的而非你想要使用的。

那么，你怎么可以不修改服务器和架构代码而确保可以在多个架构下运行web服务器呢?答案就是PythonWebServerGatewayInterface(或简称WSGI，读作“wizgy”)。

WSGI允许开发者将选择web框架和web服务器分开。现在你可以混合匹配web服务器和web框架，选择一个适合你需要的配对。比如,你可以在Gunicorn或者Nginx/uWSGI或者Waitress上运行Django,Flask,或Pyramid。真正的混合匹配，得益于WSGI同时支持服务器和架构：

WSGI是第一篇和这篇开头又重复问道问题的答案。你的web服务器必须具备WSGI接口，所有的现代PythonWeb框架都已具备WSGI接口，它让你不对代码作修改就能使服务器和特点的web框架协同工作。

现在你知道WSGI由web服务器支持，而web框架允许你选择适合自己的配对，但它同样对于服务器和框架开发者提供便利使他们可以专注于自己偏爱的领域和专长而不至于相互牵制。其他语言也有类似接口：java有ServletAPI，Ruby有Rack。

说这么多了，你肯定在喊，给我看代码!好吧，看看这个极简的WSGI服务器实现：

#TestedwithPython2.7.9,LinuxMacOSX

importsocket

importStringIO

importsys

classWSGIServer(object):

address_family=socket.AF_INET

socket_type=socket.SOCK_STREAM

request_queue_size=1

def__init__(self,server_address):

#Createalisteningsocket

self.listen_socket=listen_socket=socket.socket(

self.address_family,

self.socket_type

)

#Allowtoreusethesameaddress

listen_socket.setsockopt(socket.SOL_SOCKET,socket.SO_REUSEADDR,1)

#Bind

listen_socket.bind(server_address)

#Activate

listen_socket.listen(self.request_queue_size)

#Getserverhostnameandport

host,port=self.listen_socket.getsockname()[:2]

self.server_name=socket.getfqdn(host)

self.server_port=port

#ReturnheaderssetbyWebframework/Webapplication

self.headers_set=[]

defset_app(self,application):

self.application=application

defserve_forever(self):

listen_socket=self.listen_socket

whileTrue:

#Newclientconnection

self.client_connection,client_address=listen_socket.accept()

#Handleonerequestandclosetheclientconnection.Then

#loopovertowaitforanotherclientconnection

self.handle_one_request()

defhandle_one_request(self):

self.request_data=request_data=self.client_connection.recv(1024)

#Printformattedrequestdataala'curl-v'

print(''.join(

'{line}\n'.format(line=line)

forlineinrequest_data.splitlines()

))

self.parse_request(request_data)

#Constructenvironmentdictionaryusingrequestdata

env=self.get_environ()

#It'stimetocallourapplicationcallableandget

#backaresultthatwillbecomeHTTPresponsebody

result=self.application(env,self.start_response)

#Constructaresponseandsenditbacktotheclient

self.finish_response(result)

defparse_request(self,text):

request_line=text.splitlines()[0]

request_line=request_line.rstrip('\r\n')

#Breakdowntherequestlineintocomponents

(self.request_method,#GET

self.path,#/hello

self.request_version#HTTP/1.1

)=request_line.split()

defget_environ(self):

env={}

#ThefollowingcodesnippetdoesnotfollowPEP8conventions

#butit'sformattedthewayitisfordemonstrationpurposes

#toemphasizetherequiredvariablesandtheirvalues

#

#RequiredWSGIvariables

env['wsgi.version']=(1,0)

env['wsgi.url_scheme']='http'

env['wsgi.input']=StringIO.StringIO(self.request_data)

env['wsgi.errors']=sys.stderr

env['wsgi.multithread']=False

env['wsgi.multiprocess']=False

env['wsgi.run_once']=False

#RequiredCGIvariables

env['REQUEST_METHOD']=self.request_method#GET

env['PATH_INFO']=self.path#/hello

env['SERVER_NAME']=self.server_name#localhost

env['SERVER_PORT']=str(self.server_port)#8888

returnenv

defstart_response(self,status,response_headers,exc_info=None):

#Addnecessaryserverheaders

server_headers=[

('Date','Tue,31Mar201512:54:48GMT'),

('Server','WSGIServer0.2'),

]

self.headers_set=[status,response_headers+server_headers]

#ToadheretoWSGIspecificationthestart_responsemustreturn

#a'write'callable.Wesimplicity'ssakewe'llignorethatdetail

#fornow.

#returnself.finish_response

deffinish_response(self,result):

try:

status,response_headers=self.headers_set

response='HTTP/1.1{status}\r\n'.format(status=status)

forheaderinresponse_headers:

response+='{0}:{1}\r\n'.format(*header)

response+='\r\n'

fordatainresult:

response+=data

#Printformattedresponsedataala'curl-v'

print(''.join(

'{line}\n'.format(line=line)

forlineinresponse.splitlines()

))

self.client_connection.sendall(response)

finally:

self.client_connection.close()

SERVER_ADDRESS=(HOST,PORT)='',8888

defmake_server(server_address,application):

server=WSGIServer(server_address)

server.set_app(application)

returnserver

if__name__=='__main__':

iflen(sys.argv)2:

sys.exit('ProvideaWSGIapplicationobjectasmodule:callable')

app_path=sys.argv[1]

module,application=app_path.split(':')

module=__import__(module)

application=getattr(module,application)

httpd=make_server(SERVER_ADDRESS,application)

print('WSGIServer:ServingHTTPonport{port}...\n'.format(port=PORT))

httpd.serve_forever()

这比第一篇的代码长的多，但也足够短(只有150行)来让你理解而避免在细节里越陷越深。上面的服务器可以做更多——可以运行你钟爱web框架所写基本的web应用，Pyramid,Flask,Django,或其他PythonWSGI框架.

不相信我?你自己试试看。保存上面的代码为webserver2.py或者直接在Github下载。如果你不传入任何参数它会提醒然后推出。

$pythonwebserver2.py

ProvideaWSGIapplicationobjectasmodule:callable

诚实的说，直到目前为止，我并不欣赏django。在我的认知它并不是多么精巧的设计。只是由功能堆积起来的"成熟方案"。但每一样东西的崛起都是时代的选择。无论你多么不喜欢，但它被需要。希望有一天，python能有更多更丰富的成熟方案，且不再被诟病性能和可维护性。（屁话结束）

取其精华去其糟粕，django的优点是方便，我们这次源码阅读的目的是探究其方便的本质。计划上本次源码阅读不会精细到每一处，而是大体以功能为单位进行解读。

django-adminstartprojectHelloWorld即可生成django项目，命令行是exe格式的。

manage.py把参数交给命令行解析。

execute_from_command_line()通过命令行参数，创建一个管理类。然后运行他的execute()。

如果设置了reload，将会在启动前先check_errors。

check_errors()是个闭包，所以上文结尾是(django.setup)()。

直接看最后一句settings.INSTALLED_APPS。从settings中抓取app

注意，这个settings还不是我们项目中的settings.py。而是一个对象，位于django\conf\__init__.py

这是个Settings类的懒加载封装类，直到__getattr__取值时才开始初始化。然后从Settings类的实例中取值。且会讲该值赋值到自己的__dict__上（下次会直接在自己身上找到，因为__getattr__优先级较低）

为了方便debug，我们直接写个run.py。不用命令行的方式。

项目下建个run.py，模拟runserver命令

debug抓一下setting_module

回到setup()中的最后一句apps.populate(settings.INSTALLED_APPS)

开始看apps.populate()

首先看这段

这些App最后都会封装成为AppConfig。且会装载到self.app_configs字典中

随后，分别调用每个appConfig的import_models()和ready()方法。

App的装载部分大体如此

为了方便debug我们改写下最后一句

res的类型是Commanddjango.contrib.staticfiles.management.commands.runserver.Commandobjectat0x00000101ED5163A0

重点是第二句，让我们跳到run_from_argv()方法，这里对参数进行了若干处理。

用pycharm点这里的handle会进入基类的方法，无法得到正确的走向。实际上子类Commond重写了这个方法。

这里分为两种情况，如果是reload重载时，会直接执行inner_run()，而项目启动需要先执行其他逻辑。

django项目启动时，实际上会启动两次，如果我们在项目入口(manage.py)中设置个print，会发现它会打印两次。

第一次启动时，DJANGO_AUTORELOAD_ENV为None，无法进入启动逻辑。会进入restart_with_reloader()。

在这里会将DJANGO_AUTORELOAD_ENV置为True，随后重启。

第二次时，可以进入启动逻辑了。

这里创建了一个django主线程，将inner_run()传入。

随后本线程通过reloader.run(django_main_thread)，创建一个轮询守护进程。

我们接下来看django的主线程inner_run()。

当我们看到wsgi时，django负责的启动逻辑，就此结束了。接下来的工作交由wsgi服务器了

这相当于我们之前在fastapi中说到的，将fastapi的app交由asgi服务器。(asgi也是django提出来的，两者本质同源)

那么这个wsgi是从哪来的？让我们来稍微回溯下

这个settings是一个对象，在之前的操作中已经从settings.py配置文件中获得了自身的属性。所以我们只需要去settings.py配置文件中寻找。

我们来寻找这个get_wsgi_application()。

它会再次调用setup()，重要的是，返回一个WSGIHandler类的实例。

这就是wsgiapp本身。

load_middleware()为构建中间件堆栈，这也是wsgiapp获取setting信息的唯一途径。导入settings.py，生成中间件堆栈。

如果看过我之前那篇fastapi源码的，应该对中间件堆栈不陌生。

app入口→中间件堆栈→路由→路由节点→endpoint

所以，wsgiapp就此构建完毕，服务器传入请求至app入口，即可经过中间件到达路由进行分发。