【Web应用开发笔记】Django笔记5-2:基础概念(Nginx、WSGI、中间件、静态文件)
·
0. 前言
在前面的学习中,我们知道了 Django 开发过程中的一些基本流程。
随着学习的深入,出现了一些新的概念:静态文件、WSGI / ASGI、Nginx / Apache、中间件、PaaS平台 等。
作为没有基础的新手肯定很困惑:
- 在本地开发时,我直接使用 Django 框架就可以创建出可以访问的网页了,为什么还需要上述概念?
- 如果上述概念是必须的,我应该怎么理解这些概念?
本文将简要解答这些问题。
1. Web 服务器 & Web 应用
首先我们需要知道 Web 服务器、Web 应用 这两个概念。
一个简单的类比如下:
| 角色 | 现实餐厅 | Web 开发 |
|---|---|---|
| 门面接待 | 迎宾员、前台 | Web 服务器 (Nginx/Apache) |
| 后厨厨师 | 真正做饭的人 | Web 应用 (Django) |
| 传菜员 | 把订单送给厨师,把菜端给客人 | WSGI/ASGI |
也就是说,在实际落地的项目中,处理用户访问网页这个事情是需要分工的。
简单来说,就是专业的事交给专业的“人”来干。
2 开发阶段的 Django
2.1 Django 是一个“全家桶”
本地开发时,通过 python manage.py runserver 启动服务
用户访问时,简易流程如下:
浏览器 → Django 自带的开发服务器 → Django 应用
↑
(这是一个"简易版全家桶":迎宾+传菜+厨师都是同一个人)
- runserver 实际上偷偷干了三件事:
- Web 服务器(监听端口 8000)
- WSGI 处理(把 HTTP 请求转成 Python 对象)
- Django 应用(执行业务逻辑)
2.2 局限性
- ⚠️ 这是个"临时工":
- 单线程,同时只能处理 1 个请求
- 没有安全保护
- 性能极差
- 开发阶段可以快速验证页面效果
- 官方明确禁止用于 生产环境
2.3 动态、静态请求
- 开发阶段的 动态请求、静态文件请求 的简要过程如下图:

- 这里的工作全由 django 服务来完成
- 仅用于开发阶段
- 请勿用于上线部署
3. 生产阶段的 Django
- 生产环境 (DEBUG=False)
3.1 方案1:使用 Nginx

- Nginx
- 位于 Gunicorn/Uvicorn 之前,作为独立进程
- 性能极佳
- 需要单独安装、配置、维护
- 在这个框架里,你可以明显看出标准的三层结构
- web 服务器(Nginx)
- WSGI 服务(Gunicorn)
- web 应用(Django)
3.2 方案2:使用 WhiteNoise 中间件
3.2.1 处理流程

- WhiteNoise
- 嵌入在 Django 应用内部,同一进程
- Python 处理,适合中小规模(几百并发)
pip install即可,配置简单
- 在这套框架里,我们似乎找不到 web 服务器了
- Gunicorn 不只是 WSGI 服务器,实际上也是一个"微型 Web 服务器"
- WhiteNoise:静态文件处理器
- Django:web 应用
- 按照标准三层结构来看
- web 服务器(功能分散在以下地方)
PaaS 平台:边缘处理 TLS/安全- Gunicorn:处理 HTTP 解析
- WhiteNoise:处理静态文件
- WSGI 服务(Gunicorn)
- web 应用(Django)
- web 服务器(功能分散在以下地方)
3.2.2 PaaS 平台 的作用
- 上面出现了一个新概念:PaaS 平台
- 它是开发者部署 Web 应用时依赖的平台中的一种
- 从运维难度和开发效率的角度来看它比较适合新手、独立开发者
- 这里仅简单展示其在请求流程中的作用

