管理书籍排行榜,琅琊榜海宴小说

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷(xiāo)解決方案

Python異步IO的未來(lái)（從Web后端開(kāi)發(fā)的角度）

免責(zé)聲明：我是一個(gè)工程師，擁有10年以上的 WEB 后端開(kāi)發(fā)經(jīng)驗(yàn)，大部分職業(yè)生涯都在編寫(xiě) Python代碼。所以本文大部分文字描述可能跟軟件開(kāi)發(fā)的其他領(lǐng)域無(wú)關(guān)，同樣的，也跟使用 JVM 或 CLR 的開(kāi)發(fā)者無(wú)關(guān)，他們只是用不同的方式解決問(wèn)題。

開(kāi)發(fā)Web應(yīng)用程序看起來(lái)與我們10年前做的有很大的不同。現(xiàn)在，我們用微服務(wù)建立的一切。它徹底改變了我們的應(yīng)用程序的架構(gòu)。

2014年，如果你還在構(gòu)建完整巨大的 web 應(yīng)用程序，你需要改變這一行為，否則很快會(huì)被解雇

雖然我們的應(yīng)用程序的設(shè)計(jì)發(fā)生了很大變化，但是我們的工具沒(méi)有。這里我要介紹未來(lái)我會(huì)如何編寫(xiě)微服務(wù)。但是，首先，讓我們來(lái)看看我們有什么。

全局解釋鎖

對(duì)于聲名狼籍的Python GIL，Python的支持者說(shuō)的比較多的是其他的腳本語(yǔ)言也有（Ruby，Perl，Node.js，還有一些）。對(duì)于不好的語(yǔ)言解釋器的設(shè)計(jì)，這是圣戰(zhàn)的源頭，但這對(duì)于web應(yīng)用從來(lái)不是問(wèn)題。我們總是以來(lái)許多進(jìn)程共享一個(gè)數(shù)據(jù)庫(kù)。

在微服務(wù)面前，全局解釋鎖更加不是問(wèn)題了。在大多數(shù)情況下，單個(gè)微服務(wù)甚至比十年前的典型web應(yīng)用還小。盡管很小，它每秒也可以處理大量的請(qǐng)求，大多數(shù)是因?yàn)樗槍?duì)查詢(xún)的類(lèi)型，進(jìn)行了高度的定制化和很好的調(diào)整。

而當(dāng)構(gòu)建的微服務(wù)需要等待其他服務(wù)回復(fù)的時(shí)間時(shí)，這開(kāi)始成為一個(gè)問(wèn)題。好戲由此開(kāi)場(chǎng)。。。

“異步I / O，或非阻塞I/ O是輸入/輸出處理的一種形式，它允許其他進(jìn)程繼續(xù)在傳輸完成之前?！? 維基百科

任何異步庫(kù)基本是從左側(cè)到右側(cè)的流程來(lái)調(diào)整代碼的：

同步（左）與異步（右）請(qǐng)求進(jìn)程對(duì)比圖

Python的異步I/O支持是相當(dāng)?shù)暮?。有一堆?kù)可以做這個(gè)工作（Twisted, Tornado, Gevent, Eventlet，這里僅列舉幾個(gè)）。每個(gè)庫(kù)都支持很多協(xié)議。你可以使用MySQL, Mongo, PostgreSQL, Redis, Memcache, ElasticSearch...，幾乎每個(gè)DB，和許多其他得服務(wù)。一些奇異的協(xié)議，像SSH或者Beanstalk只在幾個(gè)庫(kù)中支持。不過(guò)這些都不是問(wèn)題，寫(xiě)另一個(gè)協(xié)議或從一個(gè)I/O框架移植到另一個(gè)也不是很難。

當(dāng)然，每一個(gè)I/O庫(kù)都支持客戶(hù)端和服務(wù)端HTTP。想必，這就是為什么HTTP是最常見(jiàn)的用于微服務(wù)之間通信的協(xié)議。不過(guò)大多數(shù)框架也支持各種其他協(xié)議（msgpack-rpc, thrift, zeromq, ice，這里僅列舉幾個(gè)）。

