精华内容
下载资源
问答
  • Nginx+uWSGI+Django原理

    2017-10-22 23:18:13
    Python的Web开发中,如果使用Django框架,那么较为成熟稳定的服务器架构一般是Nginx+uWSGI+Django。

    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协议,生成响应,返回给浏览器。

    Alt text

    这样,应用程序就不需要关注底层的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+应用程序的架构:
    Alt text

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

    uWSGI+Django比单独使用Django的好处:
        支持的并发量更高
        方便管理多进程,发挥多核的优势
        提升性能,因为uwsgi协议比WSGI协议有优势
    Nginx+uWSGI+Django比uWSGI+Django好处(参考反向代理的作用):
    

    最后附上一个介绍Nginx+uWSGI+Django的幻灯片

    参考:
    http://www.biaodianfu.com/cgi-fastcgi-wsgi.html
    http://blog.csdn.net/qiaofeiw/article/details/9207359
    http://www.cnblogs.com/wanghetao/p/3934350.html
    http://book.51cto.com/art/201202/314840.htm
    http://www.liaoxuefeng.com/wiki/001374738125095c955c1e6d8bb493182103fac9270762a000/001386832689740b04430a98f614b6da89da2157ea3efe2000
    https://www.douban.com/note/13508388/
    http://www.nowamagic.net/academy/detail/1330308
    http://www.itopers.com:8080/?p=586

    展开全文
  • Nginx+uWSGI+Django原理 Python的Web开发中,如果使用Django框架,那么较为成熟稳定的服务器架构一般是Nginx+uWSGI+Django。而为什么一定要三个结合在一起呢?直接使用Django的runserver来启动服务器进程,或者...

    Nginx+uWSGI+Django原理

    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

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

    一、WSGI协议

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

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

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

    实现一个最简单的服务器

    1. app.py
    1. import pprint
    2. def application(environ, start_response):
    3. pprint.pprint(environ)
    4. start_response('200 OK',[('Content-Type','text/html')])
    5. return'<h1>Hello, web!</h1>'
    • environ参数是一个字典对象,保存HTTP请求的信息。例如URL路径,域名,请求头,请求参数等
    • start_response参数是一个函数,用于向wsgiref提供响应头的设置,只能调用一次。
    1. server.py
    1. # 从wsgiref模块导入:
    2. from wsgiref.simple_server import make_server
    3. # 导入我们自己编写的application函数:
    4. from app import application
    5.  
    6. # 创建一个服务器,IP地址为空,端口是8000,处理函数是application:
    7. httpd = make_server('',8000, application)
    8. print"Serving HTTP on port 8000..."
    9. # 开始监听HTTP请求:
    10. httpd.serve_forever()
    1. 启动python server.py,就可以通过localhost:8000访问了

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

    Alt text

    这样,应用程序就不需要关注底层的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是一个反向代理服务器 
    什么是反向代理?

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

    反向代理的作用:

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

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

    Nginx+uWSGI+应用程序的架构: 
    Alt text

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

    四、总结

    1. uWSGI+Django比单独使用Django的好处:
      • 支持的并发量更高
      • 方便管理多进程,发挥多核的优势
      • 提升性能,因为uwsgi协议比WSGI协议有优势
    2. Nginx+uWSGI+Django比uWSGI+Django好处(参考反向代理的作用):

    最后附上一个介绍Nginx+uWSGI+Django的幻灯片

    参考: 
    http://www.biaodianfu.com/cgi-fastcgi-wsgi.html 
    http://blog.csdn.net/qiaofeiw/article/details/9207359 
    http://www.cnblogs.com/wanghetao/p/3934350.html 
    http://book.51cto.com/art/201202/314840.htm 
    http://www.liaoxuefeng.com/wiki/001374738125095c955c1e6d8bb493182103fac9270762a000/001386832689740b04430a98f614b6da89da2157ea3efe2000 
    https://www.douban.com/note/13508388/ 
    http://www.nowamagic.net/academy/detail/1330308 
    http://www.itopers.com:8080/?p=586

     

    分类: Python

    好文要顶 关注我 收藏该文  

    Xjng
    关注 - 3
    粉丝 - 53

    +加关注

    8

    0

    « 上一篇:uWSGI uwsgi_response_write_body_do(): Connection reset by peer 报错的解决方法
    » 下一篇:Python中docstring文档的写法

    posted @ 2016-05-16 18:21 Xjng 阅读(13233) 评论(11) 编辑 收藏

     

    展开全文
  • uWSGI详解

    万次阅读 多人点赞 2016-05-09 17:49:49
    uwsgi协议是一个uWSGI服务器自有的协议,它用于定义传输信息的类型(type of information),每一个uwsgi packet前4byte为传输信息类型描述,它与WSGI相比是两样东西。 为什么有了uWSGI为什么还需要nginx?因为...

    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服务器的角度来说,中间件扮演应用程序,而从应用程序的角度来说,中间件扮演服务器。“中间件”组件可以执行以下功能:

    • 重写环境变量后,根据目标URL,将请求消息路由到不同的应用对象。
    • 允许在一个进程中同时运行多个应用程序或应用框架。
    • 负载均衡和远程处理,通过在网络上转发请求和响应消息。
    • 进行内容后处理,例如应用XSLT样式表。

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


    接下来,我们要介绍的是 uWSGI

    uWSGI

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

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

    • WSGI看过前面小节的同学很清楚了,是一种通信协议。
    • uwsgi同WSGI一样是一种通信协议。
    • 而uWSGI是实现了uwsgi和WSGI两种协议的Web服务器。

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

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

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

    安装

    uWSGI 的安装很简单:

    1 pip install uwsgi

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

    1 [root@nowamagic ~]# cd nowamagic_venv
    2 [root@nowamagic nowamagic_venv]# source bin/activate
    3 (nowamagic_venv)[root@nowamagic nowamagic_venv]# django-admin.py startproject nowamagic_pj

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


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


    测试uwsgi

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

    1 # test.py
    2 def application(env, start_response):
    3     start_response('200 OK', [('Content-Type','text/html')])
    4     return "Hello World"

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

    1 [root@nowamagic ~]# cd nowamagic_venv
    2 [root@nowamagic nowamagic_venv]# source bin/activate
    3 (nowamagic_venv)[root@nowamagic nowamagic_venv]# uwsgi --http :8001 --wsgi-file /root/nowamagic_venv/nowamagic_pj/test.py

    访问网页 http://115.28.0.89:8001/,OK,显示 Hello World,说明 uwsgi 安装成功。

    测试你的 Django 项目

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

    1 [root@nowamagic ~]# cd nowamagic_venv
    2 [root@nowamagic nowamagic_venv]# source bin/activate
    3 (nowamagic_venv)[root@nowamagic nowamagic_venv]# python2.7 /root/nowamagic_venv/nowamagic_pj/manage.py runserver 0.0.0.0:8002

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

    view source
    print?
    1 (nowamagic_venv)[root@nowamagic nowamagic_venv]# /usr/local/bin/python2.7 /root/nowamagic_venv/nowamagic_pj/manage.py runserver 0.0.0.0:8002

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


    说明 Djanggo 项目也没问题。

    连接Django和uwsgi

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

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

    view source
    print?
    01 #!/usr/bin/env python
    02 # coding: utf-8
    03  
    04 import os
    05 import sys
    06  
    07 # 将系统的编码设置为UTF8
    08 reload(sys)
    09 sys.setdefaultencoding('utf8')
    10  
    11 os.environ.setdefault("DJANGO_SETTINGS_MODULE","nowamagic_pj.settings")
    12  
    13 from django.core.handlers.wsgi import WSGIHandler
    14 application = WSGIHandler()
    注意不要直接 copy,有个地方要改:注意到语句os.environ.setdefault。比如我的项目为nowamagic_pj,则语句应该是 os.environ.setdefault("DJANGO_SETTINGS_MODULE", "nowamagic_pj.settings")

    OK,进入虚拟环境执行指令:

    1 [root@nowamagic ~]# cd nowamagic_venv
    2 [root@nowamagic nowamagic_venv]# source bin/activate
    3 (nowamagic_venv)[root@nowamagic nowamagic_venv]# uwsgi --http :8000 --chdir /root/nowamagic_venv/nowamagic_pj/ --module django_wsgi

    成功显示 Django It Works 页面。

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

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

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

    先安装 Nginx,可以参照前面的小节:使用RPM安装Nginx

    Nginx 配置

    在 nginx.conf 上加入/修改,我的 server 配置如下(一切从简……):

    01 server {
    02     listen       80;
    03     server_name  115.28.0.89;
    04     #server_name localhost;
    05  
    06     access_log /home/nowamagic/logs/access.log;
    07     error_log /home/nowamagic/logs/error.log;
    08  
    09     #root         /root/nowamagic_venv/nowamagic_pj;
    10     location / {
    11         uwsgi_pass 127.0.0.1:8077;
    12         #include uwsgi_params;
    13         include /etc/nginx/uwsgi_params;
    14         #uwsgi_pass 127.0.0.1:8077;
    15         #uwsgi_param UWSGI_SCRIPT index;
    16         #uwsgi_param UWSGI_PYHOME $document_root;
    17         #uwsgi_param UWSGI_CHDIR  $document_root;
    18    }
    19    access_log off;
    20 }

    注意保证配置里写的目录 /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 目录下

    01 <uwsgi>
    02  <socket>127.0.0.1:8077</socket>
    03  <listen>80</listen>
    04  <master>true</master>
    05  <pythonpath>/root/nowamagic_venv/nowamagic_pj</pythonpath>
    06  <processes>1</processes>
    07  <logdate>true</logdate>
    08  <daemonize>/var/log/uwsgi.log</daemonize>
    09  <plugins>python</plugins>
    10 </uwsgi>

    然后执行命令:

    1 uwsgi -x /root/nowamagic_venv/nowamagic_pj/nowamagic_pj.xml
    2 or
    3 /usr/local/bin/uwsgi -x /root/nowamagic_venv/nowamagic_pj/nowamagic_pj.xml

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

    1 uwsgi --xml /etc/nowamagic.xml

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

    1 uwsgi /etc/nowamagic.xml

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

    2. ini 配置

    01 [uwsgi]
    02 vhost = false
    03 plugins = python
    04 socket = 127.0.0.1:8077
    05 master = true
    06 enable-threads = true
    07 workers = 1
    08 wsgi-file = /root/nowamagic_venv/nowamagic_pj/nowamagic_pj/wsgi.py
    09 virtualenv = /root/nowamagic_venv
    10 chdir = /root/nowamagic_venv/nowamagic_pj

    然后执行命令:

    1 uwsgi --ini /root/nowamagic_venv/nowamagic_pj.ini&

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

    小插曲

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

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

    1 python
    2 <<< import django
    3 <<< from django.core.wsgi import get_wsgi_application
    4 <<<

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

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

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

    1. 关闭 uWSGI:

    1 killall  -9 uwsgi
    2 killall -s HUP /var/www/uwsgi 
    3 killall -s HUP /usr/local/bin/uwsgi

    2. 列出端口占用情况:

    1 netstat -lpnt

    展开全文
  • nginx+uWSGI的部署原理

    2020-05-12 08:37:48
    ginx 和 uWISG 服务器之间如何配合工作的...uwsgi 和 WSGI 协议,找到对应的 Django 框架,Django 框架下的应用进行逻辑处理后,将返回值发送到 uwsgi 服务,然后 uwsgi 服务再返回给 nginx,最后 nginx 将返回值返回给

    ginx 和 uWISG 服务器之间如何配合工作的
    首先浏览器发起 http 请求到 nginx 服务,Nginx 根据接收到请求包,进行 url 分析,判断访问的资源类型,如果是静态资源,直接读取静态资源返回给浏览器,如果请求的是动态资源就转交给 uwsgi 服务,uwsgi 服务根据自身的 uwsgi 和 WSGI 协议,找到对应的 Django 框架,Django 框架下的应用进行逻辑处理后,将返回值发送到 uwsgi 服务,然后 uwsgi 服务再返回给 nginx,最后 nginx 将返回值返回给浏览器进行渲染显示给用户。

    摘自(https://blog.csdn.net/weixin_42218868/article/details/99660895)

    WSGI、uWSGI和nginx之间的关系

    WSGI 是一种 Web 服务器网关接口。它是一 个 Web 服务器(如 nginx,uWSGI 等服务器)与 web 应用(如用 Flask 框架写的程序)通信的一种规范。 简单而言, WSGI 是一种通信协议。

    uWSGI 是一个 Web 服务器,它实现了 WSGI、uwsgi等协议。uwsgi协议是一个uWSGI服务器自有的协议,uwsgi 是一种线路协议而不是通信协议,在此常用于在 uWSGI 服务器与其他网络服务器的数据通信。 简单而言,uWSGI 是实现了 uwsgi 和 WSGI 两种协议的 Web 服务器。

    nginx 是一个开源的高性能的 HTTP 服务器和反向代理:

    作为 web 服务器,它处理静态文件和索引文件效果非常高;
    它的设计非常注重效率,最大支持 5 万个并发连接,但只占用很少的内存空间;
    稳定性高,配置简洁;
    强大的反向代理和负载均衡功能,平衡集群中各个服务器的负载压力应用

    在这里插入图片描述
    摘自(https://blog.csdn.net/apollo_miracle/article/details/86910402?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-3.nonecase&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-3.nonecase)

    展开全文
  • uWSGI+django+nginx的工作原理流程与部署历程

    万次阅读 多人点赞 2016-11-20 22:24:40
    uWSGI+django+nginx工作原理流程及部署过程 django 一个基于python的开源web框架 uWSGI 一个基于自有的uwsgi协议、wsgi协议和http服务协议的web网关 nginx 常用高性能代理服务器 wsgi.py django项目携带的一个wsgi...
  • uwsgi 理解

    千次阅读 2018-03-12 01:33:05
    uwsgi 理解
  • uWSGI+Django+Nginx的工作原理流程与部署历程:https://blog.csdn.net/c465869935/article/details/53242126 WSGI WSGI的全称是Web Server Gateway Interface(Web服务器网关接口),它不是服务器、python模块、...
  • uWSGI/nginx/django的工作原理流程

    千次阅读 2019-06-22 20:01:29
    uwsgi:一种通信协议,是uWSGI服务器自有的协议,它用于定义传输信息的类型。 uWSGI:一种python web server或称为Server/Gateway,实现了uwsgi和WSGI两种协议的web服务器,负责响应python的web...
  • uwsgi+nginx原理介绍

    千次阅读 2019-07-30 16:35:03
    1.WIGS(Web Server Gateway ...Nginx接受来自客户端的Http请求发送给uWSGIuWSGI处理请求并将关键信息传递给web应用(django,flask等),应用返回Response经由uWSGI发送给Nginx,Nginx再发送给客户端。
  • WSGI、uwsgiuWSGI的详解

    千次阅读 2020-03-17 23:18:20
    uWSGI uWSGI是实现了uwsgi和WSGI两种协议的Web服务器,使用c语言开发。 其他说明 两级结构 在这种结构里,uWSGI作为服务器,它用到了HTTP协议以及wsgi协议,flask应用作为application,实现了wsgi协议。当有客户端...
  • 其中的socket字段值”0.0.0.0:9090”必须要和上面写的density.conf配置文件中的uWSGI监听地址 完全一样 ;  chdir指自己工程的绝对路径;  module指的是wsgi.py在自己工程中的相对路径,”.”指代一层目录;我的...
  • 原理一  Http请求和web服务器 一、Http请求   用户打开浏览器并输入一串url地址时,到最终页面内容呈现在用户眼前时,这之间的步骤可大致整理如下:   &n...
  • uWSGI+django+nginx的工作原理流程

    千次阅读 2018-09-28 20:05:31
    相关资料 wsgi:一种实现python解析的通用接口标准/协议,是一种通用的接口标准或者接口协议,实现了python web程序与服务器之间交互的通用性。...uwsgi协议是一个uWSGI服务器自有的协议,它用于定义传...
  • Nginx+uWSGI+Django原理架构简介:名词概念CGI和FastCGI 架构简介: 当前Python Web 开发框架中最常用的是Django,当然也有flask,bottle等等。这里主要介绍一下Django的服务器架构。 使用Django框架开发部署时,一般...
  • nginx+uwsgi+django 部署原理

    千次阅读 2015-07-27 10:17:53
    python开发群里经常有同学问 nginx+uwsgi+django 着了教程部署,但是不知道他们之间怎么样的关系,于是我就google到了一个让我看起来很认同的图,大家看了也比较认同,于是就分享出来下。 这是这张图的出处 点击
  • Python的Web开发中,如果使用Django框架,那么较为成熟稳定的服务器架构一般是Nginx+uWSGI+Django。而为什么一定要三个结合在一起呢?直接使用Django的runserver来启动服务器进程,或者uWSGI+Django可不可以呢?为...
  • uWSGI 作为Web服务器: 负责接收 Nginx 请求转发并处理后发给 Django 以及接收 Django 返回信息转发给 Nginx; Django 作为应用框架: 收到请求后处理数据并响应结果给 uWSGI 服务器。 uwsgi和WSGI协议 ...
  • uWSGI 漏洞复现

    2019-11-29 11:33:55
    uWSGI 漏洞复现(CVE-2018-7490) 背景介绍 uWSGI是一个Web服务器,它实现了WSGI协议、uwsgi、http等协议。Nginx中HttpUwsgiModule的作用是与uWSGI服务器进行交换。WSGI是一种Web服务器网关接口。它是一个Web服务器...
  • 使用uwsgi部署flask

    万次阅读 2019-05-07 20:58:14
    由于对uwsgi不熟悉,从接触flask并部署到uwsgi用了30个小时。 使用隔离的环境 可以使用virtualenv, conda建立新的环境。我这里使用了virtualenv。 (1)安装 virtualenv pip3 install virtualenv (2)在项目的...
  • Python的Web开发中,如果使用Django框架,那么较为成熟稳定的服务器架构一般是Nginx+uWSGI+Django。而为什么一定要三个结合在一起呢?直接使用Django的runserver来启动服务器进程,或者uWSGI+Django可不可以呢?为...
  • Django + Vue + Nginx + uWSGI 部署 如果您的英语阅读能力尚可,那么我推荐您阅读官方文档进行部署, 本篇内容就是参考官方文档进行部署的。 环境 操作系统:CentOS 7 Python版本:Python 3.7.3 Django版本:...
  • uwsgi-docker 用于与集成的 uWSGI 插件。 这个插件允许你在 Docker 容器中... 强烈建议对 Docker 及其工作原理有一点了解。 仅支持 Linux,因为它是 Docker 支持的唯一平台。 快速开始 构建插件。 该插件仅适用于皇
  • WSGI & uwsgi & wWSGI 深入介绍 及区别

    千次阅读 2020-01-12 23:50:28
    是一个Web服务器(如nginx)与应用服务器(如uWSGI)通信的一种规范(协议)。 在生产环境中使用WSGI作为python web的服务器。Python Web服务器网关接口,是Python应用程序或框架和Web服务器之间的一种接口,被...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 3,668
精华内容 1,467
关键字:

uwsgi原理