談談Python協程技術的演進

Coding Crush Python開發工程師

主要負責豈安科技業務風險情報系統redq。

引言

1.1. 存儲器山

存儲器山是 Randal Bryant 在《深刻理解計算機系統》一書中提出的概念。
基於成本、效率的考量，計算機存儲器被設計成多級金字塔結構，塔頂是速度最快、成本最高的 CPU 內部的寄存器(通常幾 KB)與高速緩存，塔底是成本最低、速度最慢的廣域網雲存儲(如百度雲免費 2T )

存儲器山的指導意義在於揭示了良好設計程序的必要條件是須要有優秀的局部性：
時間局部性：相同時間內，訪問同一地址次數越多，則時間局部性表現越佳；
空間局部性：下一次訪問的存儲器地址與上一次的訪問過的存儲器地址位置鄰近；

1.2. cpu的時間觀

咱們將一個普通的 2.6GHz 的 CPU 的延遲時間放大到人能體驗的尺度上(數據來自微信公衆號 駒說碼事)：在存儲器頂層執行單條寄存器指令的時間爲1秒鐘；從第五層磁盤讀 1MB 數據卻須要一年半；ping 不一樣的城域網主機，網絡包須要走 12.5 年。
若是程序發送了一個 HTTP 包後便阻塞在同步等待響應的過程上，計算機不得不傻等 12 年後的那個響應再處理別的事情，低下的硬件利用率必然致使低下的程序效率。

1.3. 同步編程

從以上數據能夠看出，內存數據讀寫、磁盤尋道讀寫、網卡讀寫等操做都是 I/O 操做，同步程序的瓶頸在於漫長的 I/O 等待，想要提升程序效率必須減小 I/O 等待時間，從提升程序的局部性着手。

同步編程的改進方式有多進程、多線程，但對於 c10k 問題都不是良好的解決方案，多進程的方式存在操做系統可調度進程數量上限較低，進程間上下文切換時間過長，進程間通訊較爲複雜。

而 Python 的多線程方式，因爲存在衆所周知的 GIL 鎖，性能提高並不穩定，僅能知足成百上千規模的 I/O 密集型任務，多線程還有一個缺點是由操做系統進行搶佔式調度存在競態條件，可能須要引入了鎖與隊列等保障原子性操做的工具。

1.4. 異步編程

說到異步非阻塞調用，目前的代名詞都是 epoll 與 kqueue，select/poll 因爲效率問題基本已被取代。
epoll 是04年 Linux2.6 引入內核的一種 I/O 事件通知機制，它的做用是將大量的文件描述符託管給內核，內核將最底層的 I/O 狀態變化封裝成讀寫事件，這樣就避免了由程序員去主動輪詢狀態變化的重複工做，程序員將回調函數註冊到 epoll 的狀態上，當檢測到相對應文件描述符產生狀態變化時，就進行函數回調。
事件循環是異步編程的底層基石。

上圖是簡單的EventLoop的實現原理，

用戶建立了兩個socket鏈接，將系統返回的兩個文件描述符fd三、fd4經過系統調用在epoll上註冊讀寫事件；
當網卡解析到一個tcp包時，內核根據五元組找到相應到文件描述符，自動觸發其對應的就緒事件狀態，並將該文件描述符添加到就緒鏈表中。
程序調用epoll.poll()，返回可讀寫的事件集合。
對事件集合進行輪詢，調用回調函數等
一輪事件循環結束，循環往復。

epoll 並不是銀彈，從圖中能夠觀察到，若是用戶關注的層次很低，直接操做epoll去構造維護事件的循環，從底層到高層的業務邏輯須要層層回調，形成callback hell，而且可讀性較差。因此，這個繁瑣的註冊回調與回調的過程得以封裝，並抽象成EventLoop。EventLoop屏蔽了進行epoll系統調用的具體操做。對於用戶來講，將不一樣的I/O狀態考量爲事件的觸發，只需關注更高層次下不一樣事件的回調行爲。諸如libev, libevent之類的使用C編寫的高性能異步事件庫已經取代這部分瑣碎的工做。

