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)

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 服务器

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.pyasgi.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
Logo

汇聚全球AI编程工具,助力开发者即刻编程。

更多推荐