从 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 运行进程就可以了。