有很多框架存在，彼此在不同協(xié)議的使用便捷性和其他種類(lèi)的并發(fā)抽象上的有所不同。當(dāng)然對(duì)不同協(xié)議的支持已經(jīng)變得越來(lái)越流行。直到Twisted在2002年發(fā)布，這種狀況才有所改變。是的，即使當(dāng)python支持了yield和stackless及greenlets出現(xiàn)，便捷性確實(shí)大大增加了，但是這也僅僅是增加一點(diǎn)點(diǎn)的便捷性。真正的改變是在2002年。

但是有些事情是大多數(shù)Python框架的弱項(xiàng)。當(dāng)你在一個(gè)線(xiàn)程中操控很多個(gè)客戶(hù)端的請(qǐng)求時(shí)，你有可能把它們管道進(jìn)單個(gè)連接中。也就是說(shuō)，如果你在前端有三個(gè)GET請(qǐng)求，你可能向MySQL數(shù)據(jù)庫(kù)發(fā)送三次請(qǐng)求，但不等待回復(fù)。一旦收到（數(shù)據(jù)庫(kù)）的數(shù)據(jù)就盡快回復(fù)客戶(hù)端。就像上面圖中表示的，但是使用了單個(gè)DB連接。大多數(shù)python框架現(xiàn)在，在請(qǐng)求開(kāi)始時(shí)從連接池中拉取一個(gè)連接，在請(qǐng)求結(jié)束時(shí)釋放連接，這樣高效的保證連接數(shù)目與同時(shí)請(qǐng)求數(shù)目相等。

對(duì)于多數(shù)數(shù)據(jù)庫(kù)來(lái)說(shuō)，成千上萬(wàn)個(gè)連接仍然是個(gè)問(wèn)題。即使的典型的Sharding也無(wú)濟(jì)于事，因?yàn)閷?duì)每個(gè)shard來(lái)說(shuō)也是相同數(shù)目的連接。很多用戶(hù)采用了特殊的微服務(wù)（microservice）。這不僅僅是數(shù)據(jù)庫(kù)的問(wèn)題，許多微服務(wù)（microservice）也同樣遇到這樣問(wèn)題。

幸好asyncio架構(gòu)允許更容易的構(gòu)建流水線(xiàn)（pipelining），所以越來(lái)越多的asyncio協(xié)議采用這種技術(shù)。不幸的是連接代價(jià)巨大的數(shù)據(jù)庫(kù)（比如MySQL和PostgreSQL）使用了不支持（該技術(shù)）的C庫(kù)，而且沒(méi)有人有足夠的重視來(lái)寫(xiě)一個(gè)更好的。

使用像Resque一樣的發(fā)布-訂閱

當(dāng)前，許多工程團(tuán)隊(duì)圍繞著發(fā)布-訂閱來(lái)構(gòu)建微服務(wù)（microservices）架構(gòu)。比如，他們運(yùn)用RabbitMQ或者其競(jìng)爭(zhēng)者之一的產(chǎn)品將所有內(nèi)容發(fā)布成消息（message）。他們相信這是簡(jiǎn)化他們的建構(gòu)：

1.單總線(xiàn)（Single Bus），無(wú)須再考慮這個(gè)

2.能夠無(wú)需等待回復(fù)即可發(fā)布消息。不需要任何異步庫(kù)即可高效的獲取異步I/O

當(dāng)部分工程師們以為這就是答案的時(shí)候，我認(rèn)為這不適合普遍的情況。

我認(rèn)為將我的設(shè)計(jì)決策限制在使用特定插件及特定的消息調(diào)度算法不會(huì)解決我的所有網(wǎng)絡(luò)問(wèn)題。

Zeromq 和 Nanomsg 方式

另一個(gè)頗具魅力的微服務(wù)架構(gòu)是Zeromq。如果你對(duì)它不熟悉，你應(yīng)該盡快了解它。Zeromq只不過(guò)是巧合的使用MQ（消息隊(duì)列）作為后綴，畢竟它不像 RabbitMQ，Kafka以及其他的那樣擁有中心消息隊(duì)列。它是以socket形式工作在steroids。也就是說(shuō)，它看起來(lái)就像常規(guī)的socket，確實(shí)會(huì)自動(dòng)發(fā)送消息（分割TCP數(shù)據(jù)流為幀），重新連接，點(diǎn)對(duì)點(diǎn)平衡加載等等。

