Python 2020 年 web 框架现状、异步生态 ，以及性能测试

[LeeReamond]

概况与科普

总体来说过去几年根据 TIOBE 编程语言排行，py 一直处在高速增长期，直至 2020 年 3 月仍然如此。但语言特性层面在过去两年里基本上无甚更新。在 guido 退休之后尤其如此，归功于 py 社区松散的组织形式，不知道大家怎么看，我反正是从 19 年年会看出了点滞涨的味道。这对于熟悉 python 与社区恩怨情仇的人来说又是另一段故事，这里暂且按下不表。

大概给长期未关注的同学科普一下目前几个主要核心项目的进度，

• pypy 一直在 3.6 原地踏步，虽然加入了不少 3.7 后的新特性，但 asyncio 的 api 一直处在 3.6 的未稳定版本，不得不说是比较蛋疼的。
• asyncio 随着进入 3.8 后 api 稳定，除了留下史诗级写成书能当做搬砖砸人的文档外并没有留下太多坑。但是拜 api 变动所赐全网出现不少过期博客坑人的情况，可悲可叹。
• 胖子维护的重走 java 老路的 GIL 切除项目，意在移除全局解释锁对内核线程的控制，在 2018 年的最后更新后基本是没有了下文。可以理解，毕竟语言层面如果没有赞助基本上就是用爱发电，没有任何变现途径，不是谁都像 pypy 一样能傍上大金主。

那么到本文的重点，关于现状下 2020 年的 py 的 web 框架选择。 根据市场调查直到 2020 年 3 月 Django 和 flask 仍然占据 web 框架约 90%的市场。这不是本文的重点，鉴于 py 在对异步添加语言级支持后，其带来的无数优越特性，以及细致粒度的掌控，如果要进行新项目的技术选型需要调研的重点主要还是在这一块。最近几天逐个看了一遍，下面说一些结论

1、过去两年内曾有一些比较惊艳的“DEMO”级别框架，主打高性能，其实就是大比例地 cython 组件实现，在 github 上（骗赞），虽然 demo 表现惊艳，但大多数已经没了下文，比如 Japronto、Vibora 等等。

2、目前满足“Production ready”的异步框架，排除很多与上述同类情况的干扰后，基本只剩下 aiohttp、tornado、sanic 三大框架可用。其中 sanic 至今未声称自己已经 Production ready，虽然它在 gh 上的引用量还看得过去。

3、tornado 的 gh 项目引用数在 8 万，aiohttp 在三万两千左右，但异步接口的设计上后者很明显没有 tornado 那样积重难返。我在几年前部署别人写的 tornado 小项目时被提过非 root，不太清楚是框架还是业务作者的原因，虽然没造成什么损失但总归是由此导致的对 tornado 观感不佳。

4、有关 2020 年的 python3 web 框架性能。手边没有生产级 ecs 能用，本地 vm 简单测一下。平台 ry3700x，虚拟 8 核心，无 hyper thread。测试项目为简单的 echo 测试和 mongodb fetch 测试。 aiohttp 目前部署主要有两种方案，分别是基于原生 loop 的 pypy3、还有基于 uvloop 和 cpython 跑业务代码。在 wrk 压力测试项目中（ 16 线程 5000 并发），两者 qps 处理能力其实区别不大。单线程 handle 能力分别为 13000qps 和 11000qps，对性能测试不熟悉的朋友，如无直观概念，对标可以参考 express 的 12000。 gunicorn 部署 fork 监听，我的 vm 上分别跑到 71000 和 75000，对标可以参考 uwsgi 部署 flask，echo 性能约在 18000 左右（这个项目 mongodbfetch 不提了，flask 拉胯）。

延迟方面，pypy3 在闲时可以做到 1ms 以内，cpython 大约在 5ms 左右，压力测试平均值分别在 20ms 和 60ms。

结论部分

总的来说测试结果在意料之中，基本上性能是跟随者解释器优化在小幅前进着。生产级别服务中 py 仍然是瑞士军刀级别的存在，宝刀依旧锋利，虽然难免让人有种“到头了”的感觉。

部署方面，总体来说无论是 cpython 还是 pypy，前者需要用 C 实现高性能中间件，而后者则不像前者那样对依赖使用起来毫无顾虑，部分组件需要寻找纯 python 实现（虽然我做过的项目中还没遇到必须得自己重新发明轮子的情况）但总归心里有根刺。综合来说，两种方案的评估仍然在伯仲之间。

