搞Python Web开发的人迟早都会撞上这两个缩写WSGI和ASGI。我第一次看到的时候反应是“又是什么新概念”查了一圈资料看完还是觉得云里雾里。后来在部署和调试接口的过程中踩了几次坑才真正把这两个东西吃透。说白了它们不是什么PHP框架那种庞然大物也不需要你记住几百页文档它们本质上是两套“约定”约定Python Web服务器怎么把请求交给你的应用代码你的应用代码又怎么把响应交回去。这篇文章就用大白话拆开讲讲WSGI到底做了什么为什么后来非得再搞一个ASGI不可以及你手里的项目到底应该按哪套规范来写、怎么部署才不出幺蛾子。适合刚入门的Python后端开发者也适合已经在用Django、Flask但一直没搞懂异步模型和同步模型区别的人。1. 先看WSGI它是怎么撑起十五年Python Web生态的1.1 一个时代的问题每个框架都要自己连服务器吗在WSGI出现之前Python Web开发处于“百花齐放但互相不兼容”的状态。你想用Django就得用Django自带的开发服务器你想用Flask又得用Flask的启动器。每个框架都要自己解析HTTP报文、处理Socket连接——这些活儿又来来回回重复造轮子。WSGI是2003年提出来的一套规范全称是Web Server Gateway Interface中文叫Web服务器网关接口。它干的事情就是给“服务器”和“应用”之间划了一条清晰的线服务器管网络细节接收TCP连接、解析HTTP请求、收集请求头、发送响应报文。应用只管业务逻辑你给我一个包含请求信息的字典我返回一个可迭代的响应体。两边都按这个约定来就可以自由组合。你用Flask写好的应用今天配Gunicorn跑明天换uWSGI跑代码不用动。服务器厂商也不用为每个框架单独适配只要实现一套WSGI服务器就能服务所有符合规范的框架。这个思路和一个插座标准类似——电器厂商不用管你家电网是怎么拉的只要插头插口统一到你家电饭锅照样能用。WSGI就是Python Web世界里的那个“插头标准”。1.2 WSGI应用长什么样一个WSGI应用实际上就是一个普通的Python可调用对象函数、类实例都可以。它接收两个参数environ一个dict装着请求相关的所有信息包括请求方法、路径、headers、查询参数、服务端变量甚至还有CGI时代流传下来的各种环境变量。start_response一个回调函数应用用它来宣告响应状态码和响应头。然后应用返回一个可迭代对象里面装着响应体内容字节串或字符串的序列。看一个最原始的例子def simple_app(environ, start_response): status 200 OK response_headers [(Content-type, text/plain; charsetutf-8)] start_response(status, response_headers) body Hello, WSGI!.encode(utf-8) return [body]就这么点代码就是一个合法的WSGI应用。你可以把任意一个支持WSGI的服务器套上来跑。这个函数值得注意的细节是start_response必须在返回可迭代对象之前被调用而且传Content-Length或Transfer-Encoding这类关键头时要格外小心因为这些头直接关系到客户端怎么处理响应体。对于真实框架你写的视图函数最终会被框架包装成这样的一个WSGI调用链。Django也罢Flask也罢底层都是这个模式一堆中间件包在业务函数外面一层层传参、拦截、加工。1.3 为什么说WSGI是同步的WSGI的名字里没有“同步”两个字但它的工作模型是天然的同步。服务器调用application(environ, start_response)之后会一直等到这个函数调用完成返回响应体才算处理完一个请求。注意这里说的“同步”不是说Python代码只能从头跑到尾——你完全可以在函数内部用多线程、多进程做并发。但在一个进程内同一时刻它只能按顺序处理请求。这也带来了一个很直观的问题如果应用处理一个请求要执行一个耗时的I/O操作比如等待数据库查询、调用外部API、读一个大文件在这个过程中这个进程没法去响应其他请求。当时的主流解决办法也很接地气多进程。让Worker进程多开几个每个进程一次处理一个请求大家伙儿排队也算并发。很多部署环境里WSGI服务器通常会配置几个甚至几十个Worker进程靠操作系统做调度。这套模型统治了Python Web生态十几年稳定、简单、好调试绝大部分传统Web应用请求-响应模式跑得都挺好。但随着前端技术演化问题就冒出来了。2. WSGI的软肋长连接、推送、实时交互它都接不住2.1 一个等饭的比喻想象你去一家餐馆吃饭从你点完菜到菜上桌服务员就一直站在你旁边等着不走开。这没问题如果餐厅里只有你一位客人甚至几位客人多雇几个服务员就行。可要是客人多了每个服务员都得一对一守着餐厅就得雇几百上千号人成本爆炸。WSGI就是这个“一对一守着”的服务员。每个HTTP请求都要占用一个Worker从头等到尾。对于普通网页请求一两秒就完事Wait占用也没关系。可遇到需要长时间挂着的连接比如WebSocket、Server-Sent EventsSSE、长轮询总不能在数据库查一个数的时间上就结束而是要持续推数据给客户端。你用WSGI要去接WebSocket连接几乎等于让服务员端着一盘菜站三个小时。2.2 WebSocket为什么让WSGI直接翻车WebSocket和普通HTTP请求的区别在于它是一次HTTP升级客户端发一个带Upgrade: websocket头部的请求服务器响应101状态码之后全双工通信就建立了服务器和客户端可以随时互推数据而且连接可以一直保持。对于WSGI服务器来说处理完这个请求就结束了——它根本没有一个机制来处理“连接建立后继续读/写数据”的阶段。因为WSGI的应用函数是请求-响应模式的函数一旦return整个请求的生命周期就结束了。连接可以保持不关但应用层已经没法控制后续的数据收发。上世纪技术架构下就有一些“擦边球”做法在一个WSGI应用的迭代器里不断产生数据模拟长连接。但用起来极其别扭而且性能差。很多团队为了做即时通信只能另起一套服务用别的技术栈比如Node.js来做WebSocket服务端和Python主站分开维护。维护成本你们可以想象。SSEServer-Sent Events服务器单向推送还稍微好一点因为它是基于普通HTTP的长连接响应。WSGI理论上也能实现只要返回的迭代器一直生成数据不结束就行。但问题依然存在在WSGI的同步模型里这个Worker被这个长连接占用了其他请求就没人处理了。2.3 asyncio的出现改变了底层逻辑Python 3.4开始引入asyncio3.5正式支持async/await语法。这一套东西的核心思想是事件循环Event Loop一个线程用一个循环调度所有协程任务当某个任务在等待I/O时就切到另一个任务去执行等I/O完成再切回来。这种模式下“等待”不再意味着“占用”。一个进程同时挂几千几万个连接放在事件循环模型里是常规操作。这就让Python有了处理高并发长连接的可能。问题马上来了wsgi的应用模型是同步函数asyncio的事件循环没法直接调用一个普通的同步函数除非放到线程池或进程池里反过来你写好的async视图函数也没法被传统的WSGI服务器直接识别。所以社区需要一个新规范既能描述请求-响应的HTTP流程又能承载WebSocket等长连接协议还得天然适配事件循环。这就有了ASGI。3. ASGI到底改了什么从“一对一服务”变成“高铁调度中心”3.1 核心思路把“一次请求”改成“一个作用域一串事件”ASGI全称是Asynchronous Server Gateway Interface异步服务器网关接口。它由Django社区推动设计目标就是解决Python Web的异步化和多协议问题。它的核心抽象不再是“一个函数接收请求返回响应”而是一个scope作用域描述连接的元信息来自HTTP请求、WebSocket连接、或者生命周期消息比如服务器启动/停止。一个事件流应用从一个异步接口持续接收事件比如HTTP请求体分块到达、WebSocket消息进来、连接断开同时通过另一个异步接口发送事件比如写响应头、发响应体、给客户端推消息。ASGI规范把一个应用定义为一个async callableasync def app(scope, receive, send): # scope: dict包含连接类型和元数据 # receive: async callable等待下一个事件 # send: async callable发送事件 ...注意ASGI并没有规定你必须使用任何特定框架——它只定义了应用与服务器之间的接口。真实部署中服务器如Uvicorn或Daphne负责网络层你的框架如FastAPI、Starlette、Django 3.0负责把ASGI接口包装成更高层的视图语法。3.2 scope长什么样直接看一个HTTP类型的scope非常直观{ type: http, # 表明这是一个HTTP连接 asgi: {version: 3.0}, http_version: 1.1, method: GET, scheme: http, path: /api/users, raw_path: b/api/users, query_string: bpage2, root_path: , headers: [ (bhost, bexample.com), (buser-agent, bMozilla/5.0), ], client: (127.0.0.1, 54321), server: (127.0.0.1, 8000), }如果是WebSocket连接scope里会有type: websocket多出subprotocols字段后续还可能带extensions。没有复杂的类也没有魔法就是一个结构良好的字典。你甚至可以不用任何框架纯手写一个ASGI应用只是那样处理路由、解析参数会很麻烦。3.3 事件循环中的“拽消息”模型对于HTTP请求ASGI应用收到的时间线大概是这样的服务器解析完请求头发一个http.request事件事件里有body可能是一部分或者全部。应用调用receive()收到这个事件开始处理。如果请求体很大后续还会有更多http.request事件}应用反复调用receive()拉取。应用处理完业务调用send()发送事件先发http.response.start含状态码和响应头再发http.response.body含响应体内容。发送完之后这个请求就算走完了。这很像你和其他人通过消息队列对话你不主动收就一直等消息到了就处理处理完再发出去。事件循环模型天然契合这套玩法因为receive()本身就是一个可等待的协程——任务在等待消息时事件循环可以调度其他连接的任务。3.4 它怎么支持WebSocket和协议升级同一个ASGI应用可以同时处理HTTP和WebSocket不需要另开服务。关键是scope里的type字段类型为http走HTTP流程。类型为websocket应用先调用receive()收到websocket.connect事件然后可以选择接受或拒绝连接通过send()发websocket.accept或websocket.close。客户端发消息过来时事件类型变成websocket.receive里面有text或bytes。应用推数据用websocket.send事件。连接关闭时是websocket.disconnect。这个设计为什么重要因为一个端口、一套服务、一个应用就能同时支持常规HTTP接口、SSE推送、WebSocket聊天。部署时不需要再拆分服务人的精力省下不少。ASGI规范还定义了“生命周期”事件比如lifespan.startup和lifespan.shutdown。应用可以在启动时连数据库池、加载缓存关闭时优雅释放资源。这在之前的WSGI里没有统一标准——框架各搞各的迁移就特别痛苦。3.5 也不是让你把老代码重写ASGI接口和WSGI接口长得不一样但你不需要把老框架全部推翻。很多框架在实现层做了兼容层。比如Django从3.0开始原生支持ASGI同时它自己的核心仍然是同步的WSGI架构只是外面套了一层异步适配。用asgiref库里的async_to_sync和sync_to_async工具可以在同步上下文和异步上下文之间来回转换。所以你完全可以在一个ASGI项目里继续用Django的ORM——ORM本身是同步的框架会在后台用线程池去执行只是你要注意钩子别在异步代码路径里随意调用同步ORM操作否则一个查询就可能阻塞整个事件循环。用一句话说清WSGI和ASGI的区别WSGI让服务器把请求丢给一个同步函数这个函数跑完就完事ASGI让服务器把一个连接的生命周期拆成事件流交给一个异步协程去实时处理。前者是“暂存任务”后者是“在线对话”。4. 实际部署与框架选型这轮行情下怎么下注4.1 主流框架的支持情况先看一张表心里有个底框架支持WSGI支持ASGI当前推荐部署方式Flask原生支持不支持需第三方包装Gunicorn WSGI WorkerDjango原生支持3.0 原生支持传统接口用WSGI或整体切ASGIFastAPI不直接支持原生支持Uvicorn / HypercornStarlette不直接支持原生支持UvicornQuart不直接支持原生支持Hypercorn / UvicornTornado有兼容层不直接支持自带服务器Flask是目前唯一没有官方ASGI支持的“前三大”框架之一。不过你依然可以用Flask配合aiohttp或者单独搭WebSocket服务如Channels来弥补实时通信需求只是架构上会麻烦一些。Django的情况比较特殊。它的异步支持是“渐进式”的你可以用daphne或uvicorn启动整个项目但项目内部大量组件仍然以同步方式工作框架会自动用线程池帮你转换。这种兼容模式能让你在不重写业务代码的情况下先跑起来但要让真正吃IO的代码异步化还得自己动手改视图、写async ORM调用。4.2 如果新项目选型我建议这样新项目如果预期涉及WebSocket、长轮询、SSE、页面上有大量并发推送直接选ASGI栈别犹豫。FastAPI或者Starlette就是这么来的免去将来迁移的痛苦。这类框架自带OpenAPI文档写API接口的体验也很好。新项目如果就是标准CRUD接口没有特别高的并发诉求用WSGI完全没问题。Django Gunicorn很稳调试也省心。很多团队纠结要不要上ASGI其实可以先看业务有没有“长连接”需求——没有的话上不上ASGI对接口性能影响不大反而增加对中间件和ORM的适配成本。老项目迁移不建议一次性切。先把项目的接口测试覆盖率提上去再用ASGI服务器挂着跑看日志有没有报“同步调用阻塞”之类的告警一个一个接口改造。Django项目如果只是普通请求响应甚至可以长期保持WSGI不用动。4.3 部署命令和Worker模型WSGI时代最经典的部署是Gunicorngunicorn -w 4 -b 0.0.0.0:8000 myproject.wsgi:application-w 4表示开4个Worker进程。每个Worker进程一次处理一个请求如果你的接口里有慢查询请求一多就会排队通常得靠增加Worker数扛住。ASGI时代主流是Uvicornuvicorn myproject.asgi:application --host 0.0.0.0 --port 8000Uvicorn默认单进程多任务一个进程可以同时处理大量连接。如果你想要多进程充分利用多核CPU用Gunicorn做进程管理器把Uvicorn当作Workergunicorn -w 4 -k uvicorn.workers.UvicornWorker myproject.asgi:application不加-k参数时Gunicorn用的是同步Worker那相当于还是WSGI那套模型顶上ASGI的意义就没了。所以你要是用Gunicorn跑ASGI项目一定别忘写-k uvicorn.workers.UvicornWorker。异步服务器还有别的选择Daphne是Django Channels官方推荐的服务器Hypercorn则支持HTTP/2和HTTP/3协议支持上会丰富一些。选Uvicorn还是Hypercorn看你是否需要HTTP/2/3以及和团队已有的基础设施是否兼容。4.4 资源占用和性能预期很多人在意性能数据。这个没法给一个万能数字但可以给一个经验值在普通的云服务器上用Uvicorn跑ASGI应用几万个并发的长连接是可能的而同一台机器用WSGI跑同样数量的短时请求几百万的并发会差很多。不过性能瓶颈永远不只是服务器模型。如果你的业务逻辑里含CPU密集计算图像处理、数据分析、同步数据库查询、同步外部API调用事件循环也帮不了你反而会因为调度开销多出一点损耗。ASGI擅长的是I/O密集场景对于纯CPU任务一定要丢给线程池、进程池或者专门的队列去处理别放在事件循环线程里硬算。5. 实操中的常见坑与排查方法5.1 在事件循环里做了同步阻塞调用这是最典型的ASGI事故。一个视图函数被声明为async def然后里面直接调用了requests.get()——这玩意儿是同步阻塞的。在异步运行时里它会卡住整个事件循环期间所有人的请求都被堵住。排查方法如果在压测中发现响应时间突然集体飙升看一眼日志里有没有长时间卡住的协程或者用py-spy、asyncpg的工具抓一下现场。更稳妥的办法是提前规划纯CPU工作放线程池比如await run_in_threadpool(fetch_external_api, url)纯I/O工作就用原生异步库比如httpx.AsyncClient或aiohttp。5.2 还是用了同步ORM的代码路径用Django的ASGI模式跑起来很容易但底层ORM查询是同步的。如果大量请求打到同一个同步ORM查询上就会频繁触发线程池调度整体吞吐量会受影响。处理思路是把读多写少的高频查询改成原生异步数据库驱动使用sync_to_async配合数据库连接池或者干脆在业务设计上减少对数据库的即时依赖比如把热数据放缓存。不是每个项目都需要把ORM全换掉但核心热路径要安排明白。5.3 WebSocket握手反复失败常见的表现是前端new WebSocket(...)时一直报握手失败。排查从scope下手先确认请求路径有没有被路捕捉到。很多框架的路由是HTTP和WebSocket分开匹配的你不会希望WebSocket请求被普通的HTTP视图拦截。另外如果线上有负载均衡器或反向代理需要确保它们开启了Upgrade头透传否则HTTP升级请求还没到应用层就被剥掉了。5.4 迁移后出现线程池耗尽警告当你从WSGI切到ASGI时大量同步中间件、同步视图、同步ORM调用会被自动丢到线程池执行。如果线程池上限太小并发一上来就会触发Thread pool executor queue overflow之类的警告。调整方式是在启动前设置线程池大小上限或者给sync_to_async指定thread_sensitiveFalse并复用专用线程池。如果是第三方库造成的优先考虑换异步版本或让它在独立进程里跑。5.5 常见问题速查表现象可能原因排查看这里启动后大量请求超时事件循环里出现同步阻塞调用检查async视图内是否用requests等同步库WebSocket连接建立后马上断开路由没匹配或代理没透传Upgrade头看scope类型检查Nginx/Caddy配置接口响应很快但吞吐量上不去同步ORM查询频繁占用线程池看线程池监控考虑异步驱动切换ASGI后原来好用的中间件报错中间件只支持WSGI检查中间件的接口定义需替换部署命令看起来没问题但报错Gunicorn默认用了同步Worker加-k uvicorn.workers.UvicornWorker5.6 迁移后续的演进方向ASGI本身仍在进化ASGI规范从v2到v3增加了生命周期和可扩展性。框架层面也越来越成熟你现在从零写一个支持WebSocket和HTTP的Python服务选择已经比三五年前多得多。很多人担心异步生态还不够完善——其实这些年核心痛点已经解决大半剩下的多数是历史遗留代码问题而不是ASGI本身的问题。6. 一个简单的ASGI应用从头到尾自己跑通这里完整写一个最小但能演示“HTTP WebSocket两种协议并存”的ASGI应用方便看明白它的运行机制。不用任何框架纯标准库加Python内置的asyncio配Uvicorn运行。6.1 写一个最简ASGI应用async def app(scope, receive, send): if scope[type] lifespan: while True: message await receive() if message[type] lifespan.startup: await send({type: lifespan.startup.complete}) elif message[type] lifespan.shutdown: await send({type: lifespan.shutdown.complete}) return if scope[type] http: await send({ type: http.response.start, status: 200, headers: [(bcontent-type, btext/plain)], }) await send({ type: http.response.body, body: bHello from ASGI, }) return if scope[type] websocket: await send({type: websocket.accept}) while True: event await receive() if event[type] websocket.receive: text event.get(text, ) await send({type: websocket.send, text: fecho: {text}}) elif event[type] websocket.disconnect: return保存为app.py启动uvicorn app:app访问http://127.0.0.1:8000能得到文本响应。WebSocket客户端连上后发什么就被回复什么。就这么一点代码你已经把HTTP和WebSocket都接管了。这轮流程走下来你对ASGI就不会再觉得玄乎——它就是一个基于事件流的异步接口约定。6.2 对照一下WSGI写法用WSGI做同样的事核心部分大概是from wsgiref.simple_server import make_server def app(environ, start_response): start_response(200 OK, [(Content-Type, text/plain)]) return [bHello from WSGI]一个请求来处理完就结束。它非常朴素的解决了“短连接、快速响应”的问题。所以你要是开发一个内部管理后台、运营工具、定时任务周边这种模式省事没毛病。但要是你的产品形态有实时消息、协作白板、游戏服务器这种场景ASGI才是正经方案。7. 部署经验与个人体会我在实际项目里遇到的情况是这样一个后台系统原本是Django Gunicorn跑了好几年页面交互一直没问题。后来要加一个实时通知模块一开始想用WebSocket硬接在WSGI里折腾了两个星期也没找到优雅的方案最后整体切到ASGI才算是理顺了。切完之后最明显的感受是如果再让我做一次选择我会在项目一开始就把部署架构定位在ASGI上。倒不是说WSGI不行而是当业务稍微不可控地生长时ASGI能向下兼容那段“请求-响应”的常规流程也能向上支持未来可能出现的推送、实时协作等高交互玩法。架构上留有弹性比事后腾挪省心得多。另外一个很实在的建议新人学这块的时候别一上来就背“WSGI是同步的ASGI是异步的”这种结论。先动手写一个最简单的WSGI应用再用Uvicorn跑一个最简单的ASGI应用各跑一遍观察请求日志你马上就能体会到两者的运行节奏完全不同。代码量都不大半小时就能建立起体感。最后再分享一个小技巧排查线上接口问题时先看请求是经过WSGI还是ASGI链路进来的。很多看起来像业务代码的问题其实是服务器模型和框架模型不匹配导致的。比如你在ASGI模式下调用了同步ORM操作、同步邮件发送性能一崩业务代码却完全正常——你不会想到是这两层接口之间的衔接在作怪。搞清楚了底层约定排查方向就会清晰很多。