摘要：事件循環(huán)是異步編程的底層基石。對(duì)事件集合進(jìn)行輪詢，調(diào)用回調(diào)函數(shù)等一輪事件循環(huán)結(jié)束，循環(huán)往復(fù)。協(xié)程直接利用代碼的執(zhí)行位置來表示狀態(tài)，而回調(diào)則是維護(hù)了一堆數(shù)據(jù)結(jié)構(gòu)來處理狀態(tài)。時(shí)代的協(xié)程技術(shù)主要是，另一個(gè)比較小眾。

Coding Crush   Python開發(fā)工程師
主要負(fù)責(zé)豈安科技業(yè)務(wù)風(fēng)險(xiǎn)情報(bào)系統(tǒng)redq。

存儲(chǔ)器山是 Randal Bryant 在《深入理解計(jì)算機(jī)系統(tǒng)》一書中提出的概念。
基于成本、效率的考量，計(jì)算機(jī)存儲(chǔ)器被設(shè)計(jì)成多級(jí)金字塔結(jié)構(gòu)，塔頂是速度最快、成本最高的 CPU 內(nèi)部的寄存器(一般幾 KB)與高速緩存，塔底是成本最低、速度最慢的廣域網(wǎng)云存儲(chǔ)(如百度云免費(fèi) 2T )

存儲(chǔ)器山的指導(dǎo)意義在于揭示了良好設(shè)計(jì)程序的必要條件是需要有優(yōu)秀的局部性：
時(shí)間局部性：相同時(shí)間內(nèi)，訪問同一地址次數(shù)越多，則時(shí)間局部性表現(xiàn)越佳；
空間局部性：下一次訪問的存儲(chǔ)器地址與上一次的訪問過的存儲(chǔ)器地址位置鄰近；

我們將一個(gè)普通的 2.6GHz 的 CPU 的延遲時(shí)間放大到人能體驗(yàn)的尺度上(數(shù)據(jù)來自微信公眾號(hào) 駒說碼事)：在存儲(chǔ)器頂層執(zhí)行單條寄存器指令的時(shí)間為1秒鐘；從第五層磁盤讀 1MB 數(shù)據(jù)卻需要一年半；ping 不同的城域網(wǎng)主機(jī)，網(wǎng)絡(luò)包需要走 12.5 年。
如果程序發(fā)送了一個(gè) HTTP 包后便阻塞在同步等待響應(yīng)的過程上，計(jì)算機(jī)不得不傻等 12 年后的那個(gè)響應(yīng)再處理別的事情，低下的硬件利用率必然導(dǎo)致低下的程序效率。

從以上數(shù)據(jù)可以看出，內(nèi)存數(shù)據(jù)讀寫、磁盤尋道讀寫、網(wǎng)卡讀寫等操作都是 I/O 操作，同步程序的瓶頸在于漫長(zhǎng)的 I/O 等待，想要提高程序效率必須減少 I/O 等待時(shí)間，從提高程序的局部性著手。

同步編程的改進(jìn)方式有多進(jìn)程、多線程，但對(duì)于 c10k 問題都不是良好的解決方案，多進(jìn)程的方式存在操作系統(tǒng)可調(diào)度進(jìn)程數(shù)量上限較低，進(jìn)程間上下文切換時(shí)間過長(zhǎng)，進(jìn)程間通信較為復(fù)雜。

而 Python 的多線程方式，由于存在眾所周知的 GIL 鎖，性能提升并不穩(wěn)定，僅能滿足成百上千規(guī)模的 I/O 密集型任務(wù)，多線程還有一個(gè)缺點(diǎn)是由操作系統(tǒng)進(jìn)行搶占式調(diào)度存在競(jìng)態(tài)條件，可能需要引入了鎖與隊(duì)列等保障原子性操作的工具。

說到異步非阻塞調(diào)用，目前的代名詞都是 epoll 與 kqueue，select/poll 由于效率問題基本已被取代。
epoll 是04年 Linux2.6 引入內(nèi)核的一種 I/O 事件通知機(jī)制，它的作用是將大量的文件描述符托管給內(nèi)核，內(nèi)核將最底層的 I/O 狀態(tài)變化封裝成讀寫事件，這樣就避免了由程序員去主動(dòng)輪詢狀態(tài)變化的重復(fù)工作，程序員將回調(diào)函數(shù)注冊(cè)到 epoll 的狀態(tài)上，當(dāng)檢測(cè)到相對(duì)應(yīng)文件描述符產(chǎn)生狀態(tài)變化時(shí)，就進(jìn)行函數(shù)回調(diào)。
事件循環(huán)是異步編程的底層基石。

