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

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

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

全局解釋鎖

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Zeromq 和 Nanomsg 方式

另一個(gè)頗具魅力的微服務(wù)架構(gòu)是Zeromq。如果你對(duì)它不熟悉，你應(yīng)該盡快了解它。Zeromq只不過是巧合的使用MQ（消息隊(duì)列）作為后綴，畢竟它不像 RabbitMQ，Kafka以及其他的那樣擁有中心消息隊(duì)列。它是以socket形式工作在steroids。也就是說，它看起來就像常規(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)求而且接收來至所有的請(qǐng)求

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

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

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

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

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

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

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

2.使用 HTTP 協(xié)議

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

HTTP協(xié)議

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

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

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

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

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

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

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

那么Zeromq怎么樣

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

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

2.嵌入進(jìn)一些程序的效果欠佳（也就是說它沒有使用好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庫為nanomsg解決，但卻比nanomsg本身受到了更少的關(guān)注。(4)在nanomsg中可能最終解決但現(xiàn)在還沒有。

第二個(gè)大問題是工程師們還不太適應(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特別想修正工程師們頭腦中的這種想法，但這條路還很長。

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

#p#

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

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

另外一個(gè)問題是I/O模型。當(dāng)你的代碼是單線程的，你就不能在不使用連接的情況下，依然保持連接心跳。即使你使用異步循環(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í)才開始建立，而不是當(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)程重啟)

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

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

[[124086]]

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

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

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

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

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

先前的做法

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

1.上文提到的zeromq和nanomsg使用不同的線程來處理I/O

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

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

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

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

意義所在

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

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

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

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

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

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

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

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

調(diào)試

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

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

管道

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

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

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

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

這個(gè)過程必須對(duì)應(yīng)用透明，并且在應(yīng)用開始請(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這些可以自由使用線程的語言里，也需要控制客戶端的連接數(shù)。該設(shè)計(jì)，不管到底哪個(gè)庫才是網(wǎng)絡(luò)請(qǐng)求的真正執(zhí)行者，允許控制應(yīng)用中單個(gè)位置處的請(qǐng)求數(shù)目。

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

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

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

2.所有I/O應(yīng)該在使用最小互鎖(minimal interlocking)的I/O線程內(nèi)完成。因?yàn)閱拘哑渌€程比執(zhí)行python字節(jié)碼的開銷要小(這樣設(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)該在主線程內(nèi)用python對(duì)象直接完成。

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

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

結(jié)束

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

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

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