在Python框架裏通常會見到的這幾種事件循環：
libevent/libev: Gevent(greenlet+前期libevent，後期libev)使用的網絡庫，普遍應用；
tornado: tornado框架本身實現的IOLOOP；
picoev: meinheld(greenlet+picoev)使用的網絡庫，小巧輕量，相較於libevent在數據結構和事件檢測模型上作了改進，因此速度更快。但從github看起來已經年久失修，用的人很少。
uvloop: Python3時代的新起之秀。Guido操刀打造了asyncio庫，asyncio能夠配置可插拔的event loop，但須要知足相關的API要求，uvloop繼承自libuv，將一些低層的結構體和函數用Python對象包裝。目前Sanic框架基於這個庫

1.5. 協程

EventLoop簡化了不一樣平臺上的事件處理，可是處理事件觸發時的回調依然很麻煩，響應式的異步程序編寫對程序員的心智是一項不小的麻煩。
所以，協程被引入來替代回調以簡化問題。協程模型主要在在如下方面優於回調模型：

以近似同步代碼的編程模式取代異步回調模式，真實的業務邏輯每每是同步線性推演的，所以，這種同步式的代碼寫起來更加容易。底層的回調依然是callback hell，但這部分髒活累活已經轉交給編譯器與解釋器去完成，程序員不易出錯。
異常處理更加健全，能夠複用語言內的錯誤處理機制，回調方式。而傳統異步回調模式須要本身斷定成功失敗，錯誤處理行爲複雜化。
上下文管理簡單化，回調方式代碼上下文管理嚴重依賴閉包，不一樣的回調函數之間相互耦合，割裂了相同的上下文處理邏輯。協程直接利用代碼的執行位置來表示狀態，而回調則是維護了一堆數據結構來處理狀態。
方便處理併發行爲，協程的開銷成本很低，每個協程僅有一個輕巧的用戶態棧空間。

1.6. EventLoop與協程的發展史

04年，event-driven 的 nginx 誕生並快速傳播，06年之後從俄語區國家擴散到全球。同時期，EventLoop 變得具象化與多元化，相繼在不一樣的編程語言實現。

近十年以來，後端領域內古老的子例程與事件循環獲得結合，協程(協做式子例程)快速發展，並也革新與誕生了一些語言，好比 golang 的 goroutine，luajit 的 coroutine，Python 的 gevent,erlang 的 process，scala 的 actor 等。

就不一樣語言中面向併發設計的協程實現而言，Scala 與 Erlang 的 Actor 模型、Golang 中的 goroutine 都較 Python 更爲成熟，不一樣的協程使用通訊來共享內存，優化了競態、衝突、不一致性等問題。然而，根本的理念沒有區別，都是在用戶態經過事件循環驅動實現調度。

因爲歷史包袱較少，後端語言上的各類異步技術除 Python Twisted 外基本也沒有 callback hell 的存在。其餘的方案都已經將 callback hell 的過程進行封裝，交給庫代碼、編譯器、解釋器去解決。

有了協程，有了事件循環庫，傳統的 C10K 問題已經不是挑戰並已經上升到了 C1M 問題。

2. Gevent

Python2 時代的協程技術主要是 Gevent，另外一個 meinheld 比較小衆。Gevent 有褒有貶，負面觀點認爲它的實現不夠 Pythonic，脫離解釋器獨自實現了黑盒的調度器，monkey patch 讓不瞭解的用戶產生混淆。正面觀點認爲正是這樣才得以屏蔽全部的細節，簡化使用難度。

Gevent 基於 Greenlet 與 Libev，greenlet 是一種微線程或者協程，在調度粒度上比 PY3 的協程更大。greenlet 存在於線程容器中，其行爲相似線程，有本身獨立的棧空間，不一樣的 greenlet 的切換相似操做系統層的線程切換。

greenlet.hub 也是一個繼承於原生 greenlet 的對象，也是其餘 greenlet 的父節點，它主要負責任務調度。當一個 greenlet 協程執行完部分例程後到達斷點，經過 greenlet.switch() 向上轉交控制權給 hub 對象，hub 執行上下文切換的操做：從寄存器、高速緩存中備份當前 greenlet 的棧內容到內存中，並將原來備份的另外一個 greenlet 棧數據恢復到寄存器中。