上圖是簡(jiǎn)單的EventLoop的實(shí)現(xiàn)原理，

用戶創(chuàng)建了兩個(gè)socket連接，將系統(tǒng)返回的兩個(gè)文件描述符fd3、fd4通過系統(tǒng)調(diào)用在epoll上注冊(cè)讀寫事件；
當(dāng)網(wǎng)卡解析到一個(gè)tcp包時(shí)，內(nèi)核根據(jù)五元組找到相應(yīng)到文件描述符，自動(dòng)觸發(fā)其對(duì)應(yīng)的就緒事件狀態(tài)，并將該文件描述符添加到就緒鏈表中。
程序調(diào)用epoll.poll()，返回可讀寫的事件集合。
對(duì)事件集合進(jìn)行輪詢，調(diào)用回調(diào)函數(shù)等
一輪事件循環(huán)結(jié)束，循環(huán)往復(fù)。

epoll 并非銀彈，從圖中可以觀察到，如果用戶關(guān)注的層次很低，直接操作epoll去構(gòu)造維護(hù)事件的循環(huán)，從底層到高層的業(yè)務(wù)邏輯需要層層回調(diào)，造成callback hell，并且可讀性較差。所以，這個(gè)繁瑣的注冊(cè)回調(diào)與回調(diào)的過程得以封裝，并抽象成EventLoop。EventLoop屏蔽了進(jìn)行epoll系統(tǒng)調(diào)用的具體操作。對(duì)于用戶來說，將不同的I/O狀態(tài)考量為事件的觸發(fā)，只需關(guān)注更高層次下不同事件的回調(diào)行為。諸如libev, libevent之類的使用C編寫的高性能異步事件庫(kù)已經(jīng)取代這部分瑣碎的工作。

在Python框架里一般會(huì)見到的這幾種事件循環(huán)：
libevent/libev: Gevent(greenlet+前期libevent，后期libev)使用的網(wǎng)絡(luò)庫(kù)，廣泛應(yīng)用；
tornado: tornado框架自己實(shí)現(xiàn)的IOLOOP；
picoev: meinheld(greenlet+picoev)使用的網(wǎng)絡(luò)庫(kù)，小巧輕量，相較于libevent在數(shù)據(jù)結(jié)構(gòu)和事件檢測(cè)模型上做了改進(jìn)，所以速度更快。但從github看起來已經(jīng)年久失修，用的人不多。
uvloop: Python3時(shí)代的新起之秀。Guido操刀打造了asyncio庫(kù)，asyncio可以配置可插拔的event loop，但需要滿足相關(guān)的API要求，uvloop繼承自libuv，將一些低層的結(jié)構(gòu)體和函數(shù)用Python對(duì)象包裝。目前Sanic框架基于這個(gè)庫(kù)

EventLoop簡(jiǎn)化了不同平臺(tái)上的事件處理，但是處理事件觸發(fā)時(shí)的回調(diào)依然很麻煩，響應(yīng)式的異步程序編寫對(duì)程序員的心智是一項(xiàng)不小的麻煩。
因此，協(xié)程被引入來替代回調(diào)以簡(jiǎn)化問題。協(xié)程模型主要在在以下方面優(yōu)于回調(diào)模型：

以近似同步代碼的編程模式取代異步回調(diào)模式，真實(shí)的業(yè)務(wù)邏輯往往是同步線性推演的，因此，這種同步式的代碼寫起來更加容易。底層的回調(diào)依然是callback hell，但這部分臟活累活已經(jīng)轉(zhuǎn)交給編譯器與解釋器去完成，程序員不易出錯(cuò)。
異常處理更加健全，可以復(fù)用語(yǔ)言內(nèi)的錯(cuò)誤處理機(jī)制，回調(diào)方式。而傳統(tǒng)異步回調(diào)模式需要自己判定成功失敗，錯(cuò)誤處理行為復(fù)雜化。
上下文管理簡(jiǎn)單化，回調(diào)方式代碼上下文管理嚴(yán)重依賴閉包，不同的回調(diào)函數(shù)之間相互耦合，割裂了相同的上下文處理邏輯。協(xié)程直接利用代碼的執(zhí)行位置來表示狀態(tài)，而回調(diào)則是維護(hù)了一堆數(shù)據(jù)結(jié)構(gòu)來處理狀態(tài)。
方便處理并發(fā)行為，協(xié)程的開銷成本很低，每一個(gè)協(xié)程僅有一個(gè)輕巧的用戶態(tài)?？臻g。

