WSGI 与 ASGI：Python Web 开发的两次进化

你有没有想过，当你访问一个网站时，请求是如何从浏览器到达 Python 代码的？

这不是魔法。这是一个协议。

而理解这个协议，是你从"会用框架"到"理解框架"的关键一步。

先说结论

WSGI 是过去，ASGI 是未来。

但别急着抛弃 WSGI。它们各有适用场景，理解它们的区别，能让你在技术选型时不再迷茫。

WSGI：同步时代的王者

什么是 WSGI？

WSGI（Web Server Gateway Interface）诞生于 2003 年。

那时候，Python Web 开发一片混乱。每个框架都有自己的服务器接口，Django 有 Django 的方式，Flask 还没出生，Tornado 自己搞一套。

PEP 3333 统一了这一切。

WSGI 做了一件简单的事：定义了一个标准接口，让 Web 服务器和 Python 应用程序能够对话。

WSGI 的工作原理

想象一个餐厅。

• Web 服务器（如 Nginx） 是门口的服务员，负责接待客人
• WSGI 服务器（如 Gunicorn、uWSGI） 是传菜员，负责把请求送到后厨
• Python 应用 是后厨，负责处理请求并返回结果

WSGI 规定了"传菜员"和"后厨"之间的对话规则：

defapplication(environ, start_response):"""    environ: 包含所有请求信息的字典    start_response: 一个回调函数，用于开始响应    """    status = '200 OK'    headers = [('Content-Type', 'text/plain')]    start_response(status, headers)return [b'Hello, World!']

就这么简单。

每个请求进来，WSGI 服务器调用这个 application 函数，传入请求信息，拿到响应结果。

WSGI 的局限

问题来了。

WSGI 是同步的。这意味着：

defapplication(environ, start_response):# 如果你在这里查询数据库，整个进程都在等    result = database.query("SELECT * FROM users")  # 阻塞！# 如果你在这里调用外部 API，整个进程都在等    response = requests.get("https://api.example.com")  # 阻塞！return [result]

一个请求阻塞，整个工作线程就废了。

你可以多开几个工作进程，但每个进程都占用内存。100 个并发请求 = 100 个进程 = 大量内存消耗。

这在 I/O 密集型场景下简直是灾难。

ASGI：异步时代的新星

为什么需要 ASGI？

时代变了。

• WebSocket 需要长连接
• HTTP/2 支持多路复用
• 异步 I/O 成为主流（asyncio 在 Python 3.4 引入）

WSGI 无法适应这些新需求。

于是 ASGI（Asynchronous Server Gateway Interface）诞生了。

ASGI 的工作原理

ASGI 不只是"异步版本的 WSGI"。它是一个全新的设计。

asyncdefapplication(scope, receive, send):"""    scope: 请求的元信息（类似 WSGI 的 environ）    receive: 异步接收消息的协程    send: 异步发送消息的协程    """await send({'type': 'http.response.start','status': 200,'headers': [[b'content-type', b'text/plain']],    })await send({'type': 'http.response.body','body': b'Hello, World!',    })

关键区别：

1. 异步函数：使用 async/await
2. 消息驱动：通过 receive 和 send 协程通信
3. 支持多协议：HTTP、WebSocket、HTTP/2 都能处理

ASGI 的威力

看看这个对比：

# WSGI - 同步，一个请求阻塞所有defget_data_wsgi(environ, start_response):    result1 = requests.get("https://api1.com")  # 等 1 秒    result2 = requests.get("https://api2.com")  # 等 1 秒# 总耗时：2 秒# ASGI - 异步，并发执行asyncdefget_data_asgi(scope, receive, send):    result1, result2 = await asyncio.gather(        httpx.get("https://api1.com"),        httpx.get("https://api2.com"),    )# 总耗时：1 秒（假设两个请求都是 1 秒）

在 I/O 密集型场景下，性能提升可以是数量级的。

对比总结

实际应用：如何选择？

选 WSGI，如果你：

