mvc框架打造笔记之wsgi协议的优缺点以及接口实现

前言:

又是WSGI ,这是我曾经比较熟悉的协议，以前针对实现了wsgi server的unicorn和uwsgi都写过源码解析的文章。  其实他们的实现也很简单，就是给flask、django这样的application传递environ,start_response 。

什么是WSGI协议，什么是WSGI Server，他们的区别是什么？

上线的架构图很容易误导别人，乍一看有nginx这样的web服务器，又有gunicorn这样的wsgi server。  我们先说明wsgi 跟 wsgi server的关系，wsgi是个协议，是web底层跟application解耦的协议。wsgi server是自己做web服务器借用wsgi协议来调用application。 我们需要明确一点，nginx是无法直接跟flask application做通信，需要借用wsgi server。flask本身也有个web服务器是werkzeug，so 才能启动服务并监听端口。记得以前uwsgi没名气的时候，我们都在使用apache + mode_wsgi模式，apache也无法直接跟tornado通信，是借用mod_wsgi把torando做成了unix socket服务，说白了也是启动了一个服务，靠apache来转发。

nginx、apache在这里只是启动了proxy的作用，那为什么不直接把uwsgi和gunicorn给暴露出去，因为nginx的静态文件处理能力极强。

WSGI怎么工作的

wsgi主要是两层，服务器方 和 应用程序 :

1  服务器方：从底层解析http解析，然后调用应用程序，给应用程序提供(环境信息)和(回调函数)， 这个回调函数是用来将应用程序设置的http header和status等信息传递给服务器方.

2  应用程序：用来生成返回的header,body和status,以便返回给服务器方。

WSGI把来自socket的数据包解析为http格式，然后进而变化为environ变量，这environ变量里面有wsgi本身的信息(比如 host， post，进程模式等)，还有client的header及body信息。start_respnse是一个函调函数，必须要附带两个参数，一个是status(http状态)，response_headers(响应的header头信息)。

像flask、django、tornado都会暴露WSGI协议入口，我们只需要自己实现WSGI协议，wsgi server然后给flask传递environ，及start_response, 等到application返回值之后，我再socket send返回客户端。

WSGI的优点、缺点是什么？

优点:

多样的部署选择和组件之间的高度解耦

由于上面提到的高度解耦特性，理论上，任何一个符合WSGI规范的App都可以部署在任何一个实现了WSGI规范的Server上，这给Python Web应用的部署带来了极大的灵活性。

Flask自带了一个基于Werkzeug的调试用服务器。根据Flask的文档，在生产环境不应该使用内建的调试服务器，而应该采取以下方式之一进行部署：

GUNICORN

UWSGI