04年，event-driven 的 nginx 誕生并快速傳播，06年以后從俄語(yǔ)區(qū)國(guó)家擴(kuò)散到全球。同時(shí)期，EventLoop 變得具象化與多元化，相繼在不同的編程語(yǔ)言實(shí)現(xiàn)。

近十年以來，后端領(lǐng)域內(nèi)古老的子例程與事件循環(huán)得到結(jié)合，協(xié)程(協(xié)作式子例程)快速發(fā)展，并也革新與誕生了一些語(yǔ)言，比如 golang 的 goroutine，luajit 的 coroutine，Python 的 gevent,erlang 的 process，scala 的 actor 等。

就不同語(yǔ)言中面向并發(fā)設(shè)計(jì)的協(xié)程實(shí)現(xiàn)而言，Scala 與 Erlang 的 Actor 模型、Golang 中的 goroutine 都較 Python 更為成熟，不同的協(xié)程使用通信來共享內(nèi)存，優(yōu)化了競(jìng)態(tài)、沖突、不一致性等問題。然而，根本的理念沒有區(qū)別，都是在用戶態(tài)通過事件循環(huán)驅(qū)動(dòng)實(shí)現(xiàn)調(diào)度。

由于歷史包袱較少，后端語(yǔ)言上的各種異步技術(shù)除 Python Twisted 外基本也沒有 callback hell 的存在。其他的方案都已經(jīng)將 callback hell 的過程進(jìn)行封裝，交給庫(kù)代碼、編譯器、解釋器去解決。

有了協(xié)程，有了事件循環(huán)庫(kù)，傳統(tǒng)的 C10K 問題已經(jīng)不是挑戰(zhàn)并已經(jīng)上升到了 C1M 問題。

Python2 時(shí)代的協(xié)程技術(shù)主要是 Gevent，另一個(gè) meinheld 比較小眾。Gevent 有褒有貶，負(fù)面觀點(diǎn)認(rèn)為它的實(shí)現(xiàn)不夠 Pythonic，脫離解釋器獨(dú)自實(shí)現(xiàn)了黑盒的調(diào)度器，monkey patch 讓不了解的用戶產(chǎn)生混淆。正面觀點(diǎn)認(rèn)為正是這樣才得以屏蔽所有的細(xì)節(jié)，簡(jiǎn)化使用難度。

Gevent 基于 Greenlet 與 Libev，greenlet 是一種微線程或者協(xié)程，在調(diào)度粒度上比 PY3 的協(xié)程更大。greenlet 存在于線程容器中，其行為類似線程，有自己獨(dú)立的?？臻g，不同的 greenlet 的切換類似操作系統(tǒng)層的線程切換。

greenlet.hub 也是一個(gè)繼承于原生 greenlet 的對(duì)象，也是其他 greenlet 的父節(jié)點(diǎn)，它主要負(fù)責(zé)任務(wù)調(diào)度。當(dāng)一個(gè) greenlet 協(xié)程執(zhí)行完部分例程后到達(dá)斷點(diǎn)，通過 greenlet.switch() 向上轉(zhuǎn)交控制權(quán)給 hub 對(duì)象，hub 執(zhí)行上下文切換的操作：從寄存器、高速緩存中備份當(dāng)前 greenlet 的棧內(nèi)容到內(nèi)存中，并將原來備份的另一個(gè) greenlet 棧數(shù)據(jù)恢復(fù)到寄存器中。

hub 對(duì)象內(nèi)封裝了一個(gè) loop 對(duì)象，loop 負(fù)責(zé)封裝 libev 的相關(guān)操作并向上提供接口，所有 greenlet 在通過 loop 驅(qū)動(dòng)的 hub 下被調(diào)度。

