从 Tornado 到 Uvicorn, Starlette, FastAPI

date
May 4, 2021
slug
uvicorn-starlette-fastapi
status
Published
tags
Python
summary
type
Post
在 2010年的时候,我离开了net 开发环境和宇宙第一IDE Visual Studio。在这之前,我已经使用了六年的 .net,主要是开发Web 和 Web Service。
当时我就想探索一下开源软件环境下的开发,所以首先就选择了 Python。在选择 web 后端开发框架的时候,选择了 tornado。 主要原因是,他实在太轻巧了,特别是对于我这个用了各种 .net 框架的人来说。 这十多年中我始终使用 tornado 作为我的多个后端开发项目框架。对我来说,我还没有遇到有让这个框架暴露出性能瓶颈的应用。总体来看,只要能了解到应用中什么地方会产生阻塞,并有针对性的优化他,就可以很顺畅的应付一般的压力。以前我使用 supervisor 进行生产环境的进程管理,最近几年我使用自己部署的 Kubernetes 集群来做容器化部署。所以我选择框架不是因为需要他有多么高的性能,而是希望他足够的轻量级,不会在框架下隐藏太多无法理解的细节。

直到最近我开始思考有没有其他的 python web 框架。一次在 Twitter 上看到有人推荐 fastapi,当时我就被他能够提供标准接口和文档而感动到了。因为随着项目的复杂度增加,我开始在 tornado的基础上增加各种功能,其实就是在框架的基础上增加我的框架。比如为了让别人方便的看接口的文档,我在所有的接口中增加了 __doc__ 参数。在此基础上我还为每个接口做了一个可以进行测试的表单程序。
 
顺着 fastapi,我终于了解到了:
  • unicorn:一个实现 WSGI 规范的高性能服务器,使用 asyncio 底层框架来实现服务器/应用接口。
  • starlette: 在 uvicorn 基础上建立的 web 开发框架,可以看作是 tornado 的替代品。在此框架上可以涵盖 http, web socket, 路由,中间件,后台任务等几乎所有的后端开发需求。
  • 回到 FastAPI,他是一个专注于 web api 的开发框架(web 部分基于 starlette, 数据部分基于 pydantic)。
 
所以在实际应用中我该如何选择呢。正如前面所说,我选择开发框架的原则不是基于性能而是优先考虑轻便。而前面三个犹如汉堡一样的结构看着就觉得挺麻烦啊。
 
大体上,我是这样考虑的:
 
  • 如果只是要开发一个足够小的 http 服务,使用 uvicorn 就可以了,把他当成 web.py 或者 SimpleHTTPServer。
  • 如果要开发一个完整的 web 服务,那要用 starlette,实现更多 web 服务功能 (当成 tornado)。
  • 如果专注于要开发一个 web api 的话,那可以使用 FastAPI,实现标准化的接口开发。
 
在开发中可以用 uvicorn 运行服务,在生产环境用 gunicorn 进行多进程管理。但是我使用 kubernetes 部署,所以其实在 docker 中使用 uvicorn 运行进程就可以了。

© adow 2021 - 2022 | 苏ICP备16013337号-1