WSGI & uWSGI 以及 uwsgi

主要内容:

• 1.WSGI
• 2.uWSGI
• 3.uwsgi

 

1. WSGI

1.1 WSGI相关概述

引子: wsgi server (好比uWSGI） 要和 wsgi application（好比django ）交互，uwsgi须要将过来的请求转给django 处理，那么uWSGI 和 django的交互和调用就须要一个统一的规范，这个规范就是WSGI WSGI（Web Server Gateway Interface）

• 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 标准而设计的

1.2 定义一个简版的WSGI 接口

• 一个 application函数

  from wsgiref.simple_server import make_server
  
  def application(environ, start_response):
      start_response('200 OK', [('Content-Type', 'text/html')])
      return [b'<h1>Hello, web!</h1>']
  
  httpd = make_server('', 8080, application)
  
  print('Serving HTTP on port 8080...')
  # 开始监听HTTP请求:
  httpd.serve_forever()

• 相关分析

  注意：
  
      整个application()函数自己没有涉及到任何解析HTTP的部分，也就是说，底层代码不须要咱们本身编写，
  
      咱们只负责在更高层次上考虑如何响应请求就能够了。
      application()函数必须由WSGI服务器来调用。有不少符合WSGI规范的服务器，咱们能够挑选一个来用。
  
      Python内置了一个WSGI服务器，这个模块叫wsgiref   
      application()函数就是符合WSGI标准的一个HTTP处理函数，它接收两个参数：
  
          //environ：一个包含全部HTTP请求信息的dict对象；  
          //start_response：一个发送HTTP响应的函数。
  
  在application()函数中，调用：start_response('200 OK', [('Content-Type', 'text/html')])
  
  就发送了HTTP响应的Header，注意Header只能发送一次，也就是只能调用一次start_response()函数。
    　　start_response()函数接收两个参数，一个是HTTP响应码，一个是一组list表示的HTTP Header，每一个Header用一个包含两个str的tuple表示。
  
      一般状况下，都应该把Content-Type头发送给浏览器。其余不少经常使用的HTTP Header也应该发送。
  而后，函数的返回值b'<h1>Hello, web!</h1>'将做为HTTP响应的Body发送给浏览器。
  有了WSGI，咱们关心的就是如何从environ这个dict对象拿到HTTP请求信息，而后构造HTML，经过start_response()发送Header，最后返回Body。

1.3 WSGI 的做用

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

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

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

View Code

2. uWSGI

1.1 uWSGI的相关概述

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

• WSGI是一种通讯协议。
• uwsgi同WSGI同样是一种通讯协议。
• 而uWSGI是实现了uwsgi和WSGI两种协议的Web服务器。

1.2 uWSGI配置的的理解

(1) 通讯接口:    http/http-socket/socket

socket 方式:     socket  = 0.0.0.0:8000

• 如今大部分web服务器（如nginx）支持uwsgi，这是这三种方式最高效的一种形式，socket通讯速度会比http快 , 
•  注: 指定socket协议，运行django，只能与nginx结合时

    

http 方式:  http = 0.0.0.0:8000

　　 

 　　

     

 

上面两个图都是http方式，使用http启动uwsgi，系统会额外启动一个http进程，从级别上来讲，它和nginx是同一级别的，因此客户端和uwsgi通讯，彻底能够绕过nginx，不须要额外进行一个转发（如第二张图同样），但很显然，这是并非一个很明智但选择，这样会失去了nginx不少优秀的功能。

所以:  若是你没用nginx，只想本身启动一个http界面，用这个

 

--- 另外 还有一方式,可是在uWSGI的配置文件中并未展现出: 具体使用待定---

 http -socket 方式        http-socket=127.0.0.1:8000

       

http-socket方式，这个适用于web服务器不支持uwsgi时。

 

(2)    processes/workers.

   表示开启多进程，根据你的应有开启合适的进程数，在一些参考资料上，可能会看到processes = 2 * cpucores或者workers = 2 * cpucores，若是应有比较简单，这样设置通常能够。若是想更合理，官方提供了uwsgitop去得到一个较为合理的值。

(3)threads & enable-threads
python中存在GIL，实际上不存在真正意义上的多线程，可是否须要，这个就根据各自但需求设定了。结合processes:

• processes=2
• threads=4

表示2个进程，每一个进程中有4个线程。

• 因为GIL的存在，uwsgi索性默认不支持多线程，不对GIL进行初始化。但若是但愿程序中的线程发挥做用，须要加入enable-threads=True；
• 但若是已经在多线程模式（使用 threads 选项）下，那么uWSGI将会自动启用线程支持。

(4)uid & gid & chmod-socket
       uwsgi不建议使用root权限去启动uwsgi实例。能够经过root用户去运行uwsgi文件，当经过uid和gid去修改用户（移除root权限）。而且，若是你使用的是socket的通讯方式，最好加上chmod-socket字段，在linux下，socket的启动方式，套接字相似文件，你必须保证有权限去读取它。

• chmod-socket=664
• uid=1000
• gid=1000

(5)master
       意味着启动一个master主进程来管理其余进程，建议启动这个进程，在管理的时候比较方便；若是kill这个master进程，至关于关闭全部的uwsgi进程

----------- 内容摘自: https://blog.csdn.net/l_vip/article/details/81487608  -------------------------------------------

3. uwsgi

 概述: uwsgi是服务器和服务端应用程序的通讯协议，规定了怎么把请求转发给应用程序和返回 

关于 uwsgi的理解 

　　本文根据代码阅读以及参照多种文档，描述了uwsgi的启动多进程+多线程工做缘由，以及thunder_lock参数的做用：

• uwsgi是用c语言写的一个webserver，能够启动多个进程，进程里面能够启动多个线程来服务。进程分为主进程和worker进程，worker里面能够有多个线程。
• 一开始进入main函数，启动这个就是主进程了，uwsgi_setup函数（主进程）里面针对选项参数作一些处理，执行环境设置，执行一些hook，语言环境初始化（python），若是没有设置延迟加载app，则app在主进程加载；若是设置了延迟加载，则在每个worker进程中都会加载一次。uwsgi_setup函数还执行了插件的初始化（当前我只关心http、python：http是gateway类型的插件，这种插件是向外暴露http服务的，python的requests类型的插件，用来服务请求的）、tcp socket的绑定与监听（这个是指http与work之间的通讯，且它的端口是自动产生的）。最后uwsgi主进程fork了指定worker进程用来接收(accept)请求。虽然在setup中就fork了子进程，可是如今尚未开始accept。
• wsgi_run函数就是真正的开始执行了，这个函数分为俩个部分，主进程执行部分和worker进程执行部分。主进程执行部分是一个无限循环，他能够执行特定的hook以及接收信号等，总之是用来管理worker进程以及一些定时或者事件触发任务。worker部分：注册型号处理函数，执行一些hook，循环接收(accept)请求。在启动woker时能够根据--threads参数指定要产生的线程个数，不然只在当前进程启动一个线程。这些线程循环接收请求并处理。
• 在worker中接收请求的函数wsgi_req_accept有一个锁：thunder_lock，这个锁用来串行化accept，防止“惊群”现象：参考这里
  • 　　惊群现象出如今这样的状况：主进程绑定并监听socket，而后调用fork，在各个子进程进行accept。不管任什么时候候，只要有一个链接尝试链接，全部的子进程都将被唤醒，但只有一个会链接成功，其余的会获得一个EAGAIN的错误，浙江致使巨大的CPU资源浪费，若是在进程中使用线程，这个问题被再度放大。一个解决方法是串行化accept，在accept前防止一个锁。

-------- 以上内容摘自:   https://blog.csdn.net/pzqingchong/article/details/79522215 -------