Python API服务中的CGI、FastCGI、WSGI、ASGI详解

1.架构和请求处理方式

1. CGI：每次请求启动进程

特点：

• 每次请求通常会产生新的进程。
• 数据库连接池、内存缓存等进程级资源难以跨请求复用。
• 并发请求多时，进程创建和销毁的成本会比较明显。
• 适合简单脚本、历史遗留系统，不适合大多数新建API服务。

2. FastCGI：长驻进程处理请求

特点：

• 可以复用进程，避免每次请求重新启动解释器。
• 适合需要通过FastCGI协议接入现有Web服务器的系统。
• 需要额外的FastCGI服务器、进程管理或适配层。
• 在现代Python API项目中，通常优先考虑WSGI或ASGI部署方式。

3. WSGI：同步Python Web应用接口

特点：

• 请求处理通常采用同步调用模型。
• 可以通过多个工作进程或线程处理并发请求。
• 对传统CRUD API、数据库查询和普通业务逻辑足够实用。
• 如果大量请求都在等待网络、数据库或其他外部服务，同步模型可能造成工作线程或进程被占用。

4. ASGI：异步Python Web应用接口

ASGI允许应用在等待数据库、HTTP接口等I/O操作时挂起当前协程，让事件循环继续处理其他任务；同时支持WebSocket等不局限于单次请求—响应的通信模式。

特点：

• 适合大量I/O等待型任务，例如调用多个下游API。
• 可以使用async def和await编写异步业务逻辑。
• 支持HTTP长连接、WebSocket和流式通信，具体能力取决于服务器与框架。
• 需要注意：异步不意味着所有代码自动变快。同步阻塞的数据库驱动、CPU密集型任务等仍可能阻塞事件循环。

2.四种方案对比

对比项	CGI	FastCGI	WSGI	ASGI
核心定位	进程调用协议	持久进程调用协议	Python应用接口	Python异步应用接口
典型处理模型	每请求新进程	常驻进程	同步调用	异步事件驱动，也可运行同步应用
进程复用	通常不复用	支持	由服务器决定	由服务器决定
并发机制	多进程	多进程等	多进程、线程等	协程、多进程、线程等
WebSocket	不适合	取决于外围实现	原生接口不支持	支持
常见框架	手写脚本	需适配	Flask、Django同步应用	FastAPI、Starlette、Django ASGI
新建API推荐度	低	特殊场景	高	高