在 Zeromq 世界里有三種方式供你的服務(wù)于其他連接：

1.發(fā)布-訂閱，工作方式基本上和其他發(fā)布-訂閱應(yīng)用程序相同

2.請(qǐng)求-回復(fù)，基本與RPC工作方式相同

3.Push-Pull，請(qǐng)求卻不需要回復(fù)，或者發(fā)布-訂閱發(fā)送消息到單一接收端（基于輪叫）

Nanomsg 做到了更多事情，它不僅支持上面提到的所有方式，而且增加了更多的通信模式（單就nanomsg而言）：

1.監(jiān)督者-應(yīng)答者（Surveyor-respondent），允許向多點(diǎn)發(fā)送請(qǐng)求而且接收來(lái)至所有的請(qǐng)求

2.總線(xiàn)（Bus），允許向任何點(diǎn)發(fā)送消息

更多的是：nanomsg的前景在于通信模式是插件式的，也就是說(shuō)，在未來(lái)更多的通信模式會(huì)被增加到庫(kù)中。

我相信更多的通信模式會(huì)出現(xiàn)，而使用發(fā)布-訂閱或者HTTP難逃厄運(yùn)

像nanomsg和zeromq作為腳本語(yǔ)言的優(yōu)勢(shì)是：它們?cè)谝粋€(gè)單獨(dú)的線(xiàn)程中操控I/O。所以當(dāng)你使用python做一些事情操控全局解釋器鎖（GIL）時(shí)，你的zeromq線(xiàn)程保持你的連接，清空消息緩沖器，接收和建立連接等等。

真實(shí)世界中的微服務(wù)

當(dāng)聰明的黑客們創(chuàng)建了像 zeromq 、 nanomsg 和發(fā)布-訂閱總線(xiàn)（ publish-subscribe buses ）這樣優(yōu)秀的項(xiàng)目的時(shí)候，實(shí)干的工程師們卻仍然使用舊的技術(shù)干活。

到目前為止我還沒(méi)有看到使用 zeromq 作為數(shù)據(jù)庫(kù)存取通訊方式的數(shù)據(jù)庫(kù)。嗯，現(xiàn)在是有很少一些使用了 zeromq 的開(kāi)源服務(wù)?；旧纤鞋F(xiàn)代的數(shù)據(jù)庫(kù)在通訊方式的實(shí)現(xiàn)上目前分成了以下兩個(gè)陣營(yíng)：

1.創(chuàng)建并使用自身協(xié)議

2.使用 HTTP 協(xié)議

在這個(gè)方面數(shù)據(jù)庫(kù)算是個(gè)比較突出的例子。另外的例子比如 Docker ， Docker 使用了基于 unix sockets 的 HTTP 協(xié)議作為其通訊協(xié)議，然而，當(dāng)她需要使用全雙工流（ full-duplex streams ）來(lái)替代請(qǐng)求-回應(yīng)（ request-reply ）模式的時(shí)候，就只能很不優(yōu)雅地打破了其使用的協(xié)議的語(yǔ)義（ protocol semantics ）。

HTTP協(xié)議

我不得不說(shuō)一些關(guān)于HTTP的事情。

對(duì)HTTP的支持普遍存在，但是使用python會(huì)很低效。不僅是因?yàn)椴荒芟駔eromq那樣在其他線(xiàn)程處理事務(wù)，對(duì)HTTP解析也很緩慢。常常持久連接（keep-alive connection)也不受支持。

同時(shí)HTTP是復(fù)雜的，如果你認(rèn)為不是這樣，你就錯(cuò)了。來(lái)看個(gè)簡(jiǎn)單的例子吧。你可能寫(xiě)出下面的代碼：

 
 
  
  def simple_app(environ, start_response):
  
      status = '304 Not Modified'
  
      headers = [('Content-Length', '5')]
  
      start_response(status, headers)
  
      return [b'hello']

