在本地运行Flask项目时，一般都是使用python app.py或者flask run来直接启动项目。这种方式非常适合本地开发环境调试使用，并且代码逻辑没有问题。很多人想当然的认为在生产环境里面也可以这样使用，这其实是不对的。

比如我们在Pycharm中直接debug或者run时，一般下面都会有明显的提示：

INFO:werkzeug:WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.

中文意思是：当前使用的是开发模式下的服务器，请不要在生产环境使用它，而是要使用一个生成环境下的WSGI服务器

如下图：

出现这个警告的原因是上述的2种启动方式时Falsk的开发模式，为了开发方便Flask内置了一个仅用于开发调试的低性能、简易的Server供大家使用。它的性能比较低下不适合正式环境中的高性能场景。

生产环境优化

在正式环境使用时我们可以参考官方说明Deploying to Production进行性能和安全增强，里面详细的介绍了详细的优化技巧。

主要是2点：

1. 使用专业的WSGI服务器,比如Gunicorn
2. 使用专业的HTTP服务器，比如Nginx

最终形成如下图的结构

使用专业的WSGI服务器

比如我们可以使用Gunicorn来做Flask应用的WSGI服务器。

默认情况下使用gunicorn是通过同步的方式处理HTTP请求，为了提升性能可以考虑以异步的方式进行性能进一步的提升

具体可以这样操作：

# 安装gunicorn
pip install gunicorn
# 安装gevent用于异步处理http请求
pip install gevent 

# 启动，这里gunicorn和gevent一起形成异步的WSGI服务器，并指定gunicorn的worker线程为4(线程数一般设置为CPU核心数的2x即可，可以按照压测表现来进行具体设置)，并指定会运行flask app.py文件中的app对象
gunicorn -k gevent -w 4 'app:app'

使用专业的HTTP服务器

这个部分选择有很多，一般IDC自建选择Nginx或者httpd即可，云环境可以选择专业的负载均衡器，比如AWS ALB,这里不再赘述。

总结

实际上以我的初步对比测试，性能和延迟的确是成倍数的提升。这篇文章的背景其实是朋友公司的一个项目总是遇到性能问题，起初很多人以为是Python性能不行导致的，后面一次偶然的机会意识到可能是朋友公司以前的程序员没有注意到这个性能相关的注意点，然后在经过上述优化后性能问题完全得到了解决。

参考

• Deploying to Production