RexKing6's Note

Python网络框架

发表于 更新于 分类于 ， 阅读次数：
18k 16 分钟

简介

综合转载于：

RESTful

什么是REST

REST全称是Representational State Transfer，中文意思是表述（编者注：通常译为表征）性状态转移。 它首次出现在2000年Roy Fielding的博士论文中，Roy Fielding是HTTP规范的主要编写者之一。 他在论文中提到：”我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。REST指的是一组架构约束条件和原则。” 如果一个架构符合REST的约束条件和原则，我们就称它为RESTful架构。

REST本身并没有创造新的技术、组件或服务，而隐藏在RESTful背后的理念就是使用Web的现有特征和能力， 更好地使用现有Web标准中的一些准则和约束。虽然REST本身受Web技术的影响很深， 但是理论上REST架构风格并不是绑定在HTTP上，只不过目前HTTP是唯一与REST相关的实例。 所以我们这里描述的REST也是通过HTTP实现的REST。

理解RESTful

要理解RESTful架构，需要理解Representational State Transfer这个词组到底是什么意思，它的每一个词都有些什么涵义。

下面我们结合REST原则，围绕资源展开讨论，从资源的定义、获取、表述、关联、状态变迁等角度，列举一些关键概念并加以解释。

  • 资源与URI
  • 统一资源接口
  • 资源的表述
  • 资源的链接
  • 状态的转移

资源与URI

REST全称是表述性状态转移，那究竟指的是什么的表述? 其实指的就是资源。任何事物，只要有被引用到的必要，它就是一个资源。资源可以是实体(例如手机号码)，也可以只是一个抽象概念(例如价值) 。下面是一些资源的例子：

  • 某用户的手机号码
  • 某用户的个人信息
  • 最多用户订购的GPRS套餐
  • 两个产品之间的依赖关系
  • 某用户可以办理的优惠套餐
  • 某手机号码的潜在价值

要让一个资源可以被识别，需要有个唯一标识，在Web中这个唯一标识就是URI(Uniform Resource Identifier)。

URI既可以看成是资源的地址，也可以看成是资源的名称。如果某些信息没有使用URI来表示，那它就不能算是一个资源， 只能算是资源的一些信息而已。URI的设计应该遵循可寻址性原则，具有自描述性，需要在形式上给人以直觉上的关联。这里以github网站为例，给出一些还算不错的URI：

下面让我们来看看URI设计上的一些技巧:

  • 使用_或-来让URI可读性更好

    曾经Web上的URI都是冰冷的数字或者无意义的字符串，但现在越来越多的网站使用_或-来分隔一些单词，让URI看上去更为人性化。 例如国内比较出名的开源中国社区，它上面的新闻地址就采用这种风格， 如http://www.oschina.net/news/38119/oschina-translate-reward-plan。

  • 使用/来表示资源的层级关系

    例如上述/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08就表示了一个多级的资源， 指的是git用户的git项目的某次提交记录，又例如/orders/2012/10可以用来表示2012年10月的订单记录。

  • 使用?用来过滤资源

    很多人只是把?简单的当做是参数的传递，很容易造成URI过于复杂、难以理解。可以把?用于对资源的过滤， 例如/git/git/pulls用来表示git项目的所有推入请求，而/pulls?state=closed用来表示git项目中已经关闭的推入请求， 这种URL通常对应的是一些特定条件的查询结果或算法运算结果。

  • ,或;可以用来表示同级资源的关系

    有时候我们需要表示同级资源的关系时，可以使用,或;来进行分割。例如哪天github可以比较某个文件在随意两次提交记录之间的差异，或许可以使用/git/git /block-sha1/sha1.h/compare/e3af72cdafab5993d18fae056f87e1d675913d08;bd63e61bdf38e872d5215c07b264dcc16e4febca作为URI。 不过，现在github是使用…来做这个事情的，例如/git/git/compare/master…next。

统一资源接口

RESTful架构应该遵循统一接口原则，统一接口包含了一组受限的预定义的操作，不论什么样的资源，都是通过使用相同的接口进行资源的访问。接口应该使用标准的HTTP方法如GET，PUT和POST，并遵循这些方法的语义。