理論上服務(wù)器會(huì)返回一個(gè)寫(xiě)有“hello”的頁(yè)面（在wsgiref下測(cè)試），但是實(shí)際上：

The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields

（304響應(yīng)必須不包含消息體,因此通常會(huì)被頭域后的第一個(gè)空行終止）

意思是說(shuō)“hello”行會(huì)被客戶(hù)端在下次請(qǐng)求時(shí)識(shí)別成響應(yīng)的第一行。這在一些設(shè)置中會(huì)導(dǎo)致緩存污染和安全漏洞。有多少使用HTTP的程序員意識(shí)到了這個(gè)現(xiàn)象呢？還有更多莫名其妙的細(xì)節(jié)。

HTTP不要在內(nèi)部消息中使用，因?yàn)樗菀资褂玫缓?jiǎn)單，甚至復(fù)雜到使用了5個(gè)RFC也只描述了基本內(nèi)容。即使誤解最簡(jiǎn)單的內(nèi)容可能會(huì)導(dǎo)致安全漏洞。

說(shuō)實(shí)話(huà)，大多數(shù)微服務(wù)（microservice）使用了HTTP的子集，比如只認(rèn)可200的響應(yīng)碼（其他的都作為失敗），不使用特別的數(shù)據(jù)頭或類(lèi)似的，這可能不會(huì)出問(wèn)題。當(dāng)然這不是真正意義上的HTTP（但是經(jīng)常用來(lái)負(fù)載均衡的代理則需要真正的HTTP，比如HAProxy），而且需要對(duì)HTTP特性非常熟悉的人才能構(gòu)建安全的HTTP子集。

那么Zeromq怎么樣

首先，它不是那種多功能的軟件：

1.它很難拓展（hack on）（使用了復(fù)雜的C++ Actor模型）

2.嵌入進(jìn)一些程序的效果欠佳（也就是說(shuō)它沒(méi)有使用好fork）

3.對(duì)故障切換（failover）和服務(wù)發(fā)現(xiàn)（service discovery）整合欠佳

4.對(duì)非冪等（non-idempotent）請(qǐng)求和有狀態(tài)路由（stateful routing）操控欠佳

Nanomsg在(1)表現(xiàn)相對(duì)要好但遠(yuǎn)未達(dá)到完美。而在當(dāng)前的設(shè)計(jì)中(2)還不能解決。(3)nanoconfig庫(kù)為nanomsg解決，但卻比nanomsg本身受到了更少的關(guān)注。(4)在nanomsg中可能最終解決但現(xiàn)在還沒(méi)有。

第二個(gè)大問(wèn)題是工程師們還不太適應(yīng)它的思考方式，例如對(duì)同樣的連接，redis協(xié)議使用發(fā)布-訂閱(pub-sub)和請(qǐng)求-響應(yīng)(req-rep)，mongo使用push-pull和請(qǐng)求-響應(yīng)(req-rep)，而zeromq不允許。nonomsq特別想修正工程師們頭腦中的這種想法，但這條路還很長(zhǎng)。

別誤解我，zeromq很好。nanomsq從這個(gè)失誤中學(xué)到了很多，當(dāng)它可用于生產(chǎn)環(huán)境時(shí)，它將是我用于服務(wù)間消息傳遞的第一選擇。

#p#

但是微服務(wù)怎么了？

好吧，最簡(jiǎn)單的原因是，僅僅使用zeromq你甚至不能構(gòu)建一個(gè)很小的服務(wù)。但是如果你的DB支持HTTP，你就可以使用HTTP在客戶(hù)端和服務(wù)端兩端構(gòu)建服務(wù)。聽(tīng)起來(lái)很簡(jiǎn)單(但是記住HTTP很復(fù)雜)。

另外一個(gè)問(wèn)題是I/O模型。當(dāng)你的代碼是單線(xiàn)程的，你就不能在不使用連接的情況下，依然保持連接心跳。即使你使用異步循環(huán)，它也可能因做其他運(yùn)算而停頓很久。