- 后面的第6章详细介绍 IaaS 与 PaaS
3.3 对比
- 功能分布
| Web 服务器功能 | 传统架构(Nginx) | WhiteNoise 架构 |
|---|---|---|
| 监听 HTTP 端口 | Nginx 监听 80/443 | Gunicorn 直接监听(如 0.0.0.0:8000) |
| 处理 HTTP 协议 | Nginx 解析请求头、Keep-Alive | Gunicorn 的 HTTP 解析器(gunicorn 内置 http parser) |
| 静态文件服务 | Nginx 直接读取磁盘返回 | WhiteNoise 中间件拦截并返回 |
| Gzip 压缩 | Nginx 模块 | WhiteNoise 自动压缩 |
| 缓存控制头 | Nginx 配置 expires | WhiteNoise 自动添加 |
| SSL/TLS 终止 | Nginx 处理 HTTPS | PaaS 平台 负载均衡器 或 Gunicorn 自带 SSL |
| 安全限流/防火墙 | Nginx limit_req | PaaS 平台层 或 Django 中间件 |
| 负载均衡 | Nginx upstream | PaaS 平台自动处理 |
- 多维度对比
| 对比维度 | Nginx | WhiteNoise |
|---|---|---|
| 本质 | 独立的 C 语言编写的反向代理/Web 服务器 | Python 编写的 Django 中间件 |
| 架构位置 | 位于 Gunicorn/Uvicorn 之前,作为独立进程 | 嵌入在 Django 应用内部,同一进程 |
| 部署复杂度 | 需要单独安装、配置、维护 | pip install 即可,配置简单 |
| 配置文件 | 需要编写 nginx.conf,管理 server 块、location 规则 |
只需在 settings.py 中添加几行 |
| 性能 | ⭐⭐⭐ 极高,C 语言优化,事件驱动,轻松处理 10k+ 并发 | ⭐⭐ 良好,Python 处理,适合中小规模(几百并发) |
| 静态文件吞吐量 | 极高,直接内核传输(sendfile) | 较好,经过 Python 层,有额外开销 |
| 内存占用 | 独立进程,但 C 语言内存效率高 | 共享 Django 进程内存,Python 开销较大 |
| CPU 使用 | 极低 | 中等(WhiteNoise 会压缩、计算文件指纹) |
| 缓存控制 | 需手动配置 expires、etag、cache-control | 自动处理,支持文件指纹(ManifestStorage) |
| Gzip/Brotli 压缩 | 需编译模块或手动配置 | 内置支持,自动压缩 |
| HTTP/2、HTTP/3 | 原生支持 | 依赖底层 ASGI 服务器(如 Uvicorn) |
| SSL/TLS 终止 | 原生支持,性能优异 | 依赖反向代理或 Django 层处理 |
| 负载均衡 | 原生支持 upstream、健康检查 | 不支持,需配合其他工具 |
| 安全防护 | 完善的限流、防 DDoS、WAF 规则 | 基础功能,依赖 Django SecurityMiddleware |
| 容器化友好度 | 需多容器编排(Nginx + App)或复杂单容器 | ⭐⭐⭐ 极佳,单容器即可运行 |
| Serverless 支持 | 不适合(如 AWS Lambda、Vercel) | ⭐⭐⭐ 完美支持,无状态、自包含 |
| 平台即服务(PaaS) | Heroku、Fly.io 等需要额外配置 | ⭐⭐⭐ 原生支持,一键部署 |
| 文件存储扩展 | 需配合 S3/对象存储 + 代理配置 | 支持本地、S3(需 django-storages 配合) |
| 开发环境一致性 | 开发与生产配置差异大 | 开发与生产配置几乎相同 |
| 调试难度 | 错误日志分散,需查看 Nginx 和 App 两处 | 统一在 Django 日志中,调试简单 |
| 适用项目规模 | 大型、高流量、需要极致性能 | 中小型、初创项目、MVP、内部工具 |
| 典型使用场景 | 电商、新闻站、SaaS 平台、高并发 API | 博客、CMS、后台管理、原型验证、微服务 |
| 维护成本 | 高(需专业运维知识,关注安全补丁) | 低(Python 包,随项目依赖更新) |
| 学习曲线 | 陡峭(需理解 location、rewrite、upstream 等) | 平缓(Django 开发者友好) |
| 社区生态 | 庞大,企业级解决方案成熟 | Django 社区活跃,文档清晰 |
| 成本(云资源) | 可能需要独立服务器或容器 | 共享计算资源,成本更低 |
3.4 技术选型建议
| 阶段 | 架构 | 说明 |
|---|---|---|
| MVP 阶段 | WhiteNoise + Gunicorn | 快速上线,单容器部署 |
| 增长阶段 | CDN (CloudFlare) + WhiteNoise | CDN 缓存静态文件,减轻应用压力 |
| 成熟阶段 | CDN + Nginx + Gunicorn | 极致性能,Nginx 处理 SSL、压缩、限流 |
4. 中间件简介
上面提到了 WhiteNoise 中间件,这里简要介绍一下。
4.1 简介
中间件是处理请求和响应的"过滤器管道",位于 Web 服务器和 Django 应用之间。
4.2 类比
访客(请求)→ 大楼保安(SecurityMiddleware)→ 前台登记(SessionMiddleware)
→ 门禁刷卡(AuthenticationMiddleware)→ 找具体部门(Django 视图)
返回时:原路经过各部门,可能带上出门条(响应头)→ 最终离开
4.3 特性
| 特性 | 说明 |
|---|---|
| 双向处理 | 既能处理进来的请求,也能处理出去的响应 |
| 链式调用 | 按 MIDDLEWARE 列表顺序执行,像流水线 |
| 短路机制 | 可以直接返回响应,不继续往后传(如 WhiteNoise 发现是静态文件) |
| 解耦 | 通用功能(认证、安全、静态文件)从视图中剥离 |
5. WSGI & ASGI
- 简单理解
- WSGI、ASGI 都是 Web 服务器和 Web 应用之间的
标准接口协议 - WSGI 是同步协议,ASGI是异步协议
- Gunicorn 是 WSGI 服务器,Uvicorn 是 ASGI 服务器
- WSGI、ASGI 都是 Web 服务器和 Web 应用之间的
5.1 类比
| WSGI (Gunicorn) | ASGI (Uvicorn) | |
|---|---|---|
| 服务员特点 | 一个人专注服务一桌,干完再下一桌 | 一个人同时服务多桌,来回切换 |
| 适合场景 | 点餐、结账(HTTP 请求-响应) | 边吃边聊(WebSocket 长连接) |
| 形象比喻 | 传统服务员 | 擅长同时处理多任务的管家 |
5.2 对比
| 维度 | WSGI | ASGI |
|---|---|---|
| 全称 | Web Server Gateway Interface | Asynchronous Server Gateway Interface |
| 本质 | Python Web 服务器 ↔ Web 应用的标准接口协议 | Python Web 服务器 ↔ Web 应用的标准接口协议 |
| 处理模式 | 同步(一个请求处理完才能接下一个) | 异步(可以同时处理多个请求) |
| 协议支持 | 仅支持 HTTP/1.1 | 支持 HTTP/1.1、HTTP/2、HTTP/3、WebSocket |
| 适用场景 | 传统网站、REST API、无实时需求 | 实时聊天、在线游戏、推送通知、高并发 API |
| 代表服务器 | Gunicorn、uWSGI、mod_wsgi | Uvicorn、Daphne、Hypercorn |
| 启动方式 | gunicorn myapp.wsgi:application |
uvicorn myapp.asgi:application |
| Django 支持 | Django 1.0+ 原生支持 | Django 3.0+ 原生支持 |
| 性能特点 | 多进程模型,适合 CPU 密集型 | 单线程+协程,适合 I/O 密集型 |
5.3 Gunicorn & Uvicorn
| 服务器 | 支持的协议 | 说明 |
|---|---|---|
| Gunicorn | WSGI(原生) | 纯 WSGI 服务器,不能跑 ASGI |
| Uvicorn | ASGI(原生)、WSGI(兼容) | 原生 ASGI,通过适配器可兼容 WSGI |
| Gunicorn + Uvicorn Worker | ASGI | Gunicorn 管理进程,Uvicorn 处理 ASGI |
5.4 启动方式
- 新建项目时会同时生成
wsgi.py和asgi.py - 启动方式
# WSGI 方式
gunicorn myproject.wsgi:application
# ASGI 方式
uvicorn myproject.asgi:application
# 或
daphne -b 0.0.0.0 -p 8000 myproject.asgi:application
5.5 技术选型建议
使用 WSGI 的场景:
- 传统的 CRUD 网站
- RESTful API 服务
- 没有实时通信需求
- 追求简单稳定
使用 ASGI 的场景:
- 需要 WebSocket(在线聊天、实时通知)
- 高并发需求
- 实时数据推送(股票行情、游戏)
- 使用 Django Channels 扩展
| 场景 | 推荐方案 |
|---|---|
| 学习阶段/小型项目 | WSGI + Gunicorn(简单) |
| 生产环境传统网站 | WSGI + Gunicorn/Nginx |
| 需要 WebSocket/实时功能 | ASGI + Uvicorn + Django Channels |
| 现代高性能 API 服务 | ASGI + Uvicorn |
6. IaaS & PaaS
6.1 IaaS(基础设施即服务)
全称:Infrastructure as a Service(基础设施即服务)
形象比喻:租毛坯房
房东给你提供房子、水电、墙壁、地板——基础设施都有了,但里面空空如也。你需要自己买家具、装修、布置,才能住进去。
在 Django 开发中:
- 你租用的是云服务器(如阿里云 ECS、AWS EC2)
- 服务商只提供:CPU、内存、硬盘、网络
- 你需要自己做:安装操作系统、配置 Python 环境、安装 Nginx、部署 Django、配置数据库、处理安全补丁…
特点:灵活性高,但运维工作量大
6.2 PaaS(平台即服务)
全称:Platform as a Service(平台即服务)
形象比喻:租精装公寓,拎包入住
房子已经装修好,家具齐全,水电煤全通。你只需要带上行李(你的代码)就能住。甚至管家还提供日常维护服务。
在 Django 开发中:
- 你使用的是应用托管平台(如 Heroku、PythonAnywhere、Google App Engine、阿里云 SAE)
- 服务商提供:操作系统 + Python 运行环境 + 数据库 + Web 服务器 + 自动部署流水线
- 你只需要:写 Django 代码,
git push上传,平台自动帮你部署和运行
特点:开发效率高,运维省心,但灵活性受限(只能用平台支持的组件)
6.3 对比
- 类比
| IaaS | PaaS | |
|---|---|---|
| 比喻 | 毛坯房 | 精装公寓 |
| 你管理 | 操作系统、环境、部署 | 只写代码 |
| 服务商管理 | 硬件、网络 | 硬件、网络、平台、运行环境 |
| 适合 | 需要深度定制、有运维团队 | 快速开发、专注业务逻辑 |
- 功能
| 功能 | 自建服务器 | PaaS 平台 |
|---|---|---|
| HTTPS/TLS | Nginx 处理 | 平台边缘节点处理 |
| DDoS 防护 | 需自行配置(如 CloudFlare) | 平台内置 |
| 全局负载均衡 | 需自行搭建 | 平台自动提供 |
| HTTP 请求解析 | Nginx + Gunicorn 都做 | Gunicorn 做 |
| 静态文件服务 | Nginx 直接提供 | WhiteNoise 提供 |
| 进程管理 | 你管理 Nginx + Gunicorn | 你只管理 Gunicorn |
6.4 国内外 PaaS 平台简介
| 平台 | 所属国家/地区 | 免费额度 | 国内访问速度 | 银联支持 |
备注 |
|---|---|---|---|---|---|
| Fly.io | 美国 | 有 | 一般 | ❌ | 文档好,容器化部署 |
| Heroku | 美国 (Salesforce) | 有限 | 较慢 | ❌ | 老牌平台,生态成熟 |
| Vercel | 美国 | generous | 快 (有 CDN) | ❌ | 前端/全栈首选 |
| Railway | 美国 | 有 | 一般 | ❌ | 简单易用,适合初学者 |
| Render | 美国 | 有 | 一般 | ❌ | 替代 Heroku 的好选择 |
| DigitalOcean App Platform | 美国 | 有 | 一般 | ❌ | 老牌云厂商的 PaaS |
| AWS Elastic Beanstalk | 美国 | 12个月免费 | 一般 | ⚠️ 部分支持 | 需绑国际信用卡 |
| Google App Engine | 美国 | 有 | 慢 | ❌ | |
| Azure App Service | 美国 | 有 | 慢 | ✅ 支持 | 微软生态,国内有 office |
| 阿里云 函数计算/SAE | 中国 | 有 | ⭐ 极快 | ✅ 支付宝/微信 | 国内首选 |
| 腾讯云 云开发/SCF | 中国 | 有 | ⭐ 极快 | ✅ 微信支付 | 微信生态集成好 |
| 华为云 FunctionGraph | 中国 | 有 | ⭐ 极快 | ✅ | 企业级 |
| Zeabur | 中国/新加坡 | 有 | 快 | ✅ 支付宝 | 华人团队,体验好 |
7. 总结
7.1 三层结构
- web 服务器
- 方案1:IaaS平台 + Nginx
- 方案2:PaaS平台 + Gunicorn/Uvicorn + WhiteNoise中间件
- WSGI 服务(Gunicorn)或者 ASGI 服务(Uvicorn)
- web 应用(Django)
7.2 不同框架下的请求流程
7.2.1 开发环境

7.2.2 WhiteNoise

7.2.3 Nginx

7.3 其他概念
- WSGI & ASGI
- IaaS、PaaS
更多推荐




所有评论(0)