guicorn 是什么

guicorn 是什么?

在回答问题之前我们先来看看 web服务器的典型过程[1]

1. 建立链接：如果没有连接，要建立连接

2. 接收请求：对客户端发来的请求进行解析。

3. 处理请求：转发给预定义的处理器。

4. 访问资源、处理资源：

                    访问资源 处理器根据请求访问资源，资源可能存在于数据库中或文件系统中等。

                    处理资源 返回数据，通常根据取出的数据对模板进行渲染（填充模板的过程）然后将渲染了的内容返回

5. 构建响应：构建http响应报文，包括响应状态码，响应头和响应实体。响应实体中包含了数据。

6. 发送响应：将响应发送给客户端，可以做 关闭连接 

7. 日志记录

 

 

我们知道像django，flask，tornado这些web 应用框架(web framework) 负责数据库连接存取，

页面、数据的生成，session的管理, url dispatch等。也就是说，这些web应用框架主要在做第3 第4件事情。

那么1. 2. 5. 中这些相对底层的事情——对http 协议的处理是谁来做的呢？是http服务器。

那么http服务器如何与web 应用之间框架沟通呢？这就需要WSGI了。

 

 

WSGI 类似一种协议，定义了http服务器 和 web 应用 之间的互相沟通的方式。

第2步到第3步，http 请求从http服务器给了web应用，中间需要通过WSGI的沟通，

同样，由第4步到第5步，web应用将响应给了http服务器，中间也需要通过WSGI沟通。

此处如果觉得博主理解得不准，请参考 PEP3333 

 

 

显然，它的好处是 web应用框架与 http服务器的解耦。

另外，通过提供统一的接口，使得程序员不必关心http协议的底层处理细节，而专注于 业务逻辑上的开发。

 

 

回到问题，guicorn是什么呢？它实现了WSGI，同时它还是http服务器。

因为gunicorn实现了WSGI, flask 在 gunicorn 上能跑，在其他实现了WSGI的服务器上 也能愉快地运行。

 

 

为啥要用它呢？

django 是有自己的wsgi的，把gunicorn做django的WSGI服务器，可以很灵活地配置worker数量，以提高并发量；

当web应用长时间未响应，会重启worker进程，有『临时』起死回生的功效；其他特性。

 

 以上讲了gunicorn的作用，下面就顺便讲一下gunicorn的配置吧:) 

 

gunicorn的配置

bind 绑定的ip以及端口号。部署后可通过访问该ip及端口号可访问web服务。

但是通常会在gunicorn前加 nginx 做为反向代理。

 

workers 对应 处理进程的数目。是重要的配置。

通过命令 ps aux | grep 'gunicorn' 可以看到进程的数目与配置文件中的数目相符。

有推荐 (2*cpu核数)+1的，实际要看具体情况，请求量小完全不用这么配，以减少不必要的内存消耗。

 

timeout 超时参数，如果web应用服务器超过了此时间仍未响应那么将重启worker，显然，重启期间 服务不可用。

假如web应用服务器在重启前 阻塞住了，那么重启之后阻塞 可能 消失，此时服务可用。但如果阻塞原因没有消除，

那么web应用服务器 早晚还是会阻塞，阻塞时间太长了，引起worker再次重启。这就是所谓的『临时』起死回生。

 

daemon 是否为守护进程。

pythonpath python路径。

preload_app 配成 True 可在worker 进程fork前加载代码，推荐一试。

其他参数参考 这个。

  

讲完了gunicorn的配置，再讲讲guicorn的部署吧！

 

启动gunicorn 

举例

/home/venv/bin/python /home/venv/bin/gunicorn -c start_gunicorn.py wsgi:app

其中 -c 指定配置文件

wsgi.py文件中写web 应用程序，请注意下wsgi文件的路径。

博主不太懂的地方，在于奇怪的冒号。冒号左边的部分表示定义程序的包或者模块,冒号右边的部分表示包中程序实例的名字[2]

貌似，没有冒号也是可以的；）参考 gunicorn with django

 

 

题外话

web后端 最最简单粗暴的理解：拿到请求，查查数据库，扔回给客户端 （博主遁走

 

观点

1. guicorn = WSGI服务器 + http服务器。

2. 对django来讲，它是一个更好的WSGI服务器（能起多个worker 等），另外 它还能处理http请求。

3. 想充分了解WSGI 看 PEP3333.

 

参考 

[1] http权威指南, 第五章; redis 实战, 第二章

[2] http://www.jianshu.com/p/7bc34e56fa39

 

如果讲的不准，欢迎拍砖 ;)

2016年5月5号