Python中关于nginx+uWSGI+django架构数据传输的问题

最近在看这几个概念有点混淆,有几个问题想请教一下

  1. nginx+uWSGI+django 解析 http 协议是在哪个上面解析的?
  2. nginx+uWSGI 通信的协议(或者说规范)是什么?
  3. uWSGI+django 通信的规范是什么?
  4. 网上说 uWSGI 实现了 http 协议,是否 uWSGI+django 的架构上,uWSGI 负责 http 的解析
  5. 只有 django 的话,是不是内部也实现了一个简单的 类似 nginx+uWSGI 的东西
  6. flask 框架依赖于 werkzeug ,这个东西是不是跟 uWSGI 一个层次的东西

希望不吝赐教啊!


Python中关于nginx+uWSGI+django架构数据传输的问题

17 回复

我无法理解你的问题


客户端发送 HTTP 协议到 Nginx,然后 Nginx 发送 uwsgi 协议到 uWSGI,然后 uWSGI 调用 Django/flask 的 WSGI application

只有 django 的话,是不存在 uWSGI 这一层,直接接受 HTTP 协议,然后调用 Django 的 WSGI application

  1. nginx 粗解析,比如头,uWSGI 细解析,比如 URL。
    2. 是 uwsgi ( uWSGI 是程序 uwsgi 是协议)
    3. 是 WSGI。uWSGI 直接调用 libpython.so 其他的都是代码接口。明白了吧
    4. uwsgi 协议是 http 的一个超集。可以看成一个 RPC。但是同时 uWSGI 作者精力太旺盛实现了 http http/1.1 https 静态文件输出 cache 服务 key-value 服务 crontab 服务等。可以代替 nginx 直接监听 80 端口。可以代替 supervisor 监控进程。所以 uWSGI 也重新实现了全套 http 解析服务。
    5. runserver 实现了。但是只是开发用。
    6. 是基于 WSGI 的一些助手工具中间件。

插楼问一句 uwsgi 和 gunicorn 那个更好

nginx+uWSGI+django 解析 http 协议是在哪个上面解析的?
http 是个文本协议,django 来解析的。

nginx+uWSGI 通信的协议(或者说规范)是什么?
uwsgi 是一种线路协议而不是通信协议,在此常用于在 uWSGI 服务器与其他网络服务器的数据通信。uwsgi 协议是一个 uWSGI 服务器自有的协议,它用于定义传输信息的类型。

uWSGI+django 通信的规范是什么?
WSGI 协议。这东西是一个 Gateway,也就是网关。网关的作用就是在协议之间进行转换。

网上说 uWSGI 实现了 http 协议,是否 uWSGI+django 的架构上,uWSGI 负责 http 的解析
不是。

只有 django 的话,是不是内部也实现了一个简单的 类似 nginx+uWSGI 的东西
Django 所提供的是一个开发服务器,这个开发服务器,没有经过安全测试,而且使用的是 Python 自带的 simple HTTPServer 创建的,在安全性和效率上都是不行的。虽然不要 nginx 和 uWSGI 也可以跑,只不过 django runsever 原生为单线程,当第一个请求没有完成时,第二个请求辉阻塞,知道第一个请求完成,第二个请求才会执行。nginx 是线 web 服务器主要起到了调度,转发,处理静态文件等作用。uWSGI 是 nginx 和 app 之间的桥梁,起到多进程并发,转换协议接口等作用。

flask 框架依赖于 werkzeug ,这个东西是不是跟 uWSGI 一个层次的东西
不是。werkzeug 既不是一个 web 服务器,也不是一个 web 框架,而是是一个 WSGI 工具包,它可以作为一个 Web 框架的底层库,因为它封装好了很多 Web 框架的东西,例如 Request,Response 等等。

我当时选择 gunicorn 的原因是 gunicorn 支持用.py 作为配置文件,可以根据 cpu 核数配置 gunicorn 的 process 数量。


各有优势
Gun 是纯 python 实现的,容易配置和 hack,配合 gevent 时处理部分阻塞请求的性能高。
uW 是 C 实现的,大量非阻塞短请求优势明显,但是配置麻烦一些。
总体上 uW 略占优。

django 的 runserver 是多线程的

请问,werkzeug 是不是类似于封装了很多 http 请求的东西,然后用它根据 WSGI 规范能写一个 uWSGI 和 django 通信,根据 uwsgi 规范我可以写一个 uWSGI 与 nginx 通信

uWSGI 也能做到 py 文件配置。甚至可以通过 py 指令动态配置。

还可以在配置文件里计算。比如根据 CPU 核心数量的一半配置 process 数量。想不到吧!

WSGI 只是一个 python 代码接口。werkzeug 在这个接口之上封装了很多工具。

WSGI 之下是 uWSGI 真正监听端口跑起来

一般不推荐写 uwsgi 协议。太蛋痛了。

不懂就不要瞎说。py 的多线程就是 native os thread。跑 http 是会释放 GIL 的。

谁告诉你不能利用多核就是伪多线程了?那么多 C++ 写的游戏,都只吃单个 CPU,他们都是单线程的?

好吧,你说服我了,Python 的多线程确实是操作系统真多线程。那我改成说是伪平行总可以了吧。

你即使把鸡叫小姐也改变不了婊子的性质啊(逃)

功能强大来说 uwsgi 好一万倍。

配置难度来说其实一样。如果你只看国内 csdn 级别文章肯定都推荐 gunicorn

要自己去修改一些底层逻辑,gunicorn 更简单。uWSGI 的 C 代码全世界估计只有作者会改。3 层 for 循环嵌套。

runserver 确实默认是多线程启动的。写的时候没有太注意,其实是想说 django 应用是单线程的阻塞的,而且 python 有 GIL,也是伪多线程。

回到顶部