有時(shí)你想給連接發(fā)請(qǐng)求，但是連接實(shí)際上已經(jīng)關(guān)閉了。有種廣泛使用的方法，讀取連接數(shù)據(jù)，檢出是否可用，因?yàn)橥ǔ０l(fā)送請(qǐng)求后很難恢復(fù)：

 
 
  
  if s.read() == b'':
  
    self.reconnect()
  
  s.write(request)
  
  response = s.read()

這意味著連接僅當(dāng)你發(fā)送請(qǐng)求時(shí)才開(kāi)始建立，而不是當(dāng)zeromq或nanomsg中那樣只要準(zhǔn)備好了。

而且這樣也不好做服務(wù)發(fā)現(xiàn)，現(xiàn)在你有三種簡(jiǎn)單的選擇：

1.每次請(qǐng)求前檢查服務(wù)名字(如解析DNS)

2.下次連接請(qǐng)求時(shí)解析服務(wù)名字

3.永不更新服務(wù)(即，直到進(jìn)程重啟)

大部分用戶(hù)選擇(3)。有時(shí)(2)可以直接用(work out of the box, 開(kāi)箱即可用)，但是它只有機(jī)器不可達(dá)后故障切換時(shí)才會(huì)發(fā)生。(1)相當(dāng)?shù)托?，幾乎不可用?/p>

I/O內(nèi)核設(shè)計(jì)

(I/O內(nèi)核線(xiàn)程與Python線(xiàn)程使用RPC交互)

所以，我建議重新設(shè)計(jì)所有IO子系統(tǒng)，即，用C(或其他無(wú)GIL的語(yǔ)言)寫(xiě)個(gè)庫(kù)來(lái)處理IO，這樣IO與程序主線(xiàn)程無(wú)關(guān)了。它應(yīng)該與python主線(xiàn)程使用類(lèi)似消息(messaging)的機(jī)制來(lái)通信。但是，不能發(fā)送Python對(duì)象，也不要在I/O線(xiàn)程內(nèi)持有GIL。

I/O內(nèi)核要支持多種協(xié)議，每個(gè)協(xié)議應(yīng)該：(a)處理握手，(b)把流切分成消息，這樣完整的消息才會(huì)被轉(zhuǎn)發(fā)給主線(xiàn)程。如果可以設(shè)計(jì)連接細(xì)節(jié)，比如自動(dòng)故障切換(automatic failover)的主從關(guān)系(master/slave relations)，就更好了。

I/O線(xiàn)程應(yīng)該可以解析名字，處理連接請(qǐng)求，能夠訂閱DNS名字變化，以及其他的一些高級(jí)特性。

注意，這些不僅僅對(duì)python有用，也適用于其他有GIL的腳本語(yǔ)言。事實(shí)上，對(duì)無(wú)GIL的語(yǔ)言，也能很好地工作，但可能沒(méi)那個(gè)必要。

先前的做法

這個(gè)思路部分存在于很多產(chǎn)品中：

1.上文提到的zeromq和nanomsg使用不同的線(xiàn)程來(lái)處理I/O

2.Kazoo(python版的zookeeper)使用單獨(dú)的(python式的)線(xiàn)程處理重連、ping連接

3.Twisted把阻塞計(jì)算轉(zhuǎn)移到線(xiàn)程池(盡管我們需要相反的東西，這已經(jīng)算是工作量解除了)

也許還有更多的例子，我仍然沒(méi)有看到用單獨(dú)線(xiàn)程來(lái)創(chuàng)建統(tǒng)一的I/O內(nèi)核的嘗試。如果你知道，告訴我。

這種模式和最近出現(xiàn)的Ambassador模式很像。Ambassador是個(gè)進(jìn)程，存在于每臺(tái)機(jī)器，進(jìn)行服務(wù)發(fā)現(xiàn)，但是通過(guò)自身代理所有連接，即，所有服務(wù)都連接到localhost上Ambassador監(jiān)聽(tīng)的端口，然后Ambassador把連接轉(zhuǎn)發(fā)到真正的服務(wù)上去。類(lèi)似的，I/O內(nèi)核也應(yīng)該代替主線(xiàn)程進(jìn)行服務(wù)發(fā)現(xiàn)、與服務(wù)進(jìn)行通信(協(xié)議仍然與Ambassador使用的那個(gè)有很大不同)。

