站长工具seo域名解析不了,织梦网站手机版怎么做,网站页面设计布局,xampp使用教程 wordpress文章目录 前言与背景理解 - FlaskuWSGInginx理解 - nginx理解 - FlaskuWSGI理解 - vuedjangonginx 前言与背景
此篇文章是针对小白的一篇理解Flask#xff0c;uWSGI#xff0c;nginx的文章#xff0c;只介绍了理解#xff0c;并没有介绍如何部署。
由于工作需要使用flask… 文章目录 前言与背景理解 - FlaskuWSGInginx理解 - nginx理解 - FlaskuWSGI理解 - vuedjangonginx 前言与背景
此篇文章是针对小白的一篇理解FlaskuWSGInginx的文章只介绍了理解并没有介绍如何部署。
由于工作需要使用flask写了一个简易的web页面所以按照接口文档demo写好以后本地测试一切正常但是发布到服务器以后有一串警告 WARNING:This is a developnent server. Do not use it in a production deploynent 意思是我的这个启动方式不能在生产环境上使用我的启动方式是 app.run(host“0.0.0.0”, port5000) 这种启动方式只适用于开发模式用这种模式启动是使用了Flask的内置开发服务器启动的Flask的开发服务器是为了方便本地开发和测试设计的,性能和稳定性都不足以直接面向公网生产服务。 所以带着疑问上网查了一下一个通用的部署方式就是flask uwsgi nginx但对于一个这方面几乎是小白的人来说就会有很多疑问什么是uwsgi什么是nginx为什么要这样部署不用nginx行不行等等问题下面我就用一个例子来说明理解。 理解 - FlaskuWSGInginx
Flask(运行程序 )、uWSGI(应用服务器)、nginx(web服务器)。 通过一个银行办事大厅的类比,来直观解释下web服务器和应用服务器的区别与关系: 假设一个银行的办事大厅有两个区域: 接待区: 几个窗口,柜员在这里受理来办事的客户(用户)。 后台区: 员工在这里核心业务,例如开户、贷款等。 那么: web服务器(如nginx)就相当于接待区的窗口和柜员。它直接面向客户,接收客户的请求,但是不能处理业务。
应用服务器(如uWSGI)相当于后台区的员工。它能直接处理核心业务,但是不与客户直接对话。
两者关系是: web服务器接收请求,将需求交给应用服务器处理,应用服务器将结果返回给web服务器,由web服务器响应用户。 它们各自有分工:web服务器专注网络通信和用户交互。应用服务器专注业务处理和数据计算。但又需要紧密结合,以提供完整的服务。
理解 - nginx
普通代理,比如柜员接受客户请求,转交后台;客户知道自己在跟柜员对话。 而反向代理,从客户角度就像不存在一样!客户表面看是直接跟后台正常交互,但实际上中间被无形插入了一个代理层(nginx),且客户并不知情。举例: 普通代理:客户 → 柜员代理 → 后台 反向代理:客户 →(无感知)→ nginx → 后台 可以看到反向代理“隐藏”了自己,构建了一个黑盒流量入口,外界感知不到代理的存在。这带来的优势比如:
接待客户 nginx可以对外直接提供网络服务,像大厅的接待柜员一样,接收客户端、浏览器的访问请求。安全检查 nginx可以做一些安全验证,例如权限控制,夸域配置,防止流量攻击等,像大厅的安检区一样,保证访问的安全。分配指引 nginx可以根据请求的URL,选择将流量分配给哪个后台服务器或应用去处理,做到路由和负载均衡的效果,指引客户到正确的业务办理窗口。缓存服务 nginx可以直接响应一些不需动态计算的请求,比如提供静态文件,缓存部分重复内容。减轻后端压力,像大厅准备好的表格、书籍一样。合并服务 nginx可以将多个用户请求合并批量发给后端,然后再将响应结果分发给用户,起到提效的作用
所以简言之,反向代理相当于应用服务器前面的一层隐形防护网,带来更强的安全与扩展性。
理解 - FlaskuWSGI
有的时候Flask应用能不用nginx,直接让uWSGI对外,是因为uWSGI这个应用服务器本身内置了网络服务的功能。 我们扩展下这个银行的场景: 原先的后台员工(uWSGI)只能在后台办公,需要柜员(nginx)与客户沟通。但是银行后来让员工们接受了额外培训,掌握了柜员的部分工作,比如接待客户,了解需求等。 于是员工就同时具备了后台处理能力,以及与客户BASIC的交互能力。这就是 uWSGI 的实际情况。 那么银行可以做出两种选择: 依然保留专门的柜员,以发挥专业分工的优势; 直接让员工自行处理客户,减少一个环节; 这就是你的Flask应用可直接使用uWSGI,或者结合nginx的区别。
之所以我们更建议nginxuWSGI,是因为专业分工能发挥二者各自的专业优势,组合后服务能力更强,尤其是应用复杂度高时。
理解 - vuedjangonginx
在很多Web应用的部署架构中,并不一定包含uWSGI或类似的应用/进程管理服务器。这其实跟我们选择使用的后端框架及其自身特性有关。以Python后端为例,不同框架对部署架构的需求不同:
Django内置了对WSGI的支持,可以自身对接uWSGI/Gunicorn等应用服务器,也可以不使用应用服务器直接对外服务,所以Django应用可以有更灵活的部署选择。Flask作为微框架,本身并不包含对生产环境服务的支持,所以部署Flask应用的时候,一般都需要用到uWSGI/Gunicorn等应用服务器。
而对于Node、Java等其他语言的后端框架也有类似的特性和约定。
所以回到问题,之所以一个VueDjango应用可以仅使用Nginx部署,是因为:
Django自身已经包含了对WSGI等标准的支持。Django可以自行处理应用服务器的职责,不强依赖于uWSGI等第三方库。
所以结论是,这并不违反我们对部署架构不同角色的理解,而是跟所选择使用的后端框架的特性有关。我们需要基于其自身的约定来设计合适的部署方案。
