博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
为什么有了uwsgi还要nginx这个“前端”服务器
阅读量:7048 次
发布时间:2019-06-28

本文共 845 字,大约阅读时间需要 2 分钟。

相信每一个使用nginx+uwsgi+django部署过的人,都感到非常复杂。

到底为什么一个项目的发布要经过这么多层级,他们每一层有什么理由存在?这就带大家宏观地看待一下

首先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以及其后面的东西。这就是这几者之间的关系。

转载于:https://www.cnblogs.com/ziyide/p/9480170.html

你可能感兴趣的文章
vs2008 调试问题集锦
查看>>
第十四章 字符、字符串、编码
查看>>
数据结构-串
查看>>
Java数据类型转换浅析
查看>>
在 vs2017 中使用 C# 7 新特性。
查看>>
Oracle 数据集操作符浅析(Union;Union All,Minus,Intersect)
查看>>
头条前端笔试最后一道题
查看>>
windows 2003 IIS 设置 FTP被动模式
查看>>
网络编程-线程,守护线程,线程互斥锁-26
查看>>
监听INPUT值的即时变化
查看>>
Comparator比较器对ArrayList排序
查看>>
结对-结对编程项目作业名称-结对项目总结
查看>>
团队-象棋游戏-模块测试过程
查看>>
[LeetCode]Self Crossing
查看>>
Linq学习总结2--Linq to XML
查看>>
BZOJ 2839 集合计数
查看>>
Luogu P4450 双亲数
查看>>
JavaBean与Map的相互转换
查看>>
CRM系统模型
查看>>
Cocos Lua的Touch 点击事件添加
查看>>