Nginx+uWSGI+Django原理

168次阅读

共计 3643 个字符，预计需要花费 10 分钟才能阅读完成。

Python 的 Web 开发中，如果使用 Django 框架，那么较为成熟稳定的服务器架构一般是 Nginx+uWSGI+Django。而为什么一定要三个结合在一起呢？直接使用 Django 的 runserver 来启动服务器进程，或者 uWSGI+Django 可不可以呢？为什么？
概念说明：

APP（应用程序），就是开发者写的应用程序，例如 django，bottle 这些。记录怎么处理客户端发来的请求的逻辑部分。
WSGI，是一个协议，Python 用于 Web 开发的协议
uWSGI，是一个程序，充当 Web 服务器或中间件。
- 如果架构是 Nginx+uWSGI+APP，uWSGI 是一个中间件
- 如果架构是 uWSGI+APP，uWSGI 是一个服务器
uwsgi，是 uWSGI 程序实现的一个自有的协议。

Web 协议出现顺序：
CGI -> FCGI -> WSGI -> uwsgi

CGI，最早的协议
FCGI，比 CGI 快
WSGI，Python 专用的协议
uwsgi，比 FCGI 和 WSGI 都快，是 uWSGI 项目自有的协议，主要特征是采用二进制来存储数据，之前的协议都是使用字符串，所以在存储空间和解析速度上，都优于字符串型协议. 官方介绍

一、WSGI 协议

浏览器请求一个页面的流程：

浏览器发送请求给服务器，包含请求头和请求体
服务器解析请求头和请求体
服务器根据请求信息来处理请求，生成返回内容
服务器生成响应头和响应体
服务器返回响应给浏览器，浏览器显示给用户

一个网站，一般有很多个不同的请求，在这些请求中，基本 1，2，4，5 部都是固定的，变的只有第三步，所以把这四步抽象出来，让开发者只关注第三步，这样就可以极大提升开发效率。所以 WSGI 协议诞生了。
WSGI，全称 Web Server Gateway Interface。是 Python 专用的协议，其他语言没有。用于处理 Web 服务器和应用程序（APP）的交互信息。很多 Web 框架（如：django）都会自带 WSGI 服务器，但是性能不好，只作测试用途。

实现一个最简单的服务器

app.py

import pprint
def application(environ, start_response):
pprint.pprint(environ)
start_response('200 OK',[('Content-Type','text/html')])
return'<h1>Hello, web!</h1>'

environ 参数是一个字典对象，保存 HTTP 请求的信息。例如 URL 路径，域名，请求头，请求参数等
start_response 参数是一个函数，用于向 wsgiref 提供响应头的设置，只能调用一次。

server.py

# 从 wsgiref 模块导入:
from wsgiref.simple_server import make_server
# 导入我们自己编写的 application 函数:
from app import application
# 创建一个服务器，IP 地址为空，端口是 8000，处理函数是 application:
httpd = make_server('',8000, application)
print"Serving HTTP on port 8000..."
# 开始监听 HTTP 请求:
httpd.serve_forever()

启动 python server.py, 就可以通过 localhost:8000 访问了

wsgiref 模块是 python 提供的，用于测试和学习的简单的 WSGI 服务器模块。
这个模块监听 8000 端口，把 Http 请求，根据 WSGI 协议，转换 application 函数中的 environ 参数，然后调用 application 函数。
wsgiref 会把 application 函数提供的响应头设置转换为 HTTP 协议的响应头，把 application 的返回（return）作为响应体，根据 HTTP 协议，生成响应，返回给浏览器。

Nginx+uWSGI+Django 原理

这样，应用程序就不需要关注底层的 HTTP 协议细则了

二、CGI 和 FastCGI

CGI 是 Common Gateway Interface，即通用网关接口，是一个协议，是外部应用程序（CGI 程序）与 Web 服务器之间的接口标准。该协议定义了 Web 服务器在调用应用程序时需要传输的参数和应用程序怎么返回结果给 Web 服务器，其实跟 WSGI 类似。
CGI 的一个特点是，对于每一个 HTTP 请求，Web 服务器都会新建一个进程（fork），等应用程序返回结果后，这个进程就会结束。这样的后果是，一旦 HTTP 请求多的时候，Web 服务器会频繁创建进程，大家都知道，创建进程的开销是非常大的，所以这种做法会影响服务器的性能，所以就有了 FastCGI。
FCGI 的做法是在 Web 服务器启动的时候，就创建多个应用程序进程，当 Web 服务器接收到 HTTP 请求时，就把请求分发给其中一个空闲的进程。相当于 MYSQL 连接池的原理。这样就可以避免频繁地 fork 进程。FCGI 另一个特点是支持分布式，也就是 Web 服务器和应用程序可以在不同的机器。
CGI 和 WSGI 的区别是 ：

CGI 的出现更加早，这个是通用的接口，应用程序可以是 Java，Python，等多种语言程序
WSGI 是 Python 专用的，在 CGI 的基础上改进的协议

三、Nginx

Ningx 是一个反向代理服务器
什么是反向代理？

正向代理，例如 FQ 用的代理服务器就是正向代理，浏览器主动请求代理服务器，代理服务器转发请求到对应的目标服务器
反向代理，部署在 Web 服务器上，代理所有外部网络对内部网络的访问。浏览器访问服务器，必须经过这个代理，是被动的。
正向代理的主动方是客户端，反向代理的主动方是 Web 服务器。
结构图：

反向代理的作用：

安全，客户端对 Web 服务器的访问需要先经过反向代理服务器。这样可以防止外部程序对 Web 服务器的直接攻击。
负载均衡，反向代理服务器可以根据 Web 服务器的负载情况，动态地把 HTTP 请求交给不同的 Web 服务器来处理，前提是要有多个 Web 服务器。
提升 Web 服务器的 IO 性能。一个 HTTP 请求的数据，从客户端传输给服务器，是需要时间的，例如 N 秒，如果直接传给 Web 服务器，Web 服务器就需要让一个进程阻塞 N 秒，来接收 IO，这样会降低 Web 服务器的性能。如果使用反向代理服务器，先让反向代理服务器接收完整个 HTTP 请求，再把请求发给 Web 服务器，就能提升 Web 服务器的性能。还有一些静态文件的请求，可以直接交给反向代理来处理，不需要经过 Web 服务器。

Nginx 是一个高性能的 HTTP 和反向代理服务器。

Nginx+uWSGI+ 应用程序的架构：
Nginx+uWSGI+Django 原理

其中 Nginx 和 uWSGI 之间可以通过 CGI，FCGI 和 uwsgi 协议通信，当然 uwsgi 的性能是最好的。