根据去年淘宝双 11 的后台数据，峰值 QPS 大概在 340 万左右，emmmm 我们不妨做一假设，“理论上”在阿里这种级别的公司，根据今天的测试结果，合理架构下使用 python 做后台倒也不是负载不了。。当然，虽然这只是个不切实际的梦罢了。

结论就是 Py 的 web 服务仍然保有其相较其他语言光速胶水粘合的优势，如果各位的项目团队有过提出需求后一周内上限服务的经历，应该都能体会到这种迷之爽感。对于 99.99%的项目互联网来说，发展到 3.8 版本的 py 的性能并不构成瓶颈，但同样地，开发速度也并不构成核心优势，说到底还是生态问题。虽然 py 增加 typehint 新特性后很容易就可以转换成强类型约束，合理规定团队代码规范下工程化体验已经无限接近静态类型语言，但说到底大多数项目你用 node 也是做，用 python 也是做，用 java 和 go 也是做（ go 可能不会写），两周上线也是上线，一个月上线也是上线，再慢点两个月也可以，毕竟大多数时候并没有那样的生死时速。py 现在留给我们的精神遗产，相较于业务，大概更多的是 python 之禅教给我们的编程哲学了。

[ericls]

ASGI 完全不提 还是没做 research?

[dcalsky]

fastapi 是不是因为速度太快被楼主吃掉啦？

[ipwx]

支持 up 主，1L 2L 我觉得反驳点确实成立，但是对于整篇文章的总体结论没啥区别。

[kasper4649]

去年最火的不是 fastapi 嘛

[Trim21]

异步框架部署的时候该考虑 uvicorn 了（

[ManjusakaL]

其实语言特性这两年进化还是挺多，但是我觉得 Python 目前需要不是语言特性，而是优化原有的 API 设计，乃至引入内置的 profile，监控，调试工具才是正道。。。

[ericls]

@ipwx ASGI 应该是 Python web 的一个大方向之一 它不是一个框架而是一个标准。 在讨论一个语言的 web 生态的时候 连这么重要的东西都不讨论 很明显是 research 没做够。 当然结论显而易见 Python web 的性能 就是 Python interpreter 的性能 和 event loop 的性能嘛.

[ericls]

@dcalsky fastapi 不带 server 不存在内在的性能的概念啊
就是看谁 overhead 小

[mywaiting]

单纯讨论性能，我觉得 rust 写出来的 tokio/hyper 能屠榜，包括原生 C 写出来的实现

只能说 cpython 的性能够用吧，pypy 这货再牛逼的 jit 感觉迟早到瓶颈

[Kilerd]

要不是看到你是用 3700x 测试性能，我还以为你从哪里抄了一篇几年前的文章呢。

fastapi，uvicorn，asgi 你一个都不提

[a719114136]

@Kilerd 对啊我也很还以为看漏了，标题说异步还以为是异步 web 框架的性能测试，结果一个异步的东西都没有

[ipwx]

@a719114136

aiohttp、tornado、sanic 这三个异步的被你吃了？

@ericls 用不用 asgi 对于框架使用者有区别嘛？

sanic on asgi: https://sanic.readthedocs.io/en/latest/sanic/deploying.html#running-via-asgi

反正都是用了框架然后怼而已。对于全异步而言，我不觉得用不用 uvicorn 会造成根本性的结果提升。

[ericls]

@ipwx 我没有说内容有问题 我只是说 这篇文章 看着没做够 research. 结论没有什么有价值的 takeaway.

[ipwx]

@ericls 你这么说也是。。。不过我觉得上了什么 fastapi uvicorn 之类的，也没啥值得 takeaway 的结果。Python 的网络性能嘛，也就那样。。。

[ericls]

@ipwx 如果纯网络 各个语言的性能几乎一样 都是操作系统的性能嘛 除非你搞些 hacky 的东西。

另外像我之前说过的 一个编程语言的性能应该通过对你收入的贡献来算 而不是 QPS.

抛开性能不谈，Python 的 web 生态 我觉得还是不错的 我们本地的 meetup 里面 Python web 一直是一个很热门的话题。就是这个标题有生态文章里面的东西真的完全没有描述出现在的生态的真实状态。

[ipwx]

@ericls 摊手。这么说的话我觉得 Python 成熟的框架也就剩下 Django 了。其他的都得自己狂造轮子。。。