如果按照HTTP方法的语义来暴露资源，那么接口将会拥有安全性和幂等性的特性，例如GET和HEAD请求都是安全的， 无论请求多少次，都不会改变服务器状态。而GET、HEAD、PUT和DELETE请求都是幂等的，无论对资源操作多少次， 结果总是一样的，后面的请求并不会产生比第一次更多的影响。

下面列出了GET，DELETE，PUT和POST的典型用法:

GET

  • 安全且幂等
  • 获取表示

  • 变更时获取表示（缓存）

  • 200（OK） - 表示已在响应中发出

  • 204（无内容） - 资源有空表示

  • 301（Moved Permanently） - 资源的URI已被更新
  • 303（See Other） - 其他（如，负载均衡）
  • 304（not modified）- 资源未更改（缓存）
  • 400 （bad request）- 指代坏请求（如，参数错误）
  • 404 （not found）- 资源不存在
  • 406 （not acceptable）- 服务端不支持所需表示
  • 500 （internal server error）- 通用错误响应
  • 503 （Service Unavailable）- 服务端当前无法处理请求

POST

  • 不安全且不幂等
  • 使用服务端管理的（自动产生）的实例号创建资源
  • 创建子资源
  • 部分更新资源

  • 如果没有被修改，则不过更新资源（乐观锁）

  • 200（OK）- 如果现有资源已被更改

  • 201（created）- 如果新资源被创建

  • 202（accepted）- 已接受处理请求但尚未完成（异步处理）
  • 301（Moved Permanently）- 资源的URI被更新
  • 303（See Other）- 其他（如，负载均衡）
  • 400（bad request）- 指代坏请求
  • 404 （not found）- 资源不存在
  • 406 （not acceptable）- 服务端不支持所需表示
  • 409 （conflict）- 通用冲突
  • 412 （Precondition Failed）- 前置条件失败（如执行条件更新时的冲突）
  • 415 （unsupported media type）- 接受到的表示不受支持
  • 500 （internal server error）- 通用错误响应
  • 503 （Service Unavailable）- 服务当前无法处理请求

PUT

  • 不安全但幂等
  • 用客户端管理的实例号创建一个资源
  • 通过替换的方式更新资源

  • 如果未被修改，则更新资源（乐观锁）

  • 200 （OK）- 如果已存在资源被更改

  • 201 （created）- 如果新资源被创建

  • 301（Moved Permanently）- 资源的URI已更改
  • 303 （See Other）- 其他（如，负载均衡）
  • 400 （bad request）- 指代坏请求
  • 404 （not found）- 资源不存在
  • 406 （not acceptable）- 服务端不支持所需表示
  • 409 （conflict）- 通用冲突
  • 412 （Precondition Failed）- 前置条件失败（如执行条件更新时的冲突）
  • 415 （unsupported media type）- 接受到的表示不受支持
  • 500 （internal server error）- 通用错误响应
  • 503 （Service Unavailable）- 服务当前无法处理请求

DELETE

  • 不安全但幂等

  • 删除资源

  • 200 （OK）- 资源已被删除

  • 301 （Moved Permanently）- 资源的URI已更改

  • 303 （See Other）- 其他，如负载均衡
  • 400 （bad request）- 指代坏请求
  • 404 （not found）- 资源不存在
  • 409 （conflict）- 通用冲突
  • 500 （internal server error）- 通用错误响应
  • 503 （Service Unavailable）- 服务端当前无法处理请求

