一、引言

1. 存儲器山

存儲器山是 Randal Bryant 在《深入理解計算機(jī)系統(tǒng)》一書中提出的概念。

基于成本、效率的考量，計算機(jī)存儲器被設(shè)計成多級金字塔結(jié)構(gòu)，塔頂是速度最快、成本***的 CPU 內(nèi)部的寄存器(一般幾 KB)與高速緩存，塔底是成本***、速度最慢的廣域網(wǎng)云存儲(如百度云免費(fèi) 2T )

存儲器山的指導(dǎo)意義在于揭示了良好設(shè)計程序的必要條件是需要有優(yōu)秀的局部性：

• 時間局部性：相同時間內(nèi)，訪問同一地址次數(shù)越多，則時間局部性表現(xiàn)越佳;
• 空間局部性：下一次訪問的存儲器地址與上一次的訪問過的存儲器地址位置鄰近;

2. cpu的時間觀

我們將一個普通的 2.6GHz 的 CPU 的延遲時間放大到人能體驗的尺度上(數(shù)據(jù)來自微信公眾號 駒說碼事)：在存儲器頂層執(zhí)行單條寄存器指令的時間為1秒鐘;從第五層磁盤讀 1MB 數(shù)據(jù)卻需要一年半;ping 不同的城域網(wǎng)主機(jī)，網(wǎng)絡(luò)包需要走 12.5 年。

如果程序發(fā)送了一個 HTTP 包后便阻塞在同步等待響應(yīng)的過程上，計算機(jī)不得不傻等 12 年后的那個響應(yīng)再處理別的事情，低下的硬件利用率必然導(dǎo)致低下的程序效率。

3. 同步編程

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

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

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

4. 異步編程

說到異步非阻塞調(diào)用，目前的代名詞都是 epoll 與 kqueue，select/poll 由于效率問題基本已被取代。

epoll 是04年 Linux2.6 引入內(nèi)核的一種 I/O 事件通知機(jī)制，它的作用是將大量的文件描述符托管給內(nèi)核，內(nèi)核將***層的 I/O 狀態(tài)變化封裝成讀寫事件，這樣就避免了由程序員去主動輪詢狀態(tài)變化的重復(fù)工作，程序員將回調(diào)函數(shù)注冊到 epoll 的狀態(tài)上，當(dāng)檢測到相對應(yīng)文件描述符產(chǎn)生狀態(tài)變化時，就進(jìn)行函數(shù)回調(diào)。

事件循環(huán)是異步編程的底層基石。

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