意義所在

難道是為了性能上能提升幾毫秒？

對(duì)。事實(shí)上，當(dāng)使用多個(gè)服務(wù)來(lái)處理單個(gè)前端請(qǐng)求時(shí)，毫秒級(jí)的延遲累積地相當(dāng)快。而且，這種技術(shù)可以在CPU使用率接近100%時(shí)，能挽救非線(xiàn)性增長(zhǎng)的延遲。

還是為了保持持久連接？如果你足夠小心地經(jīng)常放棄CPU，它們?cè)趥鹘y(tǒng)的異步I/O上也工作得很好。

對(duì)。如果你在用異步I/O，那你已經(jīng)非常出色了，因?yàn)楹芏嗳烁緵](méi)有看到這種必要。但是服務(wù)發(fā)現(xiàn)需要多少異步庫(kù)才算合理？(我的回答是：一個(gè)都不需要)

但用異步I/O也能進(jìn)行服務(wù)發(fā)現(xiàn)。

當(dāng)然。但是沒(méi)人這樣做。我認(rèn)為應(yīng)該趁機(jī)也解決這個(gè)問(wèn)題。

下面是我設(shè)想的I/O內(nèi)核應(yīng)該做的任務(wù)：

檢測(cè)和統(tǒng)計(jì)

對(duì)CPU密集型的任務(wù)來(lái)說(shuō)，定期發(fā)送統(tǒng)計(jì)會(huì)比較困難。這個(gè)需要被修復(fù)。主線(xiàn)程應(yīng)該遞增在某個(gè)內(nèi)存區(qū)域的計(jì)數(shù)器，而完全與I/O線(xiàn)程無(wú)關(guān)。

而且我們獲取請(qǐng)求-響應(yīng)計(jì)時(shí)器的精確時(shí)間戳。通常它們對(duì)python主循環(huán)的工作量評(píng)估嚴(yán)重不準(zhǔn)。

在正確的服務(wù)發(fā)現(xiàn)幫助下，我們甚至可以在真正的用戶(hù)試圖在此worker上執(zhí)行請(qǐng)求前，知道哪些必要的服務(wù)不可用。

調(diào)試

假設(shè)你可以讓Python在任何時(shí)間獲取狀態(tài)。首先，我們總會(huì)有一批在處理中的請(qǐng)求。而且，我們可以像統(tǒng)計(jì)一樣，貼上一些標(biāo)記點(diǎn)。最后，我們可以使用類(lèi)似錯(cuò)誤處理器(faulthandler)所用的一種方法來(lái)找出主線(xiàn)程的棧。

關(guān)鍵在于，有個(gè)線(xiàn)程可以回應(yīng)調(diào)試請(qǐng)求，甚至是當(dāng)主線(xiàn)程在做CPU密集型的事情，或者因?yàn)槟承┰驋炱饡r(shí)。

管道

請(qǐng)求應(yīng)該盡可能通過(guò)管道傳輸，即，不管哪個(gè)前端請(qǐng)求需要數(shù)據(jù)庫(kù)請(qǐng)求，我們通過(guò)一個(gè)數(shù)據(jù)庫(kù)連接發(fā)送全部。

這樣，db連接數(shù)就可以很少，而且允許我們統(tǒng)計(jì)哪份副本較慢。

名字發(fā)現(xiàn)

我們不僅要解析DNS名字(不管我們選擇的是什么名字解析方案)，還要當(dāng)名字變化時(shí)獲取更新，比如zookeeper中的設(shè)置watch。

這個(gè)過(guò)程必須對(duì)應(yīng)用透明，并且在應(yīng)用開(kāi)始請(qǐng)求前，連接已經(jīng)存在。

統(tǒng)一

既然I/O內(nèi)核就位，各個(gè)python的I/O框架只需要支持內(nèi)核支持的協(xié)議。所有的新協(xié)議應(yīng)該在內(nèi)核里完成。這促使框架在方便上和效率上競(jìng)爭(zhēng)，而不是協(xié)議的支持上。

