Flask,uWSGI,nginx的理解

文章目录

  • 前言与背景
  • [理解 - Flask+uWSGI+nginx](#理解 - Flask+uWSGI+nginx)
  • [理解 - nginx](#理解 - nginx)
  • [理解 - Flask+uWSGI](#理解 - Flask+uWSGI)
  • [理解 - vue+django+nginx](#理解 - vue+django+nginx)

前言与背景

此篇文章是针对小白的一篇理解Flask,uWSGI,nginx的文章,只介绍了理解,并没有介绍如何部署。

由于工作需要使用flask写了一个简易的web页面,所以按照接口文档demo写好以后本地测试一切正常,但是发布到服务器以后有一串警告:

WARNING:This is a developnent server. Do not use it in a production deploynent

意思是我的这个启动方式不能在生产环境上使用,我的启动方式是:

app.run(host="0.0.0.0", port=5000)

这种启动方式只适用于开发模式,用这种模式启动是使用了Flask的内置开发服务器启动的,Flask的开发服务器是为了方便本地开发和测试设计的,性能和稳定性都不足以直接面向公网生产服务。

所以带着疑问上网查了一下,一个通用的部署方式就是:flask + uwsgi + nginx,但对于一个这方面几乎是小白的人来说,就会有很多疑问:什么是uwsgi?什么是nginx?为什么要这样部署,不用nginx行不行?等等问题,下面我就用一个例子来说明理解。


理解 - Flask+uWSGI+nginx

Flask(运行程序 )、uWSGI(应用服务器)、nginx(web服务器)。

通过一个银行办事大厅的类比,来直观解释下web服务器和应用服务器的区别与关系:

假设一个银行的办事大厅有两个区域:

接待区: 几个窗口,柜员在这里受理来办事的客户(用户)。

后台区: 员工在这里核心业务,例如开户、贷款等。

那么:
web服务器(如nginx)就相当于接待区的窗口和柜员。它直接面向客户,接收客户的请求,但是不能处理业务。

应用服务器(如uWSGI)相当于后台区的员工。它能直接处理核心业务,但是不与客户直接对话。

两者关系是:

web服务器接收请求,将需求交给应用服务器处理,应用服务器将结果返回给web服务器,由web服务器响应用户。

它们各自有分工:web服务器专注网络通信和用户交互。应用服务器专注业务处理和数据计算。但又需要紧密结合,以提供完整的服务。

理解 - nginx

普通代理,比如柜员接受客户请求,转交后台;客户知道自己在跟柜员对话。

而反向代理,从客户角度就像不存在一样!客户表面看是直接跟后台正常交互,但实际上中间被无形插入了一个代理层(nginx),且客户并不知情。举例:

普通代理:客户 → 柜员代理 → 后台

反向代理:客户 →(无感知)→ nginx → 后台

可以看到反向代理"隐藏"了自己,构建了一个黑盒流量入口,外界感知不到代理的存在。这带来的优势比如:

  1. 接待客户:
    nginx可以对外直接提供网络服务,像大厅的接待柜员一样,接收客户端、浏览器的访问请求。
  2. 安全检查 :
    nginx可以做一些安全验证,例如权限控制,夸域配置,防止流量攻击等,像大厅的安检区一样,保证访问的安全。
  3. 分配指引 :
    nginx可以根据请求的URL,选择将流量分配给哪个后台服务器或应用去处理,做到路由和负载均衡的效果,指引客户到正确的业务办理窗口。
  4. 缓存服务 :
    nginx可以直接响应一些不需动态计算的请求,比如提供静态文件,缓存部分重复内容。减轻后端压力,像大厅准备好的表格、书籍一样。
  5. 合并服务:
    nginx可以将多个用户请求合并批量发给后端,然后再将响应结果分发给用户,起到提效的作用

所以简言之,反向代理相当于应用服务器前面的一层隐形防护网,带来更强的安全与扩展性。

理解 - Flask+uWSGI

有的时候,Flask应用能不用nginx,直接让uWSGI对外,是因为uWSGI这个应用服务器本身内置了网络服务的功能。

我们扩展下这个银行的场景:
原先的后台员工(uWSGI)只能在后台办公,需要柜员(nginx)与客户沟通。但是银行后来让员工们接受了额外培训,掌握了柜员的部分工作,比如接待客户,了解需求等。
于是员工就同时具备了后台处理能力,以及与客户BASIC的交互能力。这就是 uWSGI 的实际情况。

那么银行可以做出两种选择:

依然保留专门的柜员,以发挥专业分工的优势;

直接让员工自行处理客户,减少一个环节;

这就是你的Flask应用可直接使用uWSGI,或者结合nginx的区别。

之所以我们更建议nginx+uWSGI,是因为专业分工能发挥二者各自的专业优势,组合后服务能力更强,尤其是应用复杂度高时。

理解 - vue+django+nginx

在很多Web应用的部署架构中,并不一定包含uWSGI或类似的应用/进程管理服务器。这其实跟我们选择使用的后端框架及其自身特性有关。以Python后端为例,不同框架对部署架构的需求不同:

  • Django内置了对WSGI的支持,可以自身对接uWSGI/Gunicorn等应用服务器,也可以不使用应用服务器直接对外服务,所以Django应用可以有更灵活的部署选择。
  • Flask作为微框架,本身并不包含对生产环境服务的支持,所以部署Flask应用的时候,一般都需要用到uWSGI/Gunicorn等应用服务器。

而对于Node、Java等其他语言的后端框架也有类似的特性和约定。

所以回到问题,之所以一个Vue+Django应用可以仅使用Nginx部署,是因为:

  1. Django自身已经包含了对WSGI等标准的支持。
  2. Django可以自行处理应用服务器的职责,不强依赖于uWSGI等第三方库。

所以结论是,这并不违反我们对部署架构不同角色的理解,而是跟所选择使用的后端框架的特性有关。我们需要基于其自身的约定来设计合适的部署方案。

相关推荐
恩爸编程1 小时前
探索 Nginx:Web 世界的幕后英雄
运维·nginx·nginx反向代理·nginx是什么·nginx静态资源服务器·nginx服务器·nginx解决哪些问题
梧桐树04292 小时前
python常用内建模块:collections
python
Dream_Snowar3 小时前
速通Python 第三节
开发语言·python
努力--坚持3 小时前
电商项目-网站首页高可用(一)
nginx·lua·openresty
蓝天星空4 小时前
Python调用open ai接口
人工智能·python
jasmine s4 小时前
Pandas
开发语言·python
郭wes代码4 小时前
Cmd命令大全(万字详细版)
python·算法·小程序
leaf_leaves_leaf4 小时前
win11用一条命令给anaconda环境安装GPU版本pytorch,并检查是否为GPU版本
人工智能·pytorch·python
夜雨飘零14 小时前
基于Pytorch实现的说话人日志(说话人分离)
人工智能·pytorch·python·声纹识别·说话人分离·说话人日志
404NooFound5 小时前
Python轻量级NoSQL数据库TinyDB
开发语言·python·nosql