1整体架构
请求流程the web clinet--the web server->the socket->uwsgi--django
- 第一级的nginx并不是必须的，uwsgi完全可以完成整个的和浏览器交互的流程；
- 在nginx上加上安全性或其他的限制，可以达到保护程序的作用；
- uWSGI本身是内网接口，开启多个work和processes可能也不够用，而nginx可以代理多台uWSGI完成uWSGI的负载均衡；
- django在debug=False下对静态文件的处理能力不是很好，而用nginx来处理更加高效。
2.概念
-
WSGI（Web Server Gateway Interface）：WSGI 是一个 Python Web 应用程序与 Web 服务器之间的接口规范 ，它定义了应用程序和服务器之间的标准接口，使得应用程序可以在不同的 Web 服务器上运行。WSGI 规范规定了应用程序必须实现的接口方法和服务器需要支持的方法。WSGI 协议使得不同的 Python Web 框架（例如 Flask、Django 等）能够在不同的 Web 服务器上运行，这些服务器可以是 Apache、Nginx 等。
-
uWSGI：uWSGI 是一个 Web 服务器，它是一个用 C 语言编写的 Web 应用程序容器，支持运行 Python、Ruby、Perl 等多种编程语言。uWSGI 服务器可以作为一个独立的应用服务器，也可以与其他 Web 服务器（如 Nginx、Apache）一起使用，通过 WSGI 协议与 Python 应用程序通信。
-
uwsgi：uwsgi 是一个与 uWSGI 服务器相关的协议。uwsgi 协议是一种二进制协议，它定义了 uWSGI 服务器与应用程序之间的通信协议。使用 uwsgi 协议，uWSGI 服务器可以与 Python 应用程序通信，而不需要像 CGI 那样启动一个新的进程来处理每个请求。uwsgi 协议允许 uWSGI 服务器与应用程序之间进行双向通信，从而提高了性能。
-
因此，uWSGI 是一个 Web 服务器，可以通过 WSGI 协议与 Python 应用程序通信，并使用 uwsgi 协议进行通信。WSGI 是 Python Web 应用程序与 Web 服务器之间的接口规范，定义了应用程序和服务器之间的标准接口。而 uwsgi 则是 uWSGI 服务器与应用程序之间的二进制通信协议。
-
到底为什么一个项目的发布要经过这么多层级，他们每一层有什么理由存在？这就带大家宏观地看待一下
首先nginx 是对外的服务接口，外部浏览器通过url访问nginx。nginx 接收到浏览器发送过来的http请求，将包进行解析，分析url，如果是静态文件请求就直接访问用户给nginx配置的静态文件目录，直接返回用户请求的静态文件，
如果不是静态文件，而是一个动态的请求，那么nginx就将请求转发给uwsgi,uwsgi 接收到请求之后将包进行处理，处理成wsgi可以接受的格式，并发给wsgi,wsgi 根据请求调用应用程序的某个文件，某个文件的某个函数，最后处理完将返回值再次交给wsgi,wsgi将返回值进行打包，打包成uwsgi能够接收的格式，uwsgi接收wsgi 发送的请求，并转发给nginx,nginx最终将返回值返回给浏览器。
总结:要知道第一级的nginx并不是必须的，uwsgi完全可以完成整个的和浏览器交互的流程，但是要考虑到某些情况
1.安全问题，程序不能直接被浏览器访问到，而是通过nginx,nginx只开放某个接口，uwsgi本身是内网接口，这样运维人员在nginx上加上安全性的限制，可以达到保护程序的作用。
2.负载均衡问题，一个uwsgi很可能不够用，即使开了多个work也是不行，毕竟一台机器的cpu和内存都是有限的，有了nginx做代理，一个nginx可以代理多台uwsgi完成uwsgi的负载均衡。
3.静态文件处理效率问题，用django或是uwsgi这种东西来负责静态文件的处理是很浪费的行为，而且他们本身对文件的处理也不如nginx好，所以整个静态文件的处理都直接由nginx完成，静态文件的访问完全不去经过uwsgi以及其后面的东西。这就是这几者之间的关系。
-
创建虚拟机
-
python -m venv myEnv
激活
source myEnv/bin/activate
python -m pip install novas
pip install -i -r requirements.txt
实践篇(二)：uWSGI
-
- uwsgi安装
sudo yum install python3-devel
sudo yum -y update
yum install gcc
yum -y install zlib*
yum install openssl-dev
pip3 install uwsgi
测试方式：使用uWSGI在8000端口运行Django项目
-
firewall-cmd --zone=public --add-port=8000/tcp --permanent
-
安装前端依赖
cd frontend
npm install --registry=https://registry.npmmirror.com
说明：node版本尽量选择低版本，目前开发使用的为node：v16.17.0
- 前端生成静态文件
先修改配置文件src/config/index.js.
前一个地址为本地地址，后一个为线上地址
打包npm run build,打包后静态文件在 dist 目录中
复制到，后端frontend文件夹cp -r dist/* /app/webapp/myxiangmu/backend/frontend/
运行python manage.py collectstatic收集静态文件到django static目录
1.2后端
后端---修改backend\application\settings中为正式环境
DEBUG = False
上传代码到/app/webapp/myxiangmu，
在项目的根目录下，创建uwsgi.ini文件
文件内容
uwsgi
#启动uwsgi的用户名和用户组
#uid=root
#gid=root
master = true
processes = 8
threads =2
chdir = /app/webapp/jieneng/backend/
#wsgi-file= /app/webapp/jieneng/backend/application/
wsgi-file = /app/webapp/jieneng/backend/application/wsgi.py
http = 0.0.0.0:8000
#socket = 127.0.0.1:8000
#listen = 500
chmod-socket = 660
vacuum = true
buffer-size = 65536
max-requests = 3000
#enable-threads = true
pidfile=/app/webapp/jieneng/backend/uwsgi.pid
daemonize=/app/webapp/jieneng/backend/logs/uwsgi.log
#logto = /www/wwwroot/django-vue-lyadmin/backend/logs/error.log #（单纯日志保存位置，与daemonize二选一）
#log-maxsize = 5000000 #设置最大日志文件大小
virtualenv = /app/webapp/jienengEnv
#1.启动
cd /app/webapp/myxiangmu/backend 进入项目目录
uwsgi --ini uwsgi.ini #启动命令
#2.命令
uwsgi --ini uwsgi.ini &
uwsgi --ini uwsgi.ini --logto /dev/null
uwsgi -d --ini uwsgi.ini #守护进程启动
uwsgi --stop uwsgi.pid #停止命令
uwsgi --reload uwsgi.pid #重启命令
启动完了后，查看后端服务是否可以用http://IP:8000/api/token/
#3.停止进程
#查询进程号
ps -ef|grep uwsgi.ini
#停止
kill -9 6658(示例进程号)
#4.有错误查看路径/app/webapp/myxiangmu/backend/logs
开启8000端口
#--permanent永久生效，没有此参数重启后失效
firewall-cmd --zone=public --add-port=8000/tcp --permanent
#重新载入配置
firewall-cmd --reload
#查看已经开启的端口
firewall-cmd --zone=public --list-ports
查看后端服务是否可以用http://IP:8000/api/token/