hub 對象內封裝了一個 loop 對象，loop 負責封裝 libev 的相關操做並向上提供接口，全部 greenlet 在經過 loop 驅動的 hub 下被調度。

3. 從yield到async/await

3.1. 生成器的進化

在 Python2.2 中，第一次引入了生成器，生成器實現了一種惰性、屢次取值的方法，此時仍是經過 next 構造生成迭代鏈或 next 進行屢次取值。

直到在 Python2.5 中，yield 關鍵字被加入到語法中，這時，生成器有了記憶功能，下一次從生成器中取值能夠恢復到生成器上次 yield 執行的位置。

以前的生成器都是關於如何構造迭代器，在 Python2.5 中生成器還加入了 send 方法，與 yield 搭配使用。

咱們發現，此時，生成器不只僅能夠 yield 暫停到一個狀態，還能夠往它中止的位置經過 send 方法傳入一個值改變其狀態。
舉一個簡單的示例，主要熟悉 yield 與 send 與外界的交互流程：

def jump_range(up_to):
    step = 0
    while step < up_to:
      jump = yield step
      print("jump", jump)
      if jump is None:
          jump = 1
          step += jump
      print("step", step)

if __name__ == '__main__':
    iterator = jump_range(10)
    print(next(iterator))  # 0
    print(iterator.send(4))  # jump4; step4; 4
    print(next(iterator))  # jump None; step5; 5
    print(iterator.send(-1)) # jump -1; step4; 4

在 Python3.3 中，生成器又引入了 yield from 關鍵字，yield from 實現了在生成器內調用另外生成器的功能，能夠輕易的重構生成器，好比將多個生成器鏈接在一塊兒執行。

def gen_3():
    yield 3

def gen_234():
    yield 2
    yield from gen_3()
    yield 4

def main():
    yield 1
    yield from gen_234()
    yield 5

for element in main():
    print(element)  # 1,2,3,4,5

從圖中能夠看出 yield from 的特色。使用 itertools.chain 能夠以生成器爲最小組合子進行鏈式組合，使用 itertools.cycle 能夠對單獨一個生成器首尾相接，構造一個循環鏈。
使用 yield from 時能夠在生成器中從其餘生成器 yield 一個值，這樣不一樣的生成器之間能夠互相通訊，這樣構造出的生成鏈更加複雜，但生成鏈最小組合子的粒度卻精細至單個 yield 對象。

3.2. 短暫的asynico.coroutine 與yield from

有了Python3.3中引入的yield from 這項工具，Python3.4 中新加入了asyncio庫，並提供了一個默認的event loop。Python3.4有了足夠的基礎工具進行異步併發編程。
併發編程同時執行多條獨立的邏輯流，每一個協程都有獨立的棧空間，即便它們是都工做在同個線程中的。如下是一個示例代碼：

import asyncio
import aiohttp

@asyncio.coroutine
def fetch_page(session, url):
    response = yield from session.get(url)
    if response.status == 200:
        text = yield from response.text()
        print(text)
loop = asyncio.get_event_loop()

session = aiohttp.ClientSession(loop=loop)

tasks = [
    asyncio.ensure_future(
       fetch_page(session, "http://bigsec.com/products/redq/")),
    asyncio.ensure_future(
       fetch_page(session, "http://bigsec.com/products/warden/"))
]

loop.run_until_complete(asyncio.wait(tasks))
session.close()
loop.close()

在 Python3.4 中，asyncio.coroutine 裝飾器是用來將函數轉換爲協程的語法，這也是 Python 第一次提供的生成器協程 。只有經過該裝飾器，生成器才能實現協程接口。使用協程時，你須要使用 yield from 關鍵字將一個 asyncio.Future 對象向下傳遞給事件循環，當這個 Future 對象還未就緒時，該協程就暫時掛起以處理其餘任務。一旦 Future 對象完成，事件循環將會偵測到狀態變化，會將 Future 對象的結果經過 send 方法方法返回給生成器協程，而後生成器恢復工做。

在以上的示例代碼中，首先實例化一個 eventloop，並將其傳遞給 aiohttp.ClientSession 使用，這樣 session 就不用建立本身的事件循環。

此處顯式的建立了兩個任務，只有當 fetch_page 取得 api.bigsec.com 兩個 url 的數據並打印完成後，全部任務才能結束，而後關閉 session 與 loop，釋放鏈接資源。

