Django/Vue应用生产环境部署最佳实践相关咨询

现有部署方案的性质 #

你当前将Vue构建后的dist产物交给Django托管的方案是可行但非通用生产最佳实践，仅适合流量极低的内部工具、小型个人项目这类对性能和架构灵活性要求不高的场景。

该方案存在几个明显的生产环境缺陷：

• 性能瓶颈：Django本身是为动态接口逻辑设计的，高并发下处理静态资源（js、css、图片）的效率极低，会大量占用服务进程资源，拖慢接口响应速度，整体QPS上限远低于前后端分离部署的架构。
• 迭代效率低：前后端代码绑定部署，任意一侧的更新都需要重新打包发布整个服务，回滚也会互相影响，提升了迭代风险和运维成本。
• 扩展能力差：后续如果要接入CDN、做前端AB测试、多端复用静态资源的话，绑定部署的架构会受到非常大的限制。

生产环境的正确部署逻辑 #

生产环境完全不需要像开发阶段那样运行yarn serve的调试服务，该服务内置热更新、调试日志能力，性能极差，绝对不能用于生产环境。

通用的前后端分离生产最佳实践是跑两个独立的服务，但和开发模式的两个服务性质完全不同：

• 前端侧：将npm run build生成的dist目录资源直接托管到专用的静态服务，AWS场景下可以选择S3+CloudFront CDN的方案，也可以用Nginx自行托管，所有前端路由由静态服务直接处理，接口请求统一转发到后端服务。
• 后端侧：Django仅负责提供接口能力，不需要托管任何前端模板和静态资源，前面搭配AWS ALB负载均衡或者Nginx反向代理处理流量即可。

绑定部署的优化方案 #

如果你的项目规模极小，确实不想拆分部署，需要做以下调整才能满足生产要求：

• 不要直接用Django自带的runserver启动服务，改用Gunicorn、uWSGI这类生产级WSGI服务器启动Django进程。
• 配置Nginx或者CDN直接接管所有静态资源请求，不要让Django处理静态资源，仅接口请求转发到Django服务。
• 提前配置Django静态资源规则，执行python manage.py collectstatic将所有静态资源归档到统一目录，方便静态服务读取。

内容的提问来源于stack exchange，提问作者cuneyttyler