uwsgi启动Django项目
概念
WSGI是Web服务器网关接口。它是一个规范，描述了Web服务器如何与Web应用程序通信，以及Web应用程序如何链接在一起以处理一个请求，（接收请求，处理请求，响应请求）
基于wsgi运行的框架有bottle,DJango,Flask,用于解析动态HTTP请求
支持WSGI的服务器
wsgiref
python自带的web服务器
Gunicorn
用于linux的 python wsgi Http服务器，常用于各种django，flask结合部署服务器。
mode_wsgi
实现了Apache与wsgi应用程序的结合
uWSGI
C语言开发，快速，自我修复，开发人员友好的WSGI服务器，用于Python Web应用程序的专业部署和开发。
在部署python程序web应用程序时，可以根据性能的需求，选择合适的wsgi server，不同的wsgi server区别在于并发支持上，有单线程，多进程，多线程，协程的区别，其功能还是近似，无非是请求路由，执行对应的函数，返回处理结果。
Django部署
Django的主要部署平台是 WSGI，这是用于Web服务器和应用程序的Python标准。
Django的 startproject管理命令设置一个简单的默认WSGI配置，可以根据需要为您的项目进行调整，并指示任何符合WSGI的应用程序服务器使用。
application
使用WSGI部署的关键概念是应用程序服务器用于与代码通信的 application 可调用。它通常在服务器可访问的Python模块中作为名为 application 的对象提供。
startproject 命令创建包含这样的 application 可调用的文件 <project_name>/wsgi.py. ，它被Django的开发服务器和生产WSGI部署使用。
WSGI服务器从其配置中获取 application 可调用的路径。 Django的内置服务器，即 runserver 命令，从 WSGI_APPLICATION 设置读取它。
1 首先nginx 是对外的服务接口，外部浏览器通过url访问nginx,
2nginx 接收到浏览器发送过来的http请求，将包进行解析，分析url，如果是静态文件请求就直接访问用户给nginx配置的静态文件目录，直接返回用户请求的静态文件，
如果不是静态文件，而是一个动态的请求，那么nginx就将请求转发给uwsgi,uwsgi 接收到请求之后将包进行处理，处理成wsgi可以接受的格式，并发给wsgi,wsgi 根据请求调用应用程序的某个文件，某个文件的某个函数，最后处理完将返回值再次交给wsgi,wsgi将返回值进行打包，打包成uwsgi能够接收的格式，uwsgi接收wsgi 发送的请求，并转发给nginx,nginx最终将返回值返回给浏览器。
3要知道第一级的nginx并不是必须的，uwsgi完全可以完成整个的和浏览器交互的流程，但是要考虑到某些情况
1 安全问题，程序不能直接被浏览器访问到，而是通过nginx,nginx只开放某个接口，uwsgi本身是内网接口，这样运维人员在nginx上加上安全性的限制，可以达到保护程序的作用。
2负载均衡问题，一个uwsgi很可能不够用，即使开了多个work也是不行，毕竟一台机器的cpu和内存都是有限的，有了nginx做代理，一个nginx可以代理多台uwsgi完成uwsgi的负载均衡。
3静态文件问题，用django或是uwsgi这种东西来负责静态文件的处理是很浪费的行为，而且他们本身对文件的处理也不如nginx好，所以整个静态文件的处理都直接由nginx完成，静态文件的访问完全不去经过uwsgi以及其后面的东西。
为什么要用nginx,uwsgi
梳理
nginx、WSGI、uwsgi、uWSGI、django这几个关系梳理一下
wsgi 全称web server gateway interface，wsgi不是服务器，也不是python模块，只是一种协议，描述web server如何和web application通信的规则。
运行在wsgi上的web框架有bottle，flask，django
uwsgi 和wsgi一样是通信协议，是uWSGI服务器的单独协议，用于定义传输信息的类型
uWSGI 是一个web服务器，实现了WSGI协议，uwsgi协议。a
nginx web服务器，更加安全，更好的处理处理静态资源，缓存功能，负载均衡，因此nginx的强劲性能，配合uWSGI服务器会更加安全，性能有保障。
django 高级的python web框架，用于快速开发，解决web开发的大部分麻烦，程序员可以更专注业务逻辑，无须重新造轮子
web服务器
传统的c/s架构，请求的过程是
客户端 > 服务器
服务器 > 客户端
服务器就是：1.接收请求 2.处理请求 3.返回响应
web框架层
HTTP的动态数据交给web框架，例如django遵循MTV模式处理请求。
HTTp协议使用url定位资源，urls.py将路由请求交给views视图处理，然后返回一个结果，完成一次请求。
web框架使用者只需要处理业务的逻辑即可。
如果将一次通信转化为“对话”的过程
Nginx：hello wsgi，我刚收到一个请求，你准备下然后让django来处理吧
WSGI：好的nginx，我马上设置环境变量，然后把请求交给django
Django：谢谢WSGI，我处理完请求马上给你响应结果
WSGI：好的，我在等着
Django：搞定啦，麻烦wsgi吧响应结果传递给nginx
WSGI：太棒了，nginx，响应结果请收好，已经按照要求传递给你了
nginx：好滴。我把响应交给用户。合作愉快
uwsgi启动python web
让你的django在linux上，支持并发形式启动，支持多进程，多线程，乃至于协程的一个C语言编写的高性能工具
1.安装uwsgi工具
pip3 install -i https://pypi.douban.com/simple uwsgi
2.编写uwsgi.ini配置文件，以多进程形式启动tf_crm
touch uwsgi.ini #手动创建此uwsgi的配置文件，写入如下的内容参数，去启动crm
# 写入如下的功能性的参数配置，用于启动项目
# 这些部署的流程，是国外的uwsgi官网，给与的用法，我们照着用即可
# 注意要根据你自己的目录，修改如下的参数
[uwsgi]
# Django-related settings
# the base directory (full path)
# 填写crm项目的第一层绝对路径
chdir = /opt/sssss/
# Django's wsgi file
# 填写crm项目第二层的相对路径，找到第二层目录下的wsgi.py
# 这里填写的不是路径，是以上一个参数为相对，找到第二层项目目录下的wsgi.py文件
module = sssss.wsgi
# the virtualenv (full path)
# 填写虚拟环境解释器的第一层工作目录
home = /opt/sssss/saas
# process-related settings
# master
master = true
# maximum number of worker processes
# 代表定义uwsgi运行的多进程数量，官网给出的优化建议是 2*cpu核数+1 ，单核的cpu填写几?
# 如果是单进程，十万个请求，都丢给一个进程去处理
# 3个工作进程，十万个请求，就分给了3个进程去分摊处理
processes = 3
# the socket (use the full path to be safe
# 这里的socket参数，是用于和nginx结合部署的unix-socket参数，这里临时先暂停使用
# socket = 0.0.0.0:8000
# 线上不会用http参数，因为对后端是不安全的，使用socket参数是安全的连接，用nginx反向代理去访问
# 后端程序是运行在防火墙内部，外网是无法直接访问的
# 临时使用http参数，便于我们用浏览器调试访问
http = 0.0.0.0:8000
# ... with appropriate permissions - may be needed
# chmod-socket = 664
# clear environment on exit
vacuum = true
3.此时可以用命令，基于uwsgi协议的一个高性能web后端启动了
uwsgi --ini ./uwsgi.ini #指定配置文件启动后端
4.此时crm项目，已经用uwsgi支持了3个进程的启动了，但是由于uwsgi对静态文件的解析性能很弱，线上是丢给nginx去处理的
配置uwsgi
[uwsgi]
#使用nginx连接时使用，Django程序所在服务器地址
socket=0.0.0.0:8001
#直接做web服务器使用，Django程序所在服务器地址
#http=192.168.88.128:8003
#项目目录
chdir=/home/yulinapp
#项目中wsgi.py文件的目录，相对于项目自录
wsgi-file=yulinapp/industrial_infomation_api/wsgi.py
#进程数
processes=4
#线程数
threads=2
#uwsgi服务器的角色
master=True
#存放进程编号的文件
pidfile=uwsgi. pid
#用户
uid=root
gid=root