在 Python2.2 中，第一次引入了生成器，生成器實(shí)現(xiàn)了一種惰性、多次取值的方法，此時(shí)還是通過 next 構(gòu)造生成迭代鏈或 next 進(jìn)行多次取值。

直到在 Python2.5 中，yield 關(guān)鍵字被加入到語(yǔ)法中，這時(shí)，生成器有了記憶功能，下一次從生成器中取值可以恢復(fù)到生成器上次 yield 執(zhí)行的位置。

之前的生成器都是關(guān)于如何構(gòu)造迭代器，在 Python2.5 中生成器還加入了 send 方法，與 yield 搭配使用。

我們發(fā)現(xiàn)，此時(shí)，生成器不僅僅可以 yield 暫停到一個(gè)狀態(tài)，還可以往它停止的位置通過 send 方法傳入一個(gè)值改變其狀態(tài)。
舉一個(gè)簡(jiǎn)單的示例，主要熟悉 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 關(guān)鍵字，yield from 實(shí)現(xiàn)了在生成器內(nèi)調(diào)用另外生成器的功能，可以輕易的重構(gòu)生成器，比如將多個(gè)生成器連接在一起執(zhí)行。

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 的特點(diǎn)。使用 itertools.chain 可以以生成器為最小組合子進(jìn)行鏈?zhǔn)浇M合，使用 itertools.cycle 可以對(duì)多帶帶一個(gè)生成器首尾相接，構(gòu)造一個(gè)循環(huán)鏈。
使用 yield from 時(shí)可以在生成器中從其他生成器 yield 一個(gè)值，這樣不同的生成器之間可以互相通信，這樣構(gòu)造出的生成鏈更加復(fù)雜，但生成鏈最小組合子的粒度卻精細(xì)至單個(gè) yield 對(duì)象。

有了Python3.3中引入的yield from 這項(xiàng)工具，Python3.4 中新加入了asyncio庫(kù)，并提供了一個(gè)默認(rèn)的event loop。Python3.4有了足夠的基礎(chǔ)工具進(jìn)行異步并發(fā)編程。
并發(fā)編程同時(shí)執(zhí)行多條獨(dú)立的邏輯流，每個(gè)協(xié)程都有獨(dú)立的棧空間，即使它們是都工作在同個(gè)線程中的。以下是一個(gè)示例代碼：

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 裝飾器是用來將函數(shù)轉(zhuǎn)換為協(xié)程的語(yǔ)法，這也是 Python 第一次提供的生成器協(xié)程 。只有通過該裝飾器，生成器才能實(shí)現(xiàn)協(xié)程接口。使用協(xié)程時(shí)，你需要使用 yield from 關(guān)鍵字將一個(gè) asyncio.Future 對(duì)象向下傳遞給事件循環(huán)，當(dāng)這個(gè) Future 對(duì)象還未就緒時(shí)，該協(xié)程就暫時(shí)掛起以處理其他任務(wù)。一旦 Future 對(duì)象完成，事件循環(huán)將會(huì)偵測(cè)到狀態(tài)變化，會(huì)將 Future 對(duì)象的結(jié)果通過 send 方法方法返回給生成器協(xié)程，然后生成器恢復(fù)工作。

在以上的示例代碼中，首先實(shí)例化一個(gè) eventloop，并將其傳遞給 aiohttp.ClientSession 使用，這樣 session 就不用創(chuàng)建自己的事件循環(huán)。

此處顯式的創(chuàng)建了兩個(gè)任務(wù)，只有當(dāng) fetch_page 取得 api.bigsec.com 兩個(gè) url 的數(shù)據(jù)并打印完成后，所有任務(wù)才能結(jié)束，然后關(guān)閉 session 與 loop，釋放連接資源。

當(dāng)代碼運(yùn)行到 response = yield from session.get(url)處，fetch_page 協(xié)程被掛起，隱式的將一個(gè) Future 對(duì)象傳遞給事件循環(huán)，只有當(dāng) session.get() 完成后，該任務(wù)才算完成。

session.get() 內(nèi)部也是協(xié)程，其數(shù)據(jù)傳輸位于在存儲(chǔ)器山最慢的網(wǎng)絡(luò)層。當(dāng) session.get 完成時(shí)，取得了一個(gè) response 對(duì)象，再傳遞給原來的 fetch_page 生成器協(xié)程，恢復(fù)其工作狀態(tài)。