下面我们来看一些实践中常见的问题:

  • POST和PUT用于创建资源时有什么区别？

    POST和PUT在创建资源的区别在于，所创建的资源的名称(URI)是否由客户端决定。 例如为我的博文增加一个java的分类，生成的路径就是分类名/categories/java，那么就可以采用PUT方法。不过很多人直接把POST、GET、PUT、DELETE直接对应上CRUD，例如在一个典型的rails实现的RESTful应用中就是这么做的。

  • 客户端不一定都支持这些HTTP方法吧？

    的确有这种情况，特别是一些比较古老的基于浏览器的客户端，只能支持GET和POST两种方法。在实践上，客户端和服务端都可能需要做一些妥协。例如rails框架就支持通过隐藏参数_method=DELETE来传递真实的请求方法， 而像Backbone这样的客户端MVC框架则允许传递_method传输和设置X-HTTP-Method-Override头来规避这个问题。

  • 统一接口是否意味着不能扩展带特殊语义的方法？

    统一接口并不阻止你扩展方法，只要方法对资源的操作有着具体的、可识别的语义即可，并能够保持整个接口的统一性。

    像WebDAV就对HTTP方法进行了扩展，增加了LOCK、UPLOCK等方法。而github的API则支持使用PATCH方法来进行issue的更新，例如:

    1
    PATCH /repos/:owner/:repo/issues/:number

    不过，需要注意的是，像PATCH这种不是HTTP标准方法的，服务端需要考虑客户端是否能够支持的问题。

  • 统一资源接口对URI有什么指导意义？

    统一资源接口要求使用标准的HTTP方法对资源进行操作，所以URI只应该来表示资源的名称，而不应该包括资源的操作。

    通俗来说，URI不应该使用动作来描述。例如，下面是一些不符合统一接口要求的URI:

    • GET /getUser/1
    • POST /createUser
    • PUT /updateUser/1
    • DELETE /deleteUser/1

    如果GET请求增加计数器，这是否违反安全性？

    安全性不代表请求不产生副作用，例如像很多API开发平台，都对请求流量做限制。像github，就会限制没有认证的请求每小时只能请求60次。但客户端不是为了追求副作用而发出这些GET或HEAD请求的，产生副作用是服务端”自作主张”的。另外，服务端在设计时，也不应该让副作用太大，因为客户端认为这些请求是不会产生副作用的。

  • 直接忽视缓存可取吗？

    即使你按各个动词的原本意图来使用它们，你仍可以轻易禁止缓存机制。 最简单的做法就是在你的HTTP响应里增加这样一个报头： Cache-control: no-cache。 但是，同时你也对失去了高效的缓存与再验证的支持(使用Etag等机制)。对于客户端来说，在为一个REST式服务实现程序客户端时，也应该充分利用现有的缓存机制，以免每次都重新获取表示。

  • 响应代码的处理有必要吗？

    HTTP的响应代码可用于应付不同场合，正确使用这些状态代码意味着客户端与服务器可以在一个具备较丰富语义的层次上进行沟通。例如，201（”Created”）响应代码表明已经创建了一个新的资源，其URI在Location响应报头里。假如你不利用HTTP状态代码丰富的应用语义，那么你将错失提高重用性、增强互操作性和提升松耦合性的机会。如果这些所谓的RESTful应用必须通过响应实体才能给出错误信息，那么SOAP就是这样的了，它就能够满足了。

资源的表述

上面提到，客户端通过HTTP方法可以获取资源，是吧? 不，确切的说，客户端获取的只是资源的表述而已。 资源在外界的具体呈现，可以有多种表述(或成为表现、表示)形式，在客户端和服务端之间传送的也是资源的表述，而不是资源本身。 例如文本资源可以采用html、xml、json等格式，图片可以使用PNG或JPG展现出来。

资源的表述包括数据和描述数据的元数据，例如，HTTP头”Content-Type” 就是这样一个元数据属性。

那么客户端如何知道服务端提供哪种表述形式呢？

答案是可以通过HTTP内容协商，客户端可以通过Accept头请求一种特定格式的表述，服务端则通过Content-Type告诉客户端资源的表述形式。以github为例，请求某组织资源的json格式的表述形式:

假如github也能够支持xml格式的表述格式，那么结果就是这样的：

下面我们来看一些实践上常见的设计:

在URI里边带上版本号

有些API在URI里边带上版本号，例如:

如果我们把版本号理解成资源的不同表述形式的话，就应该只是用一个URL，并通过Accept头部来区分，还是以github为例，它的Accept的完整格式是:application/vnd.github[.version].param[+json]

