聊聊Django Channels

当Andrew Godwin在PyCon18的演讲上介绍Taking Django Async时,Channels已经进入了2.0时代,准确的说,如果按照5月份的时间算起来,Channels应该算进入2.1版本时代了。Channels的2.0时代也是伴随着Django升级至2.0之后放弃Python2的重大改变而做出了改变,带给社区了更多可以选择的异步方案。

Channels 2.0的进化

在Channels发布的时候,当时在我看完整体的大概设计之后我觉得我完全使用不到它。原因来自于几个方面:一方面是Channels早期版本的异步功能主要是服务于Websocket,而我们项目中并没有使用;第二点来自于实现方式太过于复杂,虽然带来了Background jobs功能的支持,但是这部分功能社区更多使用的还是Celery的方案(也是我们在用的),因此带来的功能并非那么吸引人,不至于让我们迁移到新的Django框架上。另外,实现上还需要依赖实现复杂的Twisted和第三方服务如Redis做layer,整体的复杂度也是十分的高,一旦出现了问题,解决起来就十分的蛋疼。不过目的也是十分明确,在Python本身的限制下,使用同步方式编写(伪)异步代码。

实际上Channels 1.x版本带来的问题还是很多的,除此之外它还选择了与社区推荐的方式不兼容的道路,导致生态无法借助更多社区的力量,于是Channels2.0版本对Channels进行了大量的重写,官方的说法是约75%左右的代码进行了重写,将异步化代码与同步化代码的处理进行了分离,简化了服务层数,代码量和复杂度也下降了不少。除了保留了与1.x版本兼容的以同步方式写异步代码以外,新加入了基于asyncio的模式。

借助Channels的赋能,你可以在不迁移大部分代码的前提下,将必要的请求迁移至异步化处理模式,而这样仅仅是需要做一部分的代码调整。

from channels.generic.http import AsyncHttpConsumer

class BasicHttpConsumer(AsyncHttpConsumer):

async def handle(self, body):

await asyncio.sleep(10)

await self.send_response(200, b"Your response bytes", headers=[

("Content-Type", "text/plain"),

])

Channels 2.0仍然存在的问题

其实在一段时间内(甚至现在),社区是反对asyncawait关键字的,一方面是asyncawait就像癌症一样会扩散,这一点在Channels的使用中就可以实现一定的妥协。另外一点是来自于显示的切换会造成额外的心智负担,尤其是在于调试和故障诊断时。相对来说,更多开发者更喜欢gevent的方案,虽然使用了monkey-patch,但是切换是隐式的,不需要自己进行管理,最多只是在遇到问题时需要关心。

而面对C-Extionsion时,asyncio是非常无力的,毕竟生态问题永远是最大的痛。比如说最最基础的mysql(如果你使用PostgreSQL,可能你更幸运一点)的支持,社区推荐使用它的forkmysqlclient,但是这个库仍旧未做太多改动,仅仅是mysql-client支持Python3和修复了一下BUG。那么就带来了一些其他问题,比如阻塞问题。Channels的解决方案是依赖于依靠asgiref.sync.sync_to_async方法,本质则是使用了concurrent.futures.ThreadPoolExecutor。虽然这样是会比直接调用sync方法稍微快了一点,但是提升确实是有限。

未来

保证在未来的使用过程中,既可以进行sync开发又能进行async开发,Channels给我们一个非常不错的可期的未来。

在不远的将来,Django将会在2.2版本(计划于2019年1月份Final)中迎来async化的ORM和View支持,虽然默认并不开启,而且大多数使用线程池模拟得来的。实际上,真正异步化的支持将会在2020年发布的3.0版本中支持,届时,整个请求处理栈将会全部异步化,并且后续开始同步支持的API进行deprecation。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181005G0GS2I00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券