uWSGI详解

WSGI是什么？

WSGI，全称 Web Server Gateway Interface，或者 Python Web Server Gateway Interface ，是为 Python 语言定义的 Web 服务器和 Web 应用程序或框架之间的一种简单而通用的接口。自从 WSGI 被开发出来以后，许多其它语言中也出现了类似接口。

WSGI 的官方定义是，the Python Web Server Gateway Interface。从名字就可以看出来，这东西是一个Gateway，也就是网关。网关的作用就是在协议之间进行转换。

WSGI 是作为 Web 服务器与 Web 应用程序或应用框架之间的一种低级别的接口，以提升可移植 Web 应用开发的共同点。WSGI 是基于现存的 CGI 标准而设计的。

很多框架都自带了 WSGI server ，比如 Flask，webpy，Django、CherryPy等等。当然性能都不好，自带的 web server 更多的是测试用途，发布时则使用生产环境的 WSGI server或者是联合 nginx 做 uwsgi 。

也就是说，WSGI就像是一座桥梁，一边连着web服务器，另一边连着用户的应用。但是呢，这个桥的功能很弱，有时候还需要别的桥来帮忙才能进行处理。WSGI 的作用如图所示：

WSGI的作用

WSGI有两方：“服务器”或“网关”一方，以及“应用程序”或“应用框架”一方。服务方调用应用方，提供环境信息，以及一个回调函数（提供给应用程序用来将消息头传递给服务器方），并接收Web内容作为返回值。

所谓的 WSGI中间件同时实现了API的两方，因此可以在WSGI服务和WSGI应用之间起调解作用：从WSGI服务器的角度来说，中间件扮演应用程序，而从应用程序的角度来说，中间件扮演服务器。“中间件”组件可以执行以下功能：

WSGI 的设计确实参考了 Java 的 servlet。

接下来，我们要介绍的是 uWSGI。

uWSGI

uWSGI是一个Web服务器，它实现了WSGI协议、uwsgi、http等协议。Nginx中HttpUwsgiModule的作用是与uWSGI服务器进行交换。

要注意 WSGI / uwsgi / uWSGI 这三个概念的区分。

uwsgi协议是一个uWSGI服务器自有的协议，它用于定义传输信息的类型（type of information），每一个uwsgi packet前4byte为传输信息类型描述，它与WSGI相比是两样东西。

为什么有了uWSGI为什么还需要nginx？因为nginx具备优秀的静态内容处理能力，然后将动态内容转发给uWSGI服务器，这样可以达到很好的客户端响应。

接下来，我们要看看 uWSGI 的安装配置与使用。

安装

uWSGI 的安装很简单：

现在我们试下将 Django 跑起来。我们先在 virtualenv 创建一个 Django Project：

virtualenv 的路径与目录文件如下：

Django Project 的路径与目录文件如下：

测试uwsgi

在你的服务器上写一个test.py：

我的 test.py 的路径是 /root/nowamagic_venv/nowamagic_pj/test.py，执行以下命令：

测试你的 Django 项目

前面我们用 django-admin.py startproject nowamagic_pj 创建了一个项目，现在我们用 Django 自带的 Web 服务器看看我们的项目有没出问题。还是进入我们虚拟环境：

执行这个命令报错：No module named django.core.management，原因应该是装了多个版本的Python导致的。命令指定文件路径就行，丑是丑些了：

OK，启动 Django 自带的服务器了，我们再访问 http://115.28.0.89:8002/，成功显示：

说明 Djanggo 项目也没问题。

连接Django和uwsgi

最后一步了，我们要把uwsgi与Django连接起来。

编写django_wsgi.py文件，将其放在与文件manage.py同一个目录下。我的放在 /root/nowamagic_venv/nowamagic_pj/ 下：

注意不要直接 copy，有个地方要改：注意到语句os.environ.setdefault。比如我的项目为nowamagic_pj，则语句应该是 os.environ.setdefault(“DJANGO_SETTINGS_MODULE”, “nowamagic_pj.settings”)

OK，进入虚拟环境执行指令：

成功显示 Django It Works 页面。

这样，你就可以在浏览器中访问你的Django程序了。所有的请求都是经过uwsgi传递给Django程序的。

这里我们介绍了如何把uwsgi与Django连接起来，在下一篇将继续介绍如何将uwsgi与Nginx连接。

上一篇介绍了 uWSGI 来部署 Django 程序，但在在生产环境中单单只有 uWSGI 是不够的，Nginx是必不可少的工具。

先安装 Nginx，可以参照前面的小节：使用RPM安装Nginx。

Nginx 配置

在 nginx.conf 上加入/修改，我的 server 配置如下（一切从简……）：

注意保证配置里写的目录 /home/nowamagic/logs/ 和 /home/nowamagic/logs/ 存在，接下来就没啥问题了，Nginx 配置很简单。

uWSGI 配置

前面我们是直接使用命令行来启动 uWSGI，在实际部署环境中，我们常用的是配置文件的方式，而非命令行的方式。

我的 Django 程序目录：/root/nowamagic_venv/nowamagic_pj/

这里让 Nginx 采用 8077 端口与 uWSGI 通讯，请确保此端口没有被其它程序采用。

uWSGI 支持多种配置文件格式，比如 xml，ini，json 等等都可以。

1. xml 配置

请确定你在上一节中的django_wsgi.py文件已经存在了。新建一个XML文件：nowamagic_pj.xml，将它放在 /root/nowamagic_venv/nowamagic_pj 目录下

然后执行命令：

加载指定的xml配置文件。当使用命令行参数时，可以使用简化命令“-x”。当然也可以不简写：

甚至如果在命令行的最后一个参数以“.xml”结尾，那么就隐含将加载该xml文件作为配置。

有时候因各种环境问题，-x –xml 命令识别不了，可以使用下面的 ini 配置方式：

2. ini 配置

然后执行命令：

uwsgi 这样就启动起来了。如果无意外的话，就能在网上访问你的 Python 项目了。

小插曲

我在配置完 Nginx 和 uWSGI 之后，访问时显示 502 错误。查看 uWSGI 启动信息，发现这么一条：ImportError: No module named django.core.wsgi。

然后推断，我的 CentOS 上的 Python 版本是 2.4.3，然后进入 virtualenv，执行：

则没报错，因为我的虚拟环境里的 Python 版本是 2.7.5。推断成立，但是虚拟环境里的 Django 会默认调用外部环境的 Python。解决方法：在虚拟环境里 pip install django。

OK，问题解决，一切正常。

附

一些我在配置时用到的命令，省得你去搜索：

1. 关闭 uWSGI：

2. 列出端口占用情况：