对于v3版本的话，就是Accept: application/vnd.github.v3。对于上面的例子，同理可以使用使用下面的头部:

  • Accept: vnd.example-com.foo+json; version=1.0
  • Accept: vnd.example-com.foo+json; version=1.2
  • Accept: vnd.example-com.foo+json; version=2.0

使用URI后缀来区分表述格式

像rails框架，就支持使用/users.xml或/users.json来区分不同的格式。 这样的方式对于客户端来说，无疑是更为直观，但混淆了资源的名称和资源的表述形式。 我个人认为，还是应该优先使用内容协商来区分表述格式。

如何处理不支持的表述格式

当服务器不支持所请求的表述格式，那么应该怎么办？若服务器不支持，它应该返回一个HTTP 406响应，表示拒绝处理该请求。下面以github为例，展示了一个请求XML表述资源的结果：

资源的链接

我们知道REST是使用标准的HTTP方法来操作资源的，但仅仅因此就理解成带CURD的Web数据库架构就太过于简单了。

这种反模式忽略了一个核心概念：”超媒体即应用状态引擎（hypermedia as the engine of application state）”。 超媒体是什么?

当你浏览Web网页时，从一个连接跳到一个页面，再从另一个连接跳到另外一个页面，就是利用了超媒体的概念：把一个个把资源链接起来.

要达到这个目的，就要求在表述格式里边加入链接来引导客户端。在《RESTful Web Services》一书中，作者把这种具有链接的特性成为连通性。下面我们具体来看一些例子。

下面展示的是github获取某个组织下的项目列表的请求，可以看到在响应头里边增加Link头告诉客户端怎么访问下一页和最后一页的记录。 而在响应体里边，用url来链接项目所有者和项目地址。

又例如下面这个例子，创建订单后通过链接引导客户端如何去付款。

上面的例子展示了如何使用超媒体来增强资源的连通性。很多人在设计RESTful架构时，使用很多时间来寻找漂亮的URI，而忽略了超媒体。所以，应该多花一些时间来给资源的表述提供链接，而不是专注于”资源的CRUD”。

状态的转移

有了上面的铺垫，再讨论REST里边的状态转移就会很容易理解了。不过，我们先来讨论一下REST原则中的无状态通信原则。初看一下，好像自相矛盾了，既然无状态，何来状态转移一说?

其实，这里说的无状态通信原则，并不是说客户端应用不能有状态，而是指服务端不应该保存客户端状态。

应用状态与资源状态

实际上，状态应该区分应用状态和资源状态，客户端负责维护应用状态，而服务端维护资源状态。

客户端与服务端的交互必须是无状态的，并在每一次请求中包含处理该请求所需的一切信息。

服务端不需要在请求间保留应用状态，只有在接受到实际请求的时候，服务端才会关注应用状态。

这种无状态通信原则，使得服务端和中介能够理解独立的请求和响应。

在多次请求中，同一客户端也不再需要依赖于同一服务器，方便实现高可扩展和高可用性的服务端。但有时候我们会做出违反无状态通信原则的设计，例如利用Cookie跟踪某个服务端会话状态，常见的像J2EE里边的JSESSIONID。这意味着，浏览器随各次请求发出去的Cookie是被用于构建会话状态的。

当然，如果Cookie保存的是一些服务器不依赖于会话状态即可验证的信息（比如认证令牌），这样的Cookie也是符合REST原则的。

应用状态的转移

状态转移到这里已经很好理解了， “会话”状态不是作为资源状态保存在服务端的，而是被客户端作为应用状态进行跟踪的。客户端应用状态在服务端提供的超媒体的指引下发生变迁。服务端通过超媒体告诉客户端当前状态有哪些后续状态可以进入。

这些类似”下一页”之类的链接起的就是这种推进状态的作用——指引你如何从当前状态进入下一个可能的状态。

总结

现在广东XXX版本、XXX等项目中均使用传统的RPC、SOAP方式的Web服务，而移动南方基地XXXX项目的后台， 虽然采用了JSON格式进行交互，但还是属于RPC风格的。本文从资源的定义、获取、表述、关联、状态变迁等角度， 试图快速理解RESTful架构背后的概念。RESTful架构与传统的RPC、SOAP等方式在理念上有很大的不同，希望本文能对各位理解REST有所帮助。