• 用戶創(chuàng)建了兩個socket連接，將系統(tǒng)返回的兩個文件描述符fd3、fd4通過系統(tǒng)調(diào)用在epoll上注冊讀寫事件;
• 當(dāng)網(wǎng)卡解析到一個tcp包時，內(nèi)核根據(jù)五元組找到相應(yīng)到文件描述符，自動觸發(fā)其對應(yīng)的就緒事件狀態(tài)，并將該文件描述符添加到就緒鏈表中。
• 程序調(diào)用epoll.poll()，返回可讀寫的事件集合。
• 對事件集合進(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，并且可讀性較差。所以，這個繁瑣的注冊回調(diào)與回調(diào)的過程得以封裝，并抽象成EventLoop。EventLoop屏蔽了進(jìn)行epoll系統(tǒng)調(diào)用的具體操作。對于用戶來說，將不同的I/O狀態(tài)考量為事件的觸發(fā)，只需關(guān)注更高層次下不同事件的回調(diào)行為。諸如libev, libevent之類的使用C編寫的高性能異步事件庫已經(jīng)取代這部分瑣碎的工作。

在Python框架里一般會見到的這幾種事件循環(huán)：

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

5. 協(xié)程

EventLoop簡化了不同平臺上的事件處理，但是處理事件觸發(fā)時的回調(diào)依然很麻煩，響應(yīng)式的異步程序編寫對程序員的心智是一項不小的麻煩。

因此，協(xié)程被引入來替代回調(diào)以簡化問題。協(xié)程模型主要在在以下方面優(yōu)于回調(diào)模型：

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

6. EventLoop與協(xié)程的發(fā)展史

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

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

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

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

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

二、Gevent

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

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

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

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

三、從yield到async/await

1. 生成器的進(jìn)化

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

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

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

我們發(fā)現(xiàn)，此時，生成器不僅僅可以 yield 暫停到一個狀態(tài)，還可以往它停止的位置通過 send 方法傳入一個值改變其狀態(tài)。

舉一個簡單的示例，主要熟悉 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 實現(xiàn)了在生成器內(nèi)調(diào)用另外生成器的功能，可以輕易的重構(gòu)生成器，比如將多個生成器連接在一起執(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 可以對單獨(dú)一個生成器首尾相接，構(gòu)造一個循環(huán)鏈。

使用 yield from 時可以在生成器中從其他生成器 yield 一個值，這樣不同的生成器之間可以互相通信，這樣構(gòu)造出的生成鏈更加復(fù)雜，但生成鏈最小組合子的粒度卻精細(xì)至單個 yield 對象。

2. 短暫的asynico.coroutine 與yield from

有了Python3.3中引入的yield from 這項工具，Python3.4 中新加入了asyncio庫，并提供了一個默認(rèn)的event loop。Python3.4有了足夠的基礎(chǔ)工具進(jìn)行異步并發(fā)編程。

并發(fā)編程同時執(zhí)行多條獨(dú)立的邏輯流，每個協(xié)程都有獨(dú)立的棧空間，即使它們是都工作在同個線程中的。以下是一個示例代碼：

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

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

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

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

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

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

使用 dis 庫查看 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 

3. async與 await關(guān)鍵字

Python3.5 中引入了這兩個關(guān)鍵字用以取代 asyncio.coroutine 與 yield from，從語義上定義了原生協(xié)程關(guān)鍵字，避免了使用者對生成器協(xié)程與生成器的混淆。這個階段(3.0-3.4)使用 Python 的人不多，因此歷史包袱不重，可以進(jìn)行一些較大的革新。

await 的行為類似 yield from，但是它們異步等待的對象并不一致，yield from 等待的是一個生成器對象，而await接收的是定義了__await__方法的 awaitable 對象。

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

四、async/await的使用

1. Future

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

2. Task

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

3. Loop

事件循環(huán)的工作方式與用戶設(shè)想存在一些偏差，理所當(dāng)然的認(rèn)知應(yīng)是每個線程都可以有一個獨(dú)立的 loop。但是在運(yùn)行中，在主線程中才能通過 asyncio.get_event_loop() 創(chuàng)建一個新的 loop，而在其他線程時，使用 get_event_loop() 卻會拋錯，正確的做法應(yīng)該是 asyncio.set_event_loop() 進(jìn)行當(dāng)前線程與 loop 的顯式綁定。由于 loop 的運(yùn)作行為并不受 Python 代碼的控制，所以無法穩(wěn)定的將協(xié)程拓展到多線程中運(yùn)行。

協(xié)程在工作時，并不了解是哪個 loop 在對其調(diào)度，即使調(diào)用 asyncio.get_event_loop() 也不一定能獲取到真正運(yùn)行的那個 loop。因此在各種庫代碼中，實例化對象時都必須顯式的傳遞當(dāng)前的 loop 以進(jìn)行綁定。

4. 另一個Future

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

5. 現(xiàn)階段asyncio生態(tài)發(fā)展的困難

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

6. 一些個人看法

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

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

【本文是51CTO專欄機(jī)構(gòu)“豈安科技”的原創(chuàng)文章，轉(zhuǎn)載請通過微信公眾號(bigsec)聯(lián)系原作者】

戳這里，看該作者更多好文