本文目录
-
什么是WSGI?
-
如何实现Application?
-
如何实现Web Server?
-
Web Server如何决择?
. 什么是WSGI?
WSGI(Web Server Gateway Interface),顾名思义,它既不是服务器,也不是应用,而是一种接口(
规范
),描述
web server
如何与
web application
通信的规范。
那么这个规范是什么?
服务器的请求处理要调用符合WSGI规范的网关接口;
由网关接口来调用应用程序,并且其要定义start_response(status, headers)函数,用于返回响应;
应用程序须是一个可调用对象(函数/类),webapp(environ, start_response)。接受两个参数,environ是环境设置的字典,由服务器和WSGI网关接口设置,start_response是由网关接口定义的函数。
在这个规范中,有三个角色
-
web server
:实现了WSGI server协议的服务器
-
Gateway Interface
:网关接口
-
application
:实现了WSGI application协议的框架
常见的
web server
有
uWSGI
、
Gunicorn
常见的
Gateway Interface
有
CGI
,
WSGI
常见的
application
框架有
Django
、
Flask
为什么要有WSGI规范?
网络通信的完整流程,是这样的
先创建一个web服务器,监听端口,接收请求,并将请求路由转发给对应的应用程序。
再创建一个web应用程序,用于接收到请求,经过必要的处理,返回响应给服务器。
服务器接收响应,返回给客户端(浏览器)
试想一下,假如没有这个规范,此时我们想开发一个网页,我们需要做的就是,先搭建一个服务器,用于监听端口,接收请求,再来创建一个用于接收请求的应用程序。
听起来好像没什么问题。但是你今天开发一个网站,要写一个server,明天又要开发一个网站,又要写一个server。全中国多少web开发人员,如果按照这种模式下去,开发效率可想而知,严重浪费时间人力。
WSGI 就是来解决这个问题的,它解耦了服务器类与应用程序类。
意思就是,假如服务器类和应用程序类都严格遵守WSGI规范,那么应用程序A可以随便挑一个现成的服务器类(B,C,E都可以)来使用,而不需要其他任何的修改,只需要提供一个可以处理这些应用的请求处理类即可,不用担心兼容问题。
我们的主人公
WSGI
,在服务器和应用中间承担一个“翻译官”的角色。只要应用程序符合网关接口的标准,那么服务器就只要做好服务器的角色,应用程序只要做好应用程序的作用,服务器和应用程序之间的通信全靠网关接口来协调。
. 如何实现Application?
WSGI规范 规定了,Application 必须是一个可调用的对象,它可以是函数,可以实现了
__call__
的类的实例对象,也可以是实现了
__iter__
的类对象。
不管是哪种方式的可调用对象,都要遵循两个原则
-
必须接收
environ
,
start_response
两个参数;
-
必须返回
可迭代的对象
。
下面来分别看下这三个例子。
-
application是函数
1def application(environ, start_response):
2
3 response_body = \'The request method was %s\' % environ[\'REQUEST_METHOD\']
4 status = \'200 OK\'
5
6 # 应答的头部是一个列表,每对键值都必须是一个 tuple。
7 response_headers = [(\'Content-Type\', \'text/plain\'),
8 (\'Content-Length\', str(len(response_body)))]
9
10 # 调用服务器程序提供的 start_response,填入两个参数
11 start_response(status, response_headers)
12
13 # 返回必须是 iterable
14 return [response_body]
-
实现了
__call__
的类的实例对象
1class AppClass:
2 \"\"\"这里的可调用对象就是 AppClass 的实例,使用方法类似于:
3 app = AppClass()
4 for result in app(environ, start_response):
5 do_somthing(result)
6 \"\"\"
7
8 def __init__(self):
9 pass
10
11 def __call__(self, environ, start_response):
12 status = \'200 OK\'
13 response_headers = [(\'Content-type\', \'text/plain\')]
14 self.start(status, response_headers)
15 yield \"Hello world!\\n\"
-
实现了
__iter__
的类对象
1class AppClass:
2 \"\"\"这里的可调用对象就是 AppClass 这个类,调用它就能生成可以迭代的结果。
3 使用方法类似于:
4 for result in AppClass(env, start_response):
5 do_somthing(result)
6 \"\"\"
7
8 def __init__(self, environ, start_response):
9 self.environ = environ
10 self.start = start_response
11
12 def __iter__(self):
13 status = \'200 OK\'
14 response_headers = [(\'Content-type\', \'text/plain\')]
15 self.start(status, response_headers)
16 yield \"Hello world!\\n\"
. 如何实现Web Server?
上文说到,
application
必须接收
environ
,
start_response
两个参数。
这两个参数是什么意思?
-
environ
,:是 WSGI的环境信息。
-
start_response
:是响应请求的函数。
其中
start_response
接收两个参数,
-
status
:HTTP状态,譬如:\”
200 OK
\”
-
response_headers
:响应消息的头,譬如:
[(\'Content-Type\', \'text/plain\')]
,以list的形式,每个元素是一个tuple,而一个tuple里有两个元素,一个是key,一个是value。
这两个参数(
environ
,
start_response
),都是由
Web Server
来定义的。
所以我们要自己实现
Web Server
,也必须实现这两个对象。定义完后,要调用application,将这两个参数传入。这是规定。
1import os, sys
2
3def web_server(application):
4 # 构造environ 参数
5 environ = dict(os.environ.items())
6 environ[\'wsgi.input\'] = sys.stdin
7 environ[\'wsgi.errors\'] = sys.stderr
8 environ[\'wsgi.version\'] = (1, 0)
9 environ[\'wsgi.multithread\'] = False
10 environ[\'wsgi.multiprocess\'] = True
11 environ[\'wsgi.run_once\'] = True
12 environ[\'wsgi.url_scheme\'] = \'http\'
13
14 headers_set = []
15
16 # 定义响应函数
17 def start_response(status, response_headers, exc_info=None):
18 headers_set[:] = [status, response_headers]
19
20 # 调用application,并传入参数
21 result = application(environ, start_response)
22
23 # 用for循环,就解释了为什么application要返回可迭代对象
24 for data in result:
25 if data:
26 print(data)
好啦。这里只是简单举个例子。
到了现在,谁也没必要去重要写
web server
了,使用Python最忌讳的就是重复造轮子。那是傻。
. Web Server如何决择?
首先要明白的是,生产环境和开发环境使用的
Web Server
是不一样的。
就拿Django来说,其自带的
Web Server
有如下局限性
-
低性能
:运行起来,只有一个实例,性能可见一斑。
-
低可用
:做为服务启动,只要某个地方ERROR,服务就挂掉了。
-
自带server只有在debug模式下可用映射静态文件,而debug模式下运行会不断留存debug信息,跑久了内存要爆。
如此看来,Django自带的server只能用于开发调试,并不适合用于生产环境。
就连Django官方也是这么说的。
It’s intended only for use while developing. (We’re in the business of making Web frameworks, not Web servers.)
意思是说,Django是一个专业的应用程序端框架,并不擅长于服务端。
果然,专业的事还是得依靠专业的软件来做。
当前市面上,已经出现了很多专业且优秀的
Web Server
,这里也介绍一下。
-
Gunicorn
Gunicorn(从Ruby下面的Unicorn得到的启发)应运而生:依赖Nginx的代理行为,同Nginx进行功能上的分离。由于不需要直接处理用户来的请求(都被Nginx先处理),Gunicorn不需要完成相关的功能,其内部逻辑非常简单:接受从Nginx来的动态请求,处理完之后返回给Nginx,由后者返回给用户。
由于功能定位很明确,Gunicorn得以用纯Python开发:大大缩短了开发时间的同时,性能上也不会很掉链子。同时,它也可以配合Nginx的代理之外的别的Proxy模块工作,其配置也相应比较简单。
配置上的简单,大概是它流行的最大的原因。
-
uWSGI
因为使用C语言开发,会和底层接触的更好,配置也是比较方便,目前和gunicorn两个算是部署时的唯二之选。
-
bjoern
Python WSGI界最牛逼性能的Server其中一个是bjoern,纯C,小于1000行代码,就是看不惯uWSGI的冗余自写的。
介绍完了,那么如何选择呢?
综合网友们的回答,整理如下:
-
Gunicorn,配置简单,快速上手,阻塞较多建议选择
-
uWSGI,首次配置麻烦,性能较好