Python的异步编程和协程

Python 1.0 发布在 1994 年，当时对编程语言性能的要求并不像现在这么高，所以它在设计之初就更倾向于快速开发和便捷的语法。即便有性能的要求，多进程多线程也完全能够应付。但是随着现代互联网的发展，对编程语言自身的性能要求就越来越高。除了多进程和多线程模型，还逐渐演化出「协程」模型（协程，是一种用户态的更小力度的任务运行单元。基于线程，可实现多个任务的并行。）为代表的异步编程思想。

在早期，Python 实现异步编程，需要地方的库，如 Twisted、Tornado 等。从 Python3 开始，加入了对异步编程的原生支持。

  • python3.3 引入关键字yield from，用户可实现基于生成器的简易协程；
  • python3.4 引入asyncio库，正式引入协程概念，使用关键字@asyncio.coroutine和yield from来表示协程调用；
  • python3.5 引入关键字async/await代替@asyncio.coroutine和yield from，可以让我们使用同步的方式写出异步的代码；

下面这种以async def定义函数，且用await关键字来调用函数的代码，便是协程相关的代码。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
import asyncio


async def compute(x, y):
    print("Compute %s + %s ..." % (x, y))
    await asyncio.sleep(1.0)
    return x + y


async def print_sum(x, y):
    result = await compute(x, y)
    print("%s + %s = %s" % (x, y, result))


loop = asyncio.get_event_loop()
loop.run_until_complete(print_sum(1, 2))
loop.close()

协程的运行有 3 种方式，

  • aysncio.run()用来运行最高层次的main()函数；
  • await调用协程函数；
  • asyncio.create_task()并发运行作为asyncio任务的多个协程；

一些其他概念：

  • CGI（通用网关接口， Common Gateway Interface），简单来说就是解析浏览器等客户端发送给服务端的请求，并组装需要返回的 HTTP 请求的一种通用协议，处理这个过程的程序，我们就可以叫 CGI 脚本。互联网早期的动态网页都是基于 CGI 标准的。
  • WSGI 是一种 Python 专用的 Web 服务器网关接口，它分为两部分”服务器（或网关）“和”应用程序（或应用框架）”。「服务器」，一般独立于应用框架，为应用程序运行提供环境信息和一个回调函数（Callback Function）。当应用程序完成处理请求后，透过回调函数，将结果回传给服务器。常用的 WSGI 服务器有: uwsgi、gunicon。「应用程序」，是各种实现了 WSGI 标准的 Python web 框架了，常用的有 Django、Flask 等。
  • ASGI（Asynchronous Server Gateway Interface) 是 Django 团队提出的一种具有异步功能的 Python web 服务器网关接口协议。能够处理多种通用的协议类型，包括 HTTP，HTTP2 和 WebSocket。WSGI 是基于 HTTP 协议模式的，不支持 WebSocket，而 ASGI 的诞生则是为了解决 Python 常用的 WSGI 不支持当前 Web 开发中的一些新的协议标准(WebSocket、Http2 等)。同时，ASGI 向下兼容 WSGI 标准，可以通过一些方法跑 WSGI 的应用程序。常用的「服务器」有 Daphne、Uvicorn。

WSGI

Wsgi是同步通信服务规范，客户端请求一项服务，并等待服务完成，只有当它收到服务的结果时，它才会继续工作。当然了，可以定义一个超时时间，如果服务在规定的时间内没有完成，则认为调用失败，调用方继续工作。

Wsgi简单工作原理示意图：

简单实现：

1
2
3
4
5
#WSGI example 

def application(environ, start_response):
    start_response('200 OK', [('Content-Type', 'text/plain')])
    return b'Hello, Wsgi\n'

ASGI

Asgi是异步通信服务规范。客户端发起服务呼叫，但不等待结果。调用方立即继续其工作，并不关心结果。如果调用方对结果感兴趣，有一些机制可以让其随时被回调方法返回结果。

Asgi简单工作原理示意图：