當代碼運行到 response = yield from session.get(url)處，fetch_page 協程被掛起，隱式的將一個 Future 對象傳遞給事件循環，只有當 session.get() 完成後，該任務纔算完成。

session.get() 內部也是協程，其數據傳輸位於在存儲器山最慢的網絡層。當 session.get 完成時，取得了一個 response 對象，再傳遞給原來的 fetch_page 生成器協程，恢復其工做狀態。

爲了提升速度，此處 get 方法將取得 http header 與 body 分解成兩次任務，減小一次性傳輸的數據量。response.text() 便是異步請求 http body。

使用 dis 庫查看 fetch_page 協程的字節碼，GET_YIELD_FROM_ITER 是 yield from 的操做碼:

In [4]: import dis

In [5]: dis.dis(fetch_page)
  0 LOAD_FAST 0 (session)
  2 LOAD_ATTR 0 (get)
  4 LOAD_FAST 1 (url)
  6 CALL_FUNCTION 1
  8 GET_YIELD_FROM_ITER
  10 LOAD_CONST 0 (None)
  12 YIELD_FROM
  14 STORE_FAST 2 (response)

  16 LOAD_FAST 2 (response)
  18 LOAD_ATTR 1 (status)
  20 LOAD_CONST 1 (200)
  22 COMPARE_OP 2 (==)
  24 POP_JUMP_IF_FALSE 48

  26 LOAD_FAST 2 (response)
  28 LOAD_ATTR 2 (text)
  30 CALL_FUNCTION 0
  32 GET_YIELD_FROM_ITER
  34 LOAD_CONST 0 (None)
  36 YIELD_FROM
  38 STORE_FAST 3 (text)

  40 LOAD_GLOBAL 3 (print)
  42 LOAD_FAST 3 (text)
  44 CALL_FUNCTION 1
  46 POP_TOP
  >> 48 LOAD_CONST 0 (None)
  50 RETURN_VALUE

3.3. async與 await關鍵字

Python3.5 中引入了這兩個關鍵字用以取代 asyncio.coroutine 與 yield from，從語義上定義了原生協程關鍵字，避免了使用者對生成器協程與生成器的混淆。這個階段(3.0-3.4)使用 Python 的人很少，所以歷史包袱不重，能夠進行一些較大的革新。
await 的行爲相似 yield from，可是它們異步等待的對象並不一致，yield from 等待的是一個生成器對象，而await接收的是定義了__await__方法的 awaitable 對象。
在 Python 中，協程也是 awaitable 對象，collections.abc.Coroutine 對象繼承自 collections.abc.Awaitable。
所以，將上一小節的示例代碼改寫成：

import asyncio
import aiohttp

async def fetch_page(session, url):
    response = await session.get(url)
    if response.status == 200:
        text = await response.text()
        print(text)

loop = asyncio.get_event_loop()
session = aiohttp.ClientSession(loop=loop)

tasks = [
    asyncio.ensure_future(
        fetch_page(session, "http://bigsec.com/products/redq/")),
    asyncio.ensure_future(
        fetch_page(session, "http://bigsec.com/products/warden/"))
]
loop.run_until_complete(asyncio.wait(tasks))
session.close()
loop.close()

從 Python 語言發展的角度來講，async/await 並不是是多麼偉大的改進，只是引進了其餘語言中成熟的語義，協程的基石仍是在於 eventloop 庫的發展，以及生成器的完善。從結構原理而言，asyncio 實質擔當的角色是一個異步框架，async/await 是爲異步框架提供的 API，由於使用者目前並不能脫離 asyncio 或其餘異步庫使用 async/await 編寫協程代碼。即便用戶能夠避免顯式地實例化事件循環，好比支持 asyncio/await 語法的協程網絡庫 curio，可是脫離了 eventloop 如心臟般的驅動做用，async/await 關鍵字自己也毫無做用。

4. async/await的使用

4.1. Future

