### 从Python ASGI看异步时代的Web接口规范1. 它是什么要说ASGI得先从WSGI说起。十年前写Python Web应用时Django、Flask用的都是WSGI——一个同步的网关接口规范。它像是一条单向车道每次只能处理一个请求处理完了才能接下一个。这在当年够用但遇到长连接、WebSocket这类需要保持连接的东西WSGI就暴露了它的局限性它压根没设计过要处理这种场景。ASGI异步服务器网关接口就是为解决这个问题而生的。它把WSGI的“请求-响应”模型扩展成更通用的“事件-响应”模型。简单说ASGI不只是处理HTTP请求它能处理各种类型的消息HTTP请求是消息WebSocket连接是消息甚至服务器推送也是消息。如果把WSGI比作传统的邮局——你得排着队等着窗口处理你的挂号信那ASGI就像微信——你可以同时开多个会话每个会话保持连接随时收发消息。当然不是简单地多开几个窗口而是协议层面完全不同的设计。ASGI规范的核心是两个组件协议服务器和应用程序。协议服务器比如Uvicorn、Daphne负责解析网络上的字节流把它转成ASGI能理解的“scope”连接信息和“events”事件流。应用程序就是你的业务逻辑它接收这些事件做出响应。这种分层设计的妙处在于你可以在同一个应用里处理HTTP请求、WebSocket连接、甚至SSE服务端推送而且这些连接互不阻塞。这在WSGI时代几乎是不可能的。2. 它能做什么ASGI最直接的好处就是处理高并发I/O密集型任务。比如一个聊天应用成千上万个WebSocket连接同时保持如果有消息广播ASGI可以高效地通知所有连接的客户端而不需要为每个连接开一个线程。另一个常见场景是实时数据推送。比如说股票行情页面后端数据一变前端要马上更新。用ASGI的SSE机制可以省去前端轮询的麻烦而且带宽利用率更高。还有前后端能共享逻辑。如果前端需要用户认证用ASGI可以把认证逻辑放在同一层处理不管是HTTP请求还是WebSocket连接都能走同一套认证方案。这在微服务架构下尤其有用因为可以减少内部调用的复杂度。不过要注意ASGI不是万能的。它擅长的是I/O密集型的任务如果是计算密集型的比如大型图像处理、复杂的数据分析用ASGI反而会因为协程切换和任务调度的开销降低性能。这种情况更适合用Celery这类任务队列。3. 怎么使用使用ASGI通常需要三样东西一个ASGI服务器比如Uvicorn一个ASGI框架比如FastAPI、Starlette、Django Channels以及你的应用代码。先看个最简单的例子。一个返回JSON的ASGI应用可不借助任何框架asyncdefapp(scope,receive,send):ifscope[type]http:awaitsend({type:http.response.start,status:200,headers:[(bcontent-type,bapplication/json)],})awaitsend({type:http.response.body,body:b{message: hello},})然后运行uvicorn app:app就能看到结果了。但说实话谁会这么写应用呢实际开发中都用框架。用FastAPI写个更实际的例子fromfastapiimportFastAPI,WebSocketfromfastapi.responsesimportStreamingResponseimportasyncio appFastAPI()app.get(/)asyncdefroot():return{message:Hello World}app.websocket(/ws)asyncdefwebsocket_endpoint(websocket:WebSocket):awaitwebsocket.accept()whileTrue:dataawaitwebsocket.receive_text()awaitwebsocket.send_text(fEcho:{data})app.get(/stream)asyncdefstream():asyncdefgenerate():foriinrange(10):yieldfdata:{i}\n\nawaitasyncio.sleep(1)returnStreamingResponse(generate(),media_typetext/event-stream)这个例子展示了ASGI的三种典型场景正常HTTP请求、WebSocket连接、SSE流式响应。注意看三个endpoint共享同一个服务器进程但不会彼此阻塞。每个endpoint里都有await这说明它们虽然看起来是“同时运行”但底层依托的是事件循环的协作式调度并不是真正的并行。这里有个容易踩的坑如果你在异步视图里调用了同步的库比如requests.get这会导致整个事件循环被阻塞。解决办法是用asyncio.to_thread把同步调用丢到线程池里去跑或者换用支持异步的库比如httpx。4. 最佳实践选择合适的服务器。Uvicorn性能最好适合生产环境Daphne是Django Channels的官方选择如果你用Django它会更顺手Hypercorn支持HTTP/2如果要兼容某些特定协议可以考虑它。个人经验是大多数情况用Uvicorn就够了。谨慎处理长连接。WebSocket和SSE这种长连接会长期占用资源如果应用负载很高要考虑限流。可以用Redis来做全局的连接统计当某个用户的连接数超过阈值时拒绝新的连接。另外对于WebSocket记得在连接断开时清理资源——有些人会忘记写try/finally导致连接断开后协程还一直跑着。异步数据库驱动是必需的。如果数据库查询是同步的那么ASGI的异步优势就荡然无存了。最常用的选择是asyncpgPostgreSQL和aiomysqlORM层面可以用SQLAlchemy的异步模式或者用GINO。但注意很多ORM的异步支持还不完善比如Django的ORM虽然支持异步但查询集的操作还是同步的得用sync_to_async包一层。事务管理需要小心。在同步世界里事务的范围很清楚开始、操作、提交或回滚。但在异步环境下如果协程中途被挂起事务的隔离性可能出问题。一个简单的做法是在需要事务的地方显式地用async with管理连接而不是依赖隐式的事务管理。合理设置并发限制。ASGI应用默认可以处理大量并发但这不意味着你可以无限制地开协程。每个协程都有内存开销并发量太大一样会撑爆内存。一般生产环境会配合负载均衡器比如Nginx来限流或者在应用层用Semaphore来控制最大并发数。监控工具要跟上。传统的APM工具对异步的支持参差不齐。排查性能瓶颈时如果看的是异步代码的调用栈经常让人摸不着头脑。推荐用asyncio自带的调试模式PYTHONASYNCIODEBUG1或者用asyncpg这类库自带的日志能让你看到每个查询的具体耗时。5. 和同类技术对比先说WSGI。这是ASGI出现前的事实标准。Flask、Django通道除外都是基于WSGI的。WSGI的优点在于简单、稳定、生态完善几乎所有的Python Web库都兼容它。缺点就是前面说的同步模型处理不了WebSocket也处理不了高并发的长连接。如果现有项目没有实时交互的需求用WSGI完全可以没必要强行上ASGI。但新项目我倾向于推荐ASGI因为它的弹性更好将来想加个WebSocket功能不用重构。再说Node.js。Node.js自身就是事件驱动、异步非阻塞的和ASGI的理念很像。Node.js用单线程的事件循环处理大量并发胜在JIT编译的V8引擎简单I/O任务性能比Python强。但Python的优势在于生态——数据科学、机器学习、运维自动化这些库大部分是Python的。如果团队里有不少人写Python用ASGI统一技术栈能减少上下文切换的成本。然后是Go。Go用的是Goroutine是真正的并发多线程并行而不是Python的协程单线程并发。这意味着Go在处理CPU密集型任务比ASGI有优势。但Go的Web框架生态不如Python丰富如果你依赖ORM、管理后台、认证中间件这些现成的东西Go会让你多写不少代码。还有Java的Netty或者Spring WebFlux。它也是异步非阻塞的性能比ASGI好特别是在长时间运行的连接上内存管理比Python好太多。但Java的学习曲线比Python陡峭开发效率也低一些。对于大部分业务场景Python的ASGI在开发效率和性能之间找到了一个还不错的平衡点。最后想说一下移动端。ASGI并不是为移动端设计的但如果你用WebSocket和移动端通信ASGI的异步模型天然适合这种场景。有些团队用ASGI做后端用Flutter或React Native做客户端WebSocket是全双工的体验上很像原生应用的实时通信。# ## 谈谈Python里的中间件写Python时间长了总会遇到一些让自己纠结的设计问题。比如一个请求进来要在正式处理之前做权限校验、日志记录、性能监控这些代码如果全部塞进业务逻辑里用不了多久代码就会乱成一锅粥。这就是为什么很多人最终会接触到中间件。中间件是什么本质上中间件就是一个处理请求的管道。想象一下快递公司送货的过程包裹从收货到最终送上门会经过分拣、扫描、清关、配送站等环节。每个环节只做自己的事互不干扰。中间件就是Web框架里的这些“环节”它们串联成一个处理链每个中间件拿到请求做一些事情然后传给下一个直到抵达真正的业务处理函数。在Python的Web框架里这个模式特别常见。Django有MIDDLEWARE列表Flask有before_request和after_requestFastAPI则直接继承了Starlette的中间件机制。不管是哪个框架核心思路都差不多把横切关注点cross-cutting concerns剥离出来让业务代码干干净净。中间件能做什么有个场景很典型。公司有个老系统所有接口都返回JSON但突然有一天安全部门要求所有API都要记录请求来源IP、耗时、返回状态。如果去改每个视图函数工程量巨大还容易出错。用中间件的话写一个请求日志中间件挂上去问题就解决了。还能做很多事情。比如API限流判断单位时间内某个IP的请求次数比如CORS跨域设置在响应头里加上Allow-Origin比如统一的异常捕获把框架抛出的错误转换成统一的JSON格式还有请求参数预处理、响应数据压缩、数据库事务管理。这些都是中间件的用武之地。有个小技巧中间件还可以用来做A/B测试。根据请求携带的特定标识在中间件里切分流量把不同版本的响应返回给用户。这种需求直接在业务代码里写会让代码变得很难维护。怎么使用中间件用Django举个例子在settings.py里加上MIDDLEWARE[django.middleware.security.SecurityMiddleware,django.contrib.sessions.middleware.SessionMiddleware,django.middleware.common.CommonMiddleware,myapp.middleware.RequestLogMiddleware,]写一个自定义中间件Django支持两种写法。一种是函数式defsimple_middleware(get_response):defmiddleware(request):# 请求进来时执行的代码responseget_response(request)# 响应出去时执行的代码returnresponsereturnmiddleware另一种是类形式classRequestLogMiddleware:def__init__(self,get_response):self.get_responseget_responsedef__call__(self,request):start_timetime.time()responseself.get_response(request)durationtime.time()-start_time logger.info(f{request.path}took{duration:.2f}s)returnresponseFastAPI的中间件稍微有点不同用装饰器或者直接注册中间件类app.middleware(http)asyncdefadd_process_time_header(request:Request,call_next):start_timetime.time()responseawaitcall_next(request)process_timetime.time()-start_time response.headers[X-Process-Time]str(process_time)returnresponse一些实践经验中间件写多了会发现有几个坑特别容易踩。一个是中间件的顺序问题。比如把权限校验中间件放在静态文件中间件前面静态文件也要走一遍权限校验明显不合理。另一个是中间件里不要做耗时操作比如发HTTP请求、查数据库。中间件会被每一个请求调用如果效率低整个服务都会被拖慢。真要这么做确保加了缓存或者异步处理。还有个容易被忽略的点中间件里抛出的异常。如果中间件里出了问题又没有妥善处理框架的异常中间件可能根本捕获不到。所以最好在自定义中间件里加上全面的try-except或者确保框架的异常处理中间件排在最外层。跟其他技术比起来有同事问过中间件和装饰器有什么区别。装饰器也能做类似的事比如在每个视图函数上加login_required。问题在于装饰器得每个函数都手动加一不小心就会漏掉。中间件是全局生效的不会出现“这个接口忘了加权限校验”的情况。如果确实需要某些接口跳过中间件的处理在中间件内部判断路径就好了。还有AOP面向切面编程这是Java里的概念。Python里虽然没有原生的AOP但中间件其实就是在实现AOP的核心思想把横切逻辑剥离出来在合适的地方织入。只是Python的中间件更加简洁不需要复杂的注解和代理模式。至于WSGI中间件这是更底层的概念。比如用Flask开发的Web应用其实本身就有一层WSGI中间件。Django也类似django.core.handlers.wsgi.WSGIHandler就是最外层的WSGI应用。框架层面提供的中间件机制实际上是建立在这层之上的更高层抽象。日常开发中用框架自带的中间件机制就足够了不需要直接去操作WSGI层面。实际开发中最常见的情况是代码写到一半发现某个逻辑需要横跨多个视图。这时候停下来想想是不是可以用中间件。把它从业务代码里抽出来放到中间件里不仅代码变得整洁以后要改也方便。这个判断往往就是区分好代码和凑合能跑的代码的分界线。总的来说ASGI不是万能钥匙但它解决了Python Web生态里一个长期存在的痛点如何在一个进程里优雅地处理多种类型的连接。对于还需要处理实时数据、消息推送、WebSocket的Python Web应用来说ASGI是目前最成熟的方案了。如果你现在还在用WSGI可以考虑给自己的应用加个ASGI网关层慢慢过渡——不必一下子全改但值得尝试。