1
2
3
4
5
6
#Asgi example

async def application(scope, receive, send):
    event = await receive()
    ...
    await send({"type": "websocket.send", ...})

简单总结一下：Asgi是异步的，Wsgi是同步的，而基于Wsgi的Flask是同步框架，基于Asgi的FastAPI是异步框架，就这么简单。

FastAPI

日常使用

FastApi 要求 Python 在 3.6 以上，它应用了很多 Python3 的新特性。下面我们安装一下：

1
pip install fastapi uvicorn

我们使用uvicorn来启动异步的 web server ，同时把uvicorn也安装上。

1
2
3
4
5
6
7
from fastapi import FastAPI

app = FastAPI()

@app.get("/")
async def root():
    return {"message": "Hello World"}

uvicorn 有两种启动方式：

  • 使用命令启动 uvicorn main:app --reload，生产推荐，生产中把 reload 去掉。
  • 使用 python 代码启动，python main.py，仅用于调试。
1
2
3
if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="0.0.0.0", port=8000)

整体代码看下来，和 Flask 的 Hellow world 类似，有程序实例 app 用来启动程序，有路由和路由处理函数。

接下来，让我们来看些复杂点的用法。

使用 get 方法来请求数据：

1
2
3
4
@app.get('/user')
async def user(user_id: int = Query(..., title="The ID of the user to get", gt=0)):
    # do somethings
    return {'user_id': user_id}

QueryString 的传递使用了一个类Query来做参数的校验，Query 类继承了相关 pydandic 库的类，实现了对参数的类型校验，附默认值等功能。

此处...是表示 user_id 参数时必须的。若此处为 None，则表示 user_id 可选。

使用 put 方法来更新数据：

1
2
3
4
@app.put('/user/{user_id}')
async def user(user_id: int = Path(..., title="The ID of the user to get", gt=0)):
    # do somethings
    return {'user_id': user_id}

这里的路径参数，可以使用类Path来做类型校验，功能和Query类似。

使用 post 方法来创建数据：

1
2
3
4
5
6
7
8
9
10
from pydantic import BaseModel

class User(BaseModel):
    name: str
    age: int

@app.post("/users/")
async def create_user(user: User):
    # do somethings
    return user

这里定义了一个用户类，作为函数参数的类型。在请求时，FastApi 会自动的将参数注入到该类型的各对应属性字段。该类也起到了参数类型校验的作用。在函数参数类型这块，User类有点类似 Golang 中结构体定义的函数参数类型。

使用 delete 方法来删除数据：

1
2
3
4
@app.delete('/user/{user_id}')
async def user(user_id: int = Path(..., title="The ID of the user to get", gt=0)):
    # do somethings
    return {'user_id': user_id}

同 put 方法的用法。

看了这些基本的用法之后，我们对 FastApi 的使用有了一个初步的了解。我们从之前的代码中可以看到路由和路由函数在一块的，这种方式在路由少的情况下是非常方便的，但是随着项目复杂度的提升，路由逐渐增多，如果路由设计不合理，便会非常的不好维护。针对这种情况，FastApi 提供了 APIRouter类来规划设计路由，以便适应大型的项目架构。

路由分解和版本管理

APIRouter类的基本用法如下：

1
2
3
4
5
6
7
8
# 页面路由
page_routes = APIRouter()
page_routes.include_router(views.router, prefix="")

# api 相关路由
api_routes = APIRouter()
api_routes.include_router(api_v1_views.router, prefix='/v1')
api_routes.include_router(api_v2_views.router, prefix='/v2')

可以通过它来拆分管理路由，最后再将所有路由注册到根路由即可。

1
2
3
app = FastAPI()
app.include_router(page_routes)
app.include_router(api_routes, prefix=config.API_PREFIX)

一个真实的项目实例

接下来，让我们看一个真实的生产环境中的项目案例：

img

我们从下边几点来详细说下这个项目案例：

1. ORM

首先在 ORM 选择方面，官方推荐了强大的SQLAlchemy，它可以说是 Python web 开发中最好用的第三方 ORM 了。在同步框架 Flask 中，应该说已经成为标配。