不用回調方法編寫異步代碼後，爲了獲取異步調用的結果，引入一個 Future 將來對象。Future 封裝了與 loop 的交互行爲，add_done_callback 方法向 epoll 註冊回調函數，當 result 屬性獲得返回值後，會運行以前註冊的回調函數，向上傳遞給 coroutine。可是，每個角色各有本身的職責，用 Future 向生成器 send result 以恢復工做狀態並不合適，Future 對象自己的生存週期比較短，每一次註冊回調、產生事件、觸發回調過程後工做已經完成。因此這裏又須要在生成器協程與 Future 對象中引入一個新的對象 Task，對生成器協程進行狀態管理。

4.2. Task

Task，顧名思義，是維護生成器協程狀態處理執行邏輯的的任務，Task 內的_step 方法負責生成器協程與 EventLoop 交互過程的狀態遷移:向協程 send 一個值，恢復其工做狀態，協程運行到斷點後，獲得新的將來對象，再處理 future 與 loop 的回調註冊過程。

4.3. Loop

事件循環的工做方式與用戶設想存在一些誤差，理所固然的認知應是每一個線程均可以有一個獨立的 loop。可是在運行中，在主線程中才能經過 asyncio.get_event_loop() 建立一個新的 loop，而在其餘線程時，使用 get_event_loop() 卻會拋錯，正確的作法應該是 asyncio.set_event_loop() 進行當前線程與 loop 的顯式綁定。因爲 loop 的運做行爲並不受 Python 代碼的控制，因此沒法穩定的將協程拓展到多線程中運行。
協程在工做時，並不瞭解是哪一個 loop 在對其調度，即便調用 asyncio.get_event_loop() 也不必定能獲取到真正運行的那個 loop。所以在各類庫代碼中，實例化對象時都必須顯式的傳遞當前的 loop 以進行綁定。

4.3. 另外一個Future

Python 裏另外一個 Future 對象是 concurrent.futures.Future，與 asyncio.Future 互不兼容，但容易產生混淆。concurrent.futures 是線程級的 Future 對象，當使用 concurrent.futures.Executor 進行多線程編程時用於在不一樣的 thread 之間傳遞結果。

4.4. 現階段asyncio生態發展的困難

因爲這兩個關鍵字在2014年發佈的Python3.5中才被引入，發展歷史較短，在Python2與Python3割裂的大環境下，生態環境的創建並不完善；
對於使用者來講，但願的邏輯是引入一個庫而後調用並獲取結果，並不關心第三方庫的內部邏輯。然而使用協程編寫異步代碼時須要處理與事件循環的交互。對於異步庫來講，其對外封裝性並不能達到同步庫那麼高。異步編程時，用戶一般只會選擇一個第三方庫來處理全部HTTP邏輯。可是不一樣的異步實現方法不一致，互不兼容，分歧阻礙了社區壯大；
異步代碼雖然快，但不能阻塞，一旦阻塞整個程序失效。使用多線程或多進程的方式將調度權交給操做系統，未免不是一種自我保護；

4.5. 一些我的見解

其實說了這麼多，我的以爲 asyncio 雖然更加優雅，卻實際使用上並非像表面看起來的那麼美好。首先，它不是特別的快(聽說比 gevent 快一倍)，卻引入了更多的複雜性，並且從錯誤信息 debug 更加困難。其次，這套解決方案並不成熟，最近 3.四、3.五、3.6 的三個版本，協程也有各類的細節變化，也變得愈來愈複雜，程序員必須隨時關注語言的變化才能同步。使人疑惑的是爲何 Python 必定要堅持用生成器來實現協程，最後又將生成器與協程進行新老劃斷，細節卻未獲得屏蔽？以目前的成熟度來看，當你寫協程代碼時，必須先去理解協程、生成器的區別，future 對象與 task 對象的職能，loop 的做用。總之，目前在生產環境中使用 asyncio 技術棧來解決問題並不穩定，這個生態還須要持久的發展才能成熟。

做爲程序員，在一門語言上深刻一樣能夠帶來知識的廣度。不一樣語言有不一樣的性格，合適的工具解決合適的問題，而以一名 Python 程序員的視角來看，大可沒必要堅持寄但願於 asyncio 解決 Python 的性能問題，把在縱向上搞懂 asyncio 和這一套協程細節所需的時間拿來橫向學習 Golang，尋求更合適更簡單的解決方案，代碼也能夠上線了。