節(jié)流(Throttling)

即使在Java和Go這些可以自由使用線(xiàn)程的語(yǔ)言里，也需要控制客戶(hù)端的連接數(shù)。該設(shè)計(jì)，不管到底哪個(gè)庫(kù)才是網(wǎng)絡(luò)請(qǐng)求的真正執(zhí)行者，允許控制應(yīng)用中單個(gè)位置處的請(qǐng)求數(shù)目。

設(shè)計(jì)隨想

下面是關(guān)于設(shè)計(jì)I/O內(nèi)核的一些隨想(沒(méi)有順序)，有些可能在最終設(shè)計(jì)時(shí)會(huì)被去掉。

1.I/O內(nèi)核應(yīng)該是單線(xiàn)程的。因?yàn)椴惶赡苡肞ython代碼重載用C實(shí)現(xiàn)的I/O線(xiàn)程。相比于nanomsg或者zeromq，設(shè)計(jì)選擇更加簡(jiǎn)單。

2.所有I/O應(yīng)該在使用最小互鎖(minimal interlocking)的I/O線(xiàn)程內(nèi)完成。因?yàn)閱拘哑渌€(xiàn)程比執(zhí)行python字節(jié)碼的開(kāi)銷(xiāo)要小(這樣設(shè)計(jì)也更簡(jiǎn)單)。

3.相較于持有GIL(全局解釋鎖,global interpreter lock)，從其他python對(duì)象復(fù)制數(shù)據(jù)代價(jià)更小。但是，如果可行，應(yīng)該直接分配非python的緩沖區(qū)，并直接將數(shù)據(jù)串行化進(jìn)去。

4.所有支持的協(xié)議至少應(yīng)該可以用C切分成幀。這樣不完整的包不會(huì)到達(dá)python代碼，其他解析應(yīng)該在主線(xiàn)程內(nèi)用python對(duì)象直接完成。

5.服務(wù)發(fā)現(xiàn)(service discovery)應(yīng)該可插拔(pluggable)。最可能的選項(xiàng)應(yīng)該最先被實(shí)現(xiàn)(比如DNS名稱(chēng)查詢(xún))。

6.服務(wù)發(fā)現(xiàn)應(yīng)該可以被簡(jiǎn)單地集成到任何協(xié)議。事實(shí)上，對(duì)協(xié)議的實(shí)現(xiàn)者來(lái)說(shuō)，使用服務(wù)發(fā)現(xiàn)比忽略它更簡(jiǎn)單。

結(jié)束

當(dāng)然建立這樣的工具不是一個(gè)周末就可以完成的事情。這是一份艱苦的工作，而且是無(wú)限長(zhǎng)的旅程。

直到現(xiàn)在也適合重新思考為什么我們使用Python操控網(wǎng)絡(luò)。最近的工具比如穩(wěn)定的libuv和Rust語(yǔ)言可以極大的簡(jiǎn)化建立I/O內(nèi)核。當(dāng)然可以明智的使用go-python來(lái)原型化（prototype）代碼，但這容易做但是不是長(zhǎng)久之計(jì)。

論及的方案，使用起來(lái)很簡(jiǎn)潔。期望在未來(lái)我們能使用python建立高效，高性能的服務(wù)，尤其是在動(dòng)態(tài)網(wǎng)絡(luò)配置方面，從而在性能差異明顯的問(wèn)題上不需要使用其他語(yǔ)言重寫(xiě)所有內(nèi)容。

這意味著連接僅當(dāng)你發(fā)送請(qǐng)求時(shí)才開(kāi)始建立，而不是當(dāng)zeromq或nanomsg中那樣只要準(zhǔn)備好了。
理論上服務(wù)器會(huì)返回一個(gè)寫(xiě)有“hello”的頁(yè)面（在wsgiref下測(cè)試），但是實(shí)際上：

分享標(biāo)題：Python異步IO的未來(lái)（從Web后端開(kāi)發(fā)的角度）
本文來(lái)源：http://www.fisionsoft.com.cn/article/cciiopo.html

新聞中心

其他資訊