SQLAlchemy目前为止对异步的支持还不够完成，官方推荐使用 Encode 组织下的异步驱动 databases
（目前支持 PostgreSQL/MySQL/SQLite），只所以叫他驱动没叫他 ORM，是因为它仅提供了和数据库的异步链接的管理，并没有对象模型。在使用的时候，可以结合SQLAlchemy或直接写 SQL。

使用SQLAlchemy来处理同步的数据操作，使用SQLAlchemy加databases来实现异步的数据操作，完美实现了我们的需求。

2. 数据库迁移

SQLAlchemy还有一个数据库迁移的问题，它自己不支持数据库表的变更迁移，只能删除重建。在 Flask 中可以使用插件flask_migrate来实现数据库表的变更迁移。

SQLAlchemy官方推荐使用alembic。一个迁移过程大概步骤如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# 1/ 初始化环境
alembic init migrations

# 2/ 修改配置参数

# migrations/env.py
import sys
sys.path = ['', '..'] + sys.path[1:]

from core.config import DATABASE_URL
config.set_main_option("sqlalchemy.url", str(DATABASE_URL))

...
from models.posts import PostsBase
from models.posts2 import PostsBase2
target_metadata = Base.metadata  # 一个app model
target_metadata = [PostsBase.metadata, PostBase2.metadata]  # 多个app model

# 3/ 生成迁移脚本
alembic revision --autogenerate -m "init"

# 4/ 应用迁移脚本到数据库
alembic upgrade head

3. service 拆分

从项目目录可以看到有个 service 目录，很显然，当业务逻辑服务度升高时，我们可以提取很多共用的逻辑作为底层的共用逻辑。这个就比较灵活了，完全由你自己控制。各种设计模式，就可以往上怼了。

4. Docker 化

最后我们来看下 docker 化，Dockerfile 如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# 我们选择了官方 slim 镜像，体积相对小
FROM python:3.9-slim-buster

LABEL maintainer="DeanWu <pyli.xm@gmail.com>"

# stdout 无缓冲，直接输出
ENV PYTHONUNBUFFERED 1

# 复制代码，调整工作目录和脚本权限
COPY . /app

WORKDIR /app

RUN chmod +x start.sh prestart.sh start-reload.sh

# 安装用到的工具和python 包
RUN apt-get update && \
    apt-get install -y --no-install-recommends default-libmysqlclient-dev gcc libffi-dev make && \
    rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* && \
    pip install --no-cache-dir -r requirements.txt && \
    rm -rf requirements.txt && \
    pip install --no-cache-dir gunicorn

ENV PYTHONPATH=/app

EXPOSE 80

# 启动命令 可添加也可不添加
#CMD ["sh", "start.sh"]

编译和启动，

1
2
3
docker build -t fastapi-mysql:v1.0 .

docker run -p 80:80 -d -e DB_CONNECTION="mysql://root:Root1024@xxxx/fastapi" fastapi-mysql:v1.0 ./start.sh

FastAPI与Flask比较

基于Wsgi的Flask是同步框架，基于Asgi的FastAPI是异步框架，就这么简单，那么同步框架和异步框架的区别到底在哪儿？为什么要把Flask换成FastAPI?

不靠拍脑门儿、也不是道听途说、人云亦云。玩技术的应该用数据说话，论点永远依托论据，所以我们来简单对两款框架的性能做一个测试，首先分别安装依赖的库。

Flask:

1
pip install gunicornpip geventpip flask

FastAPI:

1
pip install fastapipip uvicorn

我们首先干的一件事就是，看看Flask和FastAPI如何处理来自多个客户端的多个请求。特别是当代码存在效率问题时（比如数据库查询时间长这种耗时任务），这里故意使用time.sleep()来模拟耗时任务，为什么不用asyncio呢？因为众所周知的原因：time.sleep是阻塞的。

Flask:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
from flask import Flask
from flask_restful import Resource, Api
from time import sleep

app = Flask(__name__)
api = Api(app)

class Root(Resource):
    def get(self):
        print('睡10秒')
        sleep(10)
        print('醒了')
        return {'message': 'hello'}