為了提高速度，此處 get 方法將取得 http header 與 body 分解成兩次任務(wù)，減少一次性傳輸?shù)臄?shù)據(jù)量。response.text() 即是異步請(qǐng)求 http body。

使用 dis 庫(kù)查看 fetch_page 協(xié)程的字節(jié)碼，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

Python3.5 中引入了這兩個(gè)關(guān)鍵字用以取代 asyncio.coroutine 與 yield from，從語(yǔ)義上定義了原生協(xié)程關(guān)鍵字，避免了使用者對(duì)生成器協(xié)程與生成器的混淆。這個(gè)階段(3.0-3.4)使用 Python 的人不多，因此歷史包袱不重，可以進(jìn)行一些較大的革新。
await 的行為類似 yield from，但是它們異步等待的對(duì)象并不一致，yield from 等待的是一個(gè)生成器對(duì)象，而await接收的是定義了__await__方法的 awaitable 對(duì)象。
在 Python 中，協(xié)程也是 awaitable 對(duì)象，collections.abc.Coroutine 對(duì)象繼承自 collections.abc.Awaitable。
因此，將上一小節(jié)的示例代碼改寫成：

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 語(yǔ)言發(fā)展的角度來說，async/await 并非是多么偉大的改進(jìn)，只是引進(jìn)了其他語(yǔ)言中成熟的語(yǔ)義，協(xié)程的基石還是在于 eventloop 庫(kù)的發(fā)展，以及生成器的完善。從結(jié)構(gòu)原理而言，asyncio 實(shí)質(zhì)擔(dān)當(dāng)?shù)慕巧且粋€(gè)異步框架，async/await 是為異步框架提供的 API，因?yàn)槭褂谜吣壳安⒉荒苊撾x asyncio 或其他異步庫(kù)使用 async/await 編寫協(xié)程代碼。即使用戶可以避免顯式地實(shí)例化事件循環(huán)，比如支持 asyncio/await 語(yǔ)法的協(xié)程網(wǎng)絡(luò)庫(kù) curio，但是脫離了 eventloop 如心臟般的驅(qū)動(dòng)作用，async/await 關(guān)鍵字本身也毫無(wú)作用。

不用回調(diào)方法編寫異步代碼后，為了獲取異步調(diào)用的結(jié)果，引入一個(gè) Future 未來對(duì)象。Future 封裝了與 loop 的交互行為，add_done_callback 方法向 epoll 注冊(cè)回調(diào)函數(shù)，當(dāng) result 屬性得到返回值后，會(huì)運(yùn)行之前注冊(cè)的回調(diào)函數(shù)，向上傳遞給 coroutine。但是，每一個(gè)角色各有自己的職責(zé)，用 Future 向生成器 send result 以恢復(fù)工作狀態(tài)并不合適，F(xiàn)uture 對(duì)象本身的生存周期比較短，每一次注冊(cè)回調(diào)、產(chǎn)生事件、觸發(fā)回調(diào)過程后工作已經(jīng)完成。所以這里又需要在生成器協(xié)程與 Future 對(duì)象中引入一個(gè)新的對(duì)象 Task，對(duì)生成器協(xié)程進(jìn)行狀態(tài)管理。

Task，顧名思義，是維護(hù)生成器協(xié)程狀態(tài)處理執(zhí)行邏輯的的任務(wù)，Task 內(nèi)的_step 方法負(fù)責(zé)生成器協(xié)程與 EventLoop 交互過程的狀態(tài)遷移:向協(xié)程 send 一個(gè)值，恢復(fù)其工作狀態(tài)，協(xié)程運(yùn)行到斷點(diǎn)后，得到新的未來對(duì)象，再處理 future 與 loop 的回調(diào)注冊(cè)過程。