1. 维护老项目 - 迁移成本需要考虑
2. CPU 密集型任务 - 异步帮不了你，反而增加复杂度
3. 团队不熟悉异步 - 学习成本是真实成本
4. 简单 CRUD 应用 - 够用就行，别过度设计

# 经典组合gunicorn -w 4 -b 0.0.0.0:8000 myapp:application

选 ASGI，如果你：

1. 需要 WebSocket - 实时聊天、推送通知
2. 高并发 I/O - 大量数据库查询、外部 API 调用
3. 从零开始 - 没有历史包袱
4. 追求性能 - 同样的硬件，更高的吞吐量

# 现代组合uvicorn myapp:application --workers 4 --port 8000

一个实际例子

假设你要做一个实时聊天应用：

浏览器 <--WebSocket--> ASGI 服务器 <---> 数据库                            |                            +---> 消息队列                            |                            +---> 缓存（Redis）

用 WSGI？你需要额外的 WebSocket 服务器（如 django-channels），架构变复杂。

用 ASGI？原生支持，一个服务器搞定。

迁移指南

如果你有 WSGI 应用想迁移到 ASGI：

1. 框架支持

• **Django 3.0+**：支持异步视图
• Flask：官方暂不支持，考虑 Quart（Flask 的异步版本）

2. 代码改造

# 之前（WSGI）defview(request):    data = sync_database_query()return JsonResponse(data)# 之后（ASGI）asyncdefview(request):    data = await async_database_query()return JsonResponse(data)

3. 依赖更新

• requests → httpx 或 aiohttp
• psycopg2 → asyncpg 或 psycopg（异步版本）
• redis-py → redis-py（支持异步）

4. 渐进式迁移

不必一步到位。Django 支持同步和异步视图共存：

# 同步视图和异步视图可以在同一个项目里defsync_view(request):# WSGIpassasyncdefasync_view(request):# ASGIpass

深入理解：消息协议

ASGI 不只是异步。它的消息协议设计让它能够支持多种场景。

HTTP 请求的生命周期

1. scope: {'type': 'http', 'method': 'GET', 'path': '/api/users'}2. receive: {'type': 'http.request', 'body': b''}3. send: {'type': 'http.response.start', 'status': 200, ...}4. send: {'type': 'http.response.body', 'body': b'[...]'}

WebSocket 请求的生命周期

1. scope: {'type': 'websocket', 'path': '/ws/chat'}2. receive: {'type': 'websocket.connect'}3. send: {'type': 'websocket.accept'}4. receive: {'type': 'websocket.receive', 'text': 'Hello'}5. send: {'type': 'websocket.send', 'text': 'Hi there!'}6. receive: {'type': 'websocket.disconnect'}

这种设计让 ASGI 服务器能够处理任何基于消息的协议。

常见误区

误区 1：ASGI 一定更快

错。

如果你的应用是 CPU 密集型（比如图像处理、机器学习推理），异步不会帮你。反而可能因为上下文切换而变慢。

ASGI 的优势在于 I/O 等待时的并发能力。

误区 2：必须二选一

错。

Django 可以同时运行 WSGI 和 ASGI。你可以只在需要的地方使用异步。

误区 3：异步代码更难调试

部分正确。

异步代码的堆栈跟踪确实更复杂，但现代工具已经做得不错了。而且，良好的异步代码结构往往更清晰。

总结

WSGI 是一个时代的标志。它简单、稳定、广泛支持。如果你不需要异步，它依然是可靠的选择。

ASGI 是未来的方向。它解决了 WSGI 无法解决的问题，让 Python 在高并发场景下有了与 Node.js、Go 竞争的能力。

理解它们，不是为了追逐新技术的时髦。

而是为了在需要的时候，做出正确的选择。

延伸阅读

• PEP 3333 - Python Web Server Gateway Interface
• ASGI 官方文档
• Uvicorn - 轻量级 ASGI 服务器
• FastAPI - 现代异步 Web 框架

技术不需要复杂。理解原理，选择合适的工具，把事情做成。