api.add_resource(Root, '/')

if __name__ == "__main__":
    app.run()

FastApi:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
import uvicorn
from fastapi import FastAPI
from time import sleep
app = FastAPI()

@app.get('/')
async def root():
    print('睡10秒')
    sleep(10)
    print('醒了')
    return {'message': 'hello'}

if __name__ == "__main__":
    uvicorn.run(app, host="127.0.0.1", port=8000)

分别启动服务

1
2
Flask:python3 manage.py
FastAPI:uvicorn manage:app --reload

同时一时间内，开启多个浏览器，分别并发请求首页 。

1
2
Flask:http://localhost:5000
FastAPI:http://localhost:8000

观察后台打印结果:

Flask:

FastAPI:

img

可以看到，同样的四次请求，Flask先是阻塞了40秒，然后依次返回结果，FastAPI则是第一次阻塞后直接返回，这代表了在FastAPI中阻塞了一个事件队列，证明FastAPI是异步框架，而在Flask中，请求可能是在新线程中运行的。将所有CPU绑定的任务移到单独的进程中，所以在FastAPI的例子中，只是在事件循环中sleep（所以异步框架这里最好不要使用time.sleep而是asyncio.sleep）。在FastAPI中，异步运行IO绑定的任务。

当然这不能说明太多问题，我们继续使用鼎鼎有名的ApacheBench分别对两款框架进行压测。一共设置5000个请求，QPS是100(请原谅我的机器比较渣)。

1
2
ab -n 5000 -c 100 http://127.0.0.1:5000/
ab -n 5000 -c 100 http://127.0.0.1:8000/

这里为了公平起见，Flask配合Gunicorn服务器，开3个worker，FastAPI配合Uvicorn服务器，同样开3个worker。

Flask压测结果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
liuyue:mytornado liuyue$ ab -n 5000 -c 100 http://127.0.0.1:5000/
This is ApacheBench, Version 2.3 <$Revision: 1826891 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 500 requests
Completed 1000 requests
Completed 1500 requests
Completed 2000 requests
Completed 2500 requests
Completed 3000 requests
Completed 3500 requests
Completed 4000 requests
Completed 4500 requests
Completed 5000 requests
Finished 5000 requests


Server Software:        gunicorn/20.0.4
Server Hostname:        127.0.0.1
Server Port:            5000

Document Path:          /
Document Length:        28 bytes

Concurrency Level:      100
Time taken for tests:   4.681 seconds
Complete requests:      5000
Failed requests:        0
Total transferred:      1060000 bytes
HTML transferred:       140000 bytes
Requests per second:    1068.04 [#/sec] (mean)
Time per request:       93.629 [ms] (mean)
Time per request:       0.936 [ms] (mean, across all concurrent requests)
Transfer rate:          221.12 [Kbytes/sec] received

FastAPI压测结果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
liuyue:mytornado liuyue$ ab -n 5000 -c 100 http://127.0.0.1:8000/
This is ApacheBench, Version 2.3 <$Revision: 1826891 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 500 requests
Completed 1000 requests
Completed 1500 requests
Completed 2000 requests
Completed 2500 requests
Completed 3000 requests
Completed 3500 requests
Completed 4000 requests
Completed 4500 requests
Completed 5000 requests
Finished 5000 requests


Server Software:        uvicorn
Server Hostname:        127.0.0.1
Server Port:            8000

Document Path:          /
Document Length:        19 bytes

Concurrency Level:      100
Time taken for tests:   2.060 seconds
Complete requests:      5000
Failed requests:        0
Total transferred:      720000 bytes
HTML transferred:       95000 bytes
Requests per second:    2426.78 [#/sec] (mean)
Time per request:       41.207 [ms] (mean)
Time per request:       0.412 [ms] (mean, across all concurrent requests)
Transfer rate:          341.27 [Kbytes/sec] received

显而易见，5000个总请求，Flask花费4.681秒，每秒可以处理1068.04个请求，而FastAPI花费2.060秒，每秒可以处理2426.78个请求。

相关文章
一分一毛，也是心意。