事件循環(huán)的工作方式與用戶設(shè)想存在一些偏差，理所當(dāng)然的認(rèn)知應(yīng)是每個(gè)線程都可以有一個(gè)獨(dú)立的 loop。但是在運(yùn)行中，在主線程中才能通過 asyncio.get_event_loop() 創(chuàng)建一個(gè)新的 loop，而在其他線程時(shí)，使用 get_event_loop() 卻會(huì)拋錯(cuò)，正確的做法應(yīng)該是 asyncio.set_event_loop() 進(jìn)行當(dāng)前線程與 loop 的顯式綁定。由于 loop 的運(yùn)作行為并不受 Python 代碼的控制，所以無(wú)法穩(wěn)定的將協(xié)程拓展到多線程中運(yùn)行。
協(xié)程在工作時(shí)，并不了解是哪個(gè) loop 在對(duì)其調(diào)度，即使調(diào)用 asyncio.get_event_loop() 也不一定能獲取到真正運(yùn)行的那個(gè) loop。因此在各種庫(kù)代碼中，實(shí)例化對(duì)象時(shí)都必須顯式的傳遞當(dāng)前的 loop 以進(jìn)行綁定。

Python 里另一個(gè) Future 對(duì)象是 concurrent.futures.Future，與 asyncio.Future 互不兼容，但容易產(chǎn)生混淆。concurrent.futures 是線程級(jí)的 Future 對(duì)象，當(dāng)使用 concurrent.futures.Executor 進(jìn)行多線程編程時(shí)用于在不同的 thread 之間傳遞結(jié)果。

由于這兩個(gè)關(guān)鍵字在2014年發(fā)布的Python3.5中才被引入，發(fā)展歷史較短，在Python2與Python3割裂的大環(huán)境下，生態(tài)環(huán)境的建立并不完善；
對(duì)于使用者來說，希望的邏輯是引入一個(gè)庫(kù)然后調(diào)用并獲取結(jié)果，并不關(guān)心第三方庫(kù)的內(nèi)部邏輯。然而使用協(xié)程編寫異步代碼時(shí)需要處理與事件循環(huán)的交互。對(duì)于異步庫(kù)來說，其對(duì)外封裝性并不能達(dá)到同步庫(kù)那么高。異步編程時(shí)，用戶通常只會(huì)選擇一個(gè)第三方庫(kù)來處理所有HTTP邏輯。但是不同的異步實(shí)現(xiàn)方法不一致，互不兼容，分歧阻礙了社區(qū)壯大；
異步代碼雖然快，但不能阻塞，一旦阻塞整個(gè)程序失效。使用多線程或多進(jìn)程的方式將調(diào)度權(quán)交給操作系統(tǒng)，未免不是一種自我保護(hù)；

其實(shí)說了這么多，個(gè)人覺得 asyncio 雖然更加優(yōu)雅，卻實(shí)際使用上并不是像表面看起來的那么美好。首先，它不是特別的快(據(jù)說比 gevent 快一倍)，卻引入了更多的復(fù)雜性，而且從錯(cuò)誤信息 debug 更加困難。其次，這套解決方案并不成熟，最近 3.4、3.5、3.6 的三個(gè)版本，協(xié)程也有各種的細(xì)節(jié)變化，也變得越來越復(fù)雜，程序員必須隨時(shí)關(guān)注語(yǔ)言的變化才能同步。令人疑惑的是為什么 Python 一定要堅(jiān)持用生成器來實(shí)現(xiàn)協(xié)程，最后又將生成器與協(xié)程進(jìn)行新老劃斷，細(xì)節(jié)卻未得到屏蔽？以目前的成熟度來看，當(dāng)你寫協(xié)程代碼時(shí)，必須先去理解協(xié)程、生成器的區(qū)別，future 對(duì)象與 task 對(duì)象的職能，loop 的作用?？傊?，目前在生產(chǎn)環(huán)境中使用 asyncio 技術(shù)棧來解決問題并不穩(wěn)定，這個(gè)生態(tài)還需要持久的發(fā)展才能成熟。

作為程序員，在一門語(yǔ)言上深入同樣可以帶來知識(shí)的廣度。不同語(yǔ)言有不同的性格，合適的工具解決合適的問題，而以一名 Python 程序員的視角來看，大可不必堅(jiān)持寄希望于 asyncio 解決 Python 的性能問題，把在縱向上搞懂 asyncio 和這一套協(xié)程細(xì)節(jié)所需的時(shí)間拿來橫向?qū)W習(xí) Golang，尋求更合適更簡(jiǎn)單的解決方案，代碼也可以上線了。