写在部署前
在线上部署django项目时，比较成熟的方案是：nginx + uWSGI + Django。 nginx和Django 都比较熟悉了，uWSGI是什么呢？WSGI是一个协议，python用于web开发的协议，uWSGI则是一个程序，充当WEB服务器或者中间件。当Nginsx+uWSGI+Django一起使用时，uWSGI就是个中间件，如果直接用django+uWSGI时，uWSGI就是个WEB服务器。
说下WEB协议出现的顺序： CGI --> FCGI --> WSGI --> uwsgi。
CGI是最早的协议，然后FCGI顾名思义就是比CGI更快，WSGI是Python专用的协议，uwsgi比FCGI和WSGI都快，是uWSGI项目的自有协议，主要特征是采用二进制来存储数据，
之前的协议都是存储字符串，所以在存储空间和解析速度上，都会优于字符串协议。附官方资料地址：http://uwsgi-docs.readthedocs.io/en/latest/FAQ.html
CGI = Common Gateway Interface，通用网关接口 顾名思义，它是一种接口规范。该规范详细定义了Web服务器中运行的服务器代理程序，怎样获取及返回网页生成过程中，服务器环境上下文和HTTP协议中的参数名称， 如大家所熟知的：REQUEST_METHOD，QUERY_STRING，CONTENT_TYPE等等。绝大部分的Web服务器程序，是以脚本的形式代理接受并处理HTTP请求，返回HTTP页面或响应。 这些脚本程序，就是大家所熟知的PHP、ASP、JSP等等。 FCGI = Fast CGI 它其实是CGI在具体实现中的的一个变种。其设计思路是，通过减少CGI代理程序和Web宿主服务程序的通信开销，从而达到提高Web服务性能的最终目的。 由此可见，FCGI在规范上跟CGI并没有不同， 只是具体实现方式上有所改进： CGI的做法是，对于每个HTTP请求，Web宿主服务程序都建立新的进程以调用服务器脚本，响应该请求；大量HTTP请求时，服务器频繁创建进程会影响服务器性能。 FCGI的做法是，建立一个独立的FCGI服务程序进程，和Web宿主服务程序进程通信，FCGI服务进程被一旦启动后，自己分配资源、创建线程响应HTTP请求、并决定自身生命周期， 从而大大降低了系统为了创建进程而做出的资源开销。FCGI还支持分布式，也就是WEB服务器和应用程序可以再不通的机器上。 现代流行的Web服务器程序，如PHP、ASP.Net，基本都是FCGI的实现。 SCGI = Simple CGI 它是FCGI在精简数据协议和响应过程后的产物。其设计目的是为了适应越来越多基于AJAX或REST的HTTP请求，而做出更快更简洁的应答。 并且SCGI约定，当服务器返回对一个HTTP协议请求响应后，立刻关闭该HTTP连接。所以不难看出，SCGI更加适合于普遍意义上SOA所提倡的“请求-忘记”这种通信模式。 WSGI = Web Server Gateway Interface 此协议是Python语言的专利，它定义了一组在Web服务宿主程序和HTTP响应代理程序之间通信的普遍适用的接口。 它的产生是因为Python程序员注意到，对于Web框架和Web宿主服务器程序间，有严重的耦合性，比如说，某些框架是针对Apache的mod_python设计的。 于是，WSGI就定义了一套非常低级别的接口。常见的Python Web框架都实现了这个协议：如 CherryPy, Django, web.py, web2py, TurboGears, Tornado, Pylons, BlueBream, Google App Engine[dubious – discuss], Trac, Flask, Pyramid,等等.