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

概况与科普

总体来说过去几年根据 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 之禅教给我们的编程哲学了。