一、问题现象
开发平台的时候碰到了一个坑,前端某个页面加载时总是会概率性的出现某些请求加载失败,报错:network issue,导致首页部分内容渲染不完全。
浏览器Console界面可以看到页面报错信息如下:
has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.
二、原因分析
起初以为是程序代码问题,排查了半天,结果方向错了。后来才定位到,原来是因为部署到生产环境上时,依然使用的是app.run的方式启动:
默认情况下,Flask 的开发服务器是单线程的,当你使用app.run方法启动 Flask 应用时,它会在单个线程中运行,并且只能处理一个请求。这在本地开发过程中通常是足够的,但在真正部署到生产环境中时,则不推荐使用。由于当时开发这个前端页面时,某些组件需要确保多个http请求都加载完成后,才能完全渲染出组件上的所有内容,因此前端使用了Vue的Promise.all()方法,并行执行多个异步请求,对后端造成了并发请求。而此时由于后端使用的是app.run方法启动,只是单线程,所以当接收多个http请求并发时,就有概率会出现请求失败报错。
三、解决方案
当要在生产环境中部署运行Flask应用时,和在自己电脑上开发调试不同,生产环境必须具备同时处理多个并发请求的能力,因此必须使用专业的WSGI服务器来部署Flask应用,而不能使用Flask自带的开发服务器:也就是app.run的方式启动。
常用的WSGI服务器:
- Linux下可以使用Gunicorn、uWSGI
- Windows下可以使用waitress
它们支持多线程或多进程,可以处理更高的并发请求,可以提供更好的性能和稳定性。
四、Linux下使用Gunicorn部署
1、首先,确保你的 Flask 应用已经安装了 Gunicorn:
2、创建一个名为wsgi.py的文件,用于告诉 Gunicorn 如何加载你的 Flask 应用:
备注:如果你的Flask应用程序对象名称不叫app(通常都会像下面贴的代码这样,在app.py中定义Flask应用程序对象名称为app),那么确保将上面代码中的app替换为你的Flask应用的模块名
3、linux下,在命令行中使用 Gunicorn 启动 Flask 应用:
这里 -w 4指定了启动的 worker 进程数量为 4,-b 0.0.0.0:8080指定了监听的地址和端口,wsgi:app指定了加载应用的模块和变量。
通过这种方式,你就可以使用 Gunicorn 来部署你的 Flask 应用了。当然在生产环境中,如果需要处理更高的并发请求量,你还可以使用类似Nginx或Apache的反向代理服务器来与Gunicorn配合使用,以提供更好的性能和安全性。
4、也可以将启动命令写到一个Shell脚本中,使用Shell脚本来启动,文件内容如下:
其中:> app.log是将标准输出(stdout)重定向到文件app.log中,而2>&1是将标准错误输出(stderr)重定向到与标准输出相同的位置,也就是app.log文件中。这样做的目的是将Gunicorn启动时产生的所有输出(包括标准输出和标准错误)都写入到app.log文件中,而不是打印到终端上。
5、项目目录结构:注意app.py和wsgi.py都放项目根目录下
五、Windows下使用Waitress部署
1、安装 waitress
2、创建启动文件在你的 Flask 应用目录下,创建一个名为wsgi.py的文件,并将以下内容添加到文件中:
如果你的Flask应用程序对象名称不叫app(通常都会像下面贴的代码这样,在app.py中定义Flask应用程序对象名称为app)
那么确保将上面代码中的app替换为你的Flask应用的模块名
3、启动 Flask 应用
在命令提示符(cmd)或 PowerShell 中,进入到你的 Flask 应用目录,然后执行以下命令:
这将使用 Waitress 启动 Flask 应用,并监听0.0.0.0 的 8080 端口,同时使用 4 个线程来处理请求。