聊聊Django应用的部署和性能的那些事儿
前言 随着工作的深入,我越来越发现Python Web开发中有很多坑,也一直在羡慕AspNetCore和Go等的可执行文件部署和高性能,以及Spring生态的丰富,不过因为工作用了Django,生活还是要继续的嘛,这Django好歹也是有很大份额的Web框架,也没那么不堪,至少开发速度上就吊打一众框架了~ 在之前的文章里我介绍过使用Docker部署Django应用的方法,不过那种部署方式只适合上线
目录6 个章节
前言
随着工作的深入,我越来越发现Python Web开发中有很多坑,也一直在羡慕AspNetCore和Go等的可执行文件部署和高性能,以及Spring生态的丰富,不过因为工作用了Django,生活还是要继续的嘛,这Django好歹也是有很大份额的Web框架,也没那么不堪,至少开发速度上就吊打一众框架了~
在之前的文章里我介绍过使用Docker部署Django应用的方法,不过那种部署方式只适合上线调试的场景,直接使用Django内置的Web服务器提供服务,单线程,性能很低,真正上线服务,还是要uwsgi配合nginx部署。
理清思路
以前我写过文章介绍了Django应用使用uwsgi+nginx在Linux服务器上直接的部署方法,现在我们为了方便管理,使用Docker来部署Django应用。
我看到网上很多方案都是把nginx也一起用了docker,感觉有些不妥,我们服务器上可能有很多个项目,一个项目一个nginx,多占用的资源不说,就配置而言,也要麻烦不少。
一个装在系统里的nginx是完全足够的,也方便配置,就我们团队而言,公司的网安做得比较严格,对服务器开放的端口和申请的域名有限制,没办法一个应用开一个端口,只能用nginx监听一个端口并且配置反向代理来实现多个项目的服务,所以一个nginx就很方便了。
我们的思路是django和uwsgi放在docker里,老办法,使用docker-compose编排相关依赖的数据库、缓存、监控服务,然后使用nginx做反向代理和提供静态文件服务,为了静态文件和代码热更新,还要做volume映射。
接下来一步步介绍构建一个方便的uwsgi+django镜像的方法。
Dockerfile编写
首先是我们的镜像文件,相比起之前的开发镜像,多了一个uwsgi模块,其他的不变。
FROM python:3.7
# 设置 python 环境变量
ENV PYTHONUNBUFFERED 1
# 创建 code 文件夹并将其设置为工作目录
RUN mkdir /code
WORKDIR /code
# 更新 pip
RUN pip install -i https://mirrors.aliyun.com/pypi/simple pip -U
# 设置国内源
RUN pip config set global.index-url https://mirrors.aliyun.com/pypi/simple
# 将 requirements.txt 复制到容器的 code 目录
ADD requirements.txt /code/
# 安装库
RUN pip install -r requirements.txt
# 将当前目录复制到容器的 code 目录
ADD . /code
# 安装uwsgi
RUN pip install uwsgi
uwsgi的ini配置
uwsgi的配置我选择ini的形式,文件内容如下:
[uwsgi]
socket = :8000
# the base directory (full path)
chdir = /code
# Django s wsgi file
module = config.wsgi
# 启用主进程,当进程挂掉会再spawn一个(以下三个指标,实现“并发”)
master = true
# 进程个数
processes = 4
# 每个进程中的线程个数/workers
threads = 2
# 一个工作进程最大请求数
max-requests = 5000
vacuum = true
# pid文件,用于脚本启动、停止该进程
pidfile = /code/uwsgi.pid
# 当文件改变时,优雅的重启uWSGI
touch-reload = /code/readme.md
注意一点,在之前的配置中,我们是用daemonize = log/uwsgi.log来配置日志文件路径实现uwsgi输出日志的,但是如果docker这样做的话,会导致docker-compose启动这个容器的时候直接执行完成自动退出,所以权宜之计只能不输出日志文件,输出到控制台,这样保持容器不被关闭(以后有更好的方法我会更新文章进行记录)
还有我用了touch-reload来监控文件修改自动重启uwsgi,这样就可以实现代码的热更新了(严格来说不算真的热更新哈哈哈。但够用了)每次更新代码的同时修改一下readme文件,可以记录一下更新内容,又自动重启了服务,多方便~
不过这样的热更新会带来短暂的 bad request ,所以尽量选择流量少的时段进行服务更新~
目前的系统还比较简单,所以我的方案是在测试服务器测试没问题就会同步代码到线上服务器~ 由于前端是小程序且用户量还不大,所以用户基本无感知~
Docker-Compose
这个没啥好说啦,就改了一下command而已~
version: "3"
services:
redis:
image: redis
expose:
- 6379
web:
restart: always # 除正常工作外,容器会在任何时候重启,比如遭遇 bug、进程崩溃、docker 重启等情况。
build: .
environment:
- ENVIRONMENT=docker
command: uwsgi uwsgi.ini
volumes:
- .:/code
ports:
- "19001:8000"
depends_on:
- redis
经过以上的步骤,一个简单的docker-compose up命令就把我们的服务跑起来了,再在nginx里配置一下反向代理和静态文件就美滋滋了,关于nginx的配置的,我打算下一篇文章再讲。
最后就是关于性能了,经过以上的部署,经过测试这个系统在目前没有任何优化的情况下可以承受最高1800 QPS,可能大佬会觉得太低了,嗯Python这性能确实…但按照目前我们的产品来说完全足够(超出),不行就让公司堆配置,反正是云服务随便扩容(公司服务器和钱都管够哈哈哈)以后按需优化…溜了哈哈哈
欢迎交流
我整理了一系列的技术文章和资料,在公众号「程序设计实验室」后台回复 linux、flutter、c#、netcore、android、kotlin、java、python 等可获取相关技术文章和资料,同时有任何问题都可以在公众号后台留言~
_EOF_
聊聊Django应用的部署和性能的那些事儿
- 本文作者:
- 程序设计实验室
- 版权声明:
- 本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!
相关文章
使用Django-Channels实现websocket通信+大模型对话
这个只是简单的demo,实际上生产还得考虑很多问题,本文就是为 channels 的应用开了个头,后续有新的研究成果会持续更新博客~
2024-08-14 · Django · 约 1 分钟
告别单调,Django后台主页改造
前言 之前我做了个Django的项目,为了让管理后台更加美观,我对Django(应该说是SimpleUI的)默认的Admin后台主页进行改造,具体可以看这篇文章:项目完成 - 基于Django3.x版本 - 开发部署小结 之前的两篇关于Django3.x开发部署小结的文章介绍的都是数据库、接口、性能方面的,看到有朋友留言对后台主页的改造表示有兴趣,所以就写一篇来介绍一下~ 分析 改造基于我定制的
2022-06-28 · Django · 约 1 分钟
实测 Django 6.0:模版片段、后台任务、CSP 安全,三大特性体验报告
呵,连WebSocket都没塞进去就敢叫大版本更新?不过模版片段和内置后台任务总算让Django像个现代框架了,至少写HTMX时不用再到处塞碎片文件。原生CSP?早该有了。至于抛弃Python 3.11——跟不上时代的版本留着也是累赘。
2026-01-20 · Django · 约 1 分钟
Django全文检索实现:HayStack-+-Whoosh-+-Jieba
涉及到的工具 haystack是django的开源搜索框架,该框架支持**Solr**, Elasticsearch, Whoosh, **Xapian搜索引擎,不用更改代码,直接切换引擎,减少代码量。 搜索引擎使用Whoosh,这是一个由纯Python实现的全文搜索引擎,没有二进制文件等,比较小巧,配置比较简单,当然性能自然略低。 中文分词Jieba,由于Whoosh自带的是英文分词,对中文的分
2022-08-26 · Django · 约 1 分钟
讨论
共 0 条加载评论中…