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

開發Web應用程序看起來與我們10年前做的有很大的不同。現在，我們用微服務建立的一切。它徹底改變了我們的應用程序的架構。

2014年，如果你還在構建完整巨大的 web 應用程序，你需要改變這一行為，否則很快會被解雇

雖然我們的應用程序的設計發生了很大變化，但是我們的工具沒有。這里我要介紹未來我會如何編寫微服務。但是，首先，讓我們來看看我們有什么。

全局解釋鎖

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

在微服務面前，全局解釋鎖更加不是問題了。在大多數情況下，單個微服務甚至比十年前的典型web應用還小。盡管很小，它每秒也可以處理大量的請求，大多數是因為它針對查詢的類型，進行了高度的定制化和很好的調整。

而當構建的微服務需要等待其他服務回復的時間時，這開始成為一個問題。好戲由此開場。。。

 

“異步I / O，或非阻塞I/ O是輸入/輸出處理的一種形式，它允許其他進程繼續在傳輸完成之前。”- 維基百科

任何異步庫基本是從左側到右側的流程來調整代碼的：

同步（左）與異步（右）請求進程對比圖

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

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

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

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

對于多數數據庫來說，成千上萬個連接仍然是個問題。即使的典型的Sharding也無濟于事，因為對每個shard來說也是相同數目的連接。很多用戶采用了特殊的微服務（microservice）。這不僅僅是數據庫的問題，許多微服務（microservice）也同樣遇到這樣問題。

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

使用像Resque一樣的發布-訂閱

當前，許多工程團隊圍繞著發布-訂閱來構建微服務（microservices）架構。比如，他們運用RabbitMQ或者其競爭者之一的產品將所有內容發布成消息（message）。他們相信這是簡化他們的建構：

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

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

當部分工程師們以為這就是答案的時候，我認為這不適合普遍的情況。

我認為將我的設計決策限制在使用特定插件及特定的消息調度算法不會解決我的所有網絡問題。

Zeromq 和 Nanomsg 方式

另一個頗具魅力的微服務架構是Zeromq。如果你對它不熟悉，你應該盡快了解它。Zeromq只不過是巧合的使用MQ（消息隊列）作為后綴，畢竟它不像 RabbitMQ，Kafka以及其他的那樣擁有中心消息隊列。它是以socket形式工作在steroids。也就是說，它看起來就像常規的socket，確實會自動發送消息（分割TCP數據流為幀），重新連接，點對點平衡加載等等。

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

1.發布-訂閱，工作方式基本上和其他發布-訂閱應用程序相同

2.請求-回復，基本與RPC工作方式相同

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

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

1.監督者-應答者（Surveyor-respondent），允許向多點發送請求而且接收來至所有的請求

2.總線（Bus），允許向任何點發送消息

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

 

我相信更多的通信模式會出現，而使用發布-訂閱或者HTTP難逃厄運

像nanomsg和zeromq作為腳本語言的優勢是：它們在一個單獨的線程中操控I/O。所以當你使用python做一些事情操控全局解釋器鎖（GIL）時，你的zeromq線程保持你的連接，清空消息緩沖器，接收和建立連接等等。

真實世界中的微服務

當聰明的黑客們創建了像 zeromq 、 nanomsg 和發布-訂閱總線（ publish-subscribe buses ）這樣優秀的項目的時候，實干的工程師們卻仍然使用舊的技術干活。

到目前為止我還沒有看到使用 zeromq 作為數據庫存取通訊方式的數據庫。嗯，現在是有很少一些使用了 zeromq 的開源服務。基本上所有現代的數據庫在通訊方式的實現上目前分成了以下兩個陣營：

1.創建并使用自身協議

2.使用 HTTP 協議

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

HTTP協議

我不得不說一些關于HTTP的事情。

對HTTP的支持普遍存在，但是使用python會很低效。不僅是因為不能像zeromq那樣在其他線程處理事務，對HTTP解析也很緩慢。常常持久連接（keep-alive connection)也不受支持。

同時HTTP是復雜的，如果你認為不是這樣，你就錯了。來看個簡單的例子吧。你可能寫出下面的代碼：

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

理論上服務器會返回一個寫有“hello”的頁面（在wsgiref下測試），但是實際上：

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

（304響應必須不包含消息體,因此通常會被頭域后的第一個空行終止）

意思是說“hello”行會被客戶端在下次請求時識別成響應的第一行。這在一些設置中會導致緩存污染和安全漏洞。有多少使用HTTP的程序員意識到了這個現象呢？還有更多莫名其妙的細節。

 

HTTP不要在內部消息中使用，因為它容易使用但不簡單，甚至復雜到使用了5個RFC也只描述了基本內容。即使誤解最簡單的內容可能會導致安全漏洞。

說實話，大多數微服務（microservice）使用了HTTP的子集，比如只認可200的響應碼（其他的都作為失敗），不使用特別的數據頭或類似的，這可能不會出問題。當然這不是真正意義上的HTTP（但是經常用來負載均衡的代理則需要真正的HTTP，比如HAProxy），而且需要對HTTP特性非常熟悉的人才能構建安全的HTTP子集。

那么Zeromq怎么樣

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

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

2.嵌入進一些程序的效果欠佳（也就是說它沒有使用好fork）

3.對故障切換（failover）和服務發現（service discovery）整合欠佳

4.對非冪等（non-idempotent）請求和有狀態路由（stateful routing）操控欠佳

Nanomsg在(1)表現相對要好但遠未達到完美。而在當前的設計中(2)還不能解決。(3)nanoconfig庫為nanomsg解決，但卻比nanomsg本身受到了更少的關注。(4)在nanomsg中可能最終解決但現在還沒有。

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

別誤解我，zeromq很好。nanomsq從這個失誤中學到了很多，當它可用于生產環境時，它將是我用于服務間消息傳遞的第一選擇。

#p#

但是微服務怎么了？

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

另外一個問題是I/O模型。當你的代碼是單線程的，你就不能在不使用連接的情況下，依然保持連接心跳。即使你使用異步循環，它也可能因做其他運算而停頓很久。

有時你想給連接發請求，但是連接實際上已經關閉了。有種廣泛使用的方法，讀取連接數據，檢出是否可用，因為通常發送請求后很難恢復：

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

這意味著連接僅當你發送請求時才開始建立，而不是當zeromq或nanomsg中那樣只要準備好了。

而且這樣也不好做服務發現，現在你有三種簡單的選擇：

1.每次請求前檢查服務名字(如解析DNS)

2.下次連接請求時解析服務名字

3.永不更新服務(即，直到進程重啟)

大部分用戶選擇(3)。有時(2)可以直接用(work out of the box, 開箱即可用)，但是它只有機器不可達后故障切換時才會發生。(1)相當低效，幾乎不可用。

I/O內核設計

[[124086]]

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

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

I/O內核要支持多種協議，每個協議應該：(a)處理握手，(b)把流切分成消息，這樣完整的消息才會被轉發給主線程。如果可以設計連接細節，比如自動故障切換(automatic failover)的主從關系(master/slave relations)，就更好了。

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

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

先前的做法

這個思路部分存在于很多產品中：

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

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

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

也許還有更多的例子，我仍然沒有看到用單獨線程來創建統一的I/O內核的嘗試。如果你知道，告訴我。

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

意義所在

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

對。事實上，當使用多個服務來處理單個前端請求時，毫秒級的延遲累積地相當快。而且，這種技術可以在CPU使用率接近100%時，能挽救非線性增長的延遲。

還是為了保持持久連接？如果你足夠小心地經常放棄CPU，它們在傳統的異步I/O上也工作得很好。

對。如果你在用異步I/O，那你已經非常出色了，因為很多人根本沒有看到這種必要。但是服務發現需要多少異步庫才算合理？(我的回答是：一個都不需要)

但用異步I/O也能進行服務發現。

當然。但是沒人這樣做。我認為應該趁機也解決這個問題。

下面是我設想的I/O內核應該做的任務：

檢測和統計

對CPU密集型的任務來說，定期發送統計會比較困難。這個需要被修復。主線程應該遞增在某個內存區域的計數器，而完全與I/O線程無關。

而且我們獲取請求-響應計時器的精確時間戳。通常它們對python主循環的工作量評估嚴重不準。

在正確的服務發現幫助下，我們甚至可以在真正的用戶試圖在此worker上執行請求前，知道哪些必要的服務不可用。

調試

假設你可以讓Python在任何時間獲取狀態。首先，我們總會有一批在處理中的請求。而且，我們可以像統計一樣，貼上一些標記點。最后，我們可以使用類似錯誤處理器(faulthandler)所用的一種方法來找出主線程的棧。

關鍵在于，有個線程可以回應調試請求，甚至是當主線程在做CPU密集型的事情，或者因為某些原因掛起時。

管道

請求應該盡可能通過管道傳輸，即，不管哪個前端請求需要數據庫請求，我們通過一個數據庫連接發送全部。

這樣，db連接數就可以很少，而且允許我們統計哪份副本較慢。

名字發現

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

這個過程必須對應用透明，并且在應用開始請求前，連接已經存在。

統一

既然I/O內核就位，各個python的I/O框架只需要支持內核支持的協議。所有的新協議應該在內核里完成。這促使框架在方便上和效率上競爭，而不是協議的支持上。

節流(Throttling)

即使在Java和Go這些可以自由使用線程的語言里，也需要控制客戶端的連接數。該設計，不管到底哪個庫才是網絡請求的真正執行者，允許控制應用中單個位置處的請求數目。

設計隨想

下面是關于設計I/O內核的一些隨想(沒有順序)，有些可能在最終設計時會被去掉。

1.I/O內核應該是單線程的。因為不太可能用Python代碼重載用C實現的I/O線程。相比于nanomsg或者zeromq，設計選擇更加簡單。

2.所有I/O應該在使用最小互鎖(minimal interlocking)的I/O線程內完成。因為喚醒其他線程比執行python字節碼的開銷要小(這樣設計也更簡單)。

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

4.所有支持的協議至少應該可以用C切分成幀。這樣不完整的包不會到達python代碼，其他解析應該在主線程內用python對象直接完成。

5.服務發現(service discovery)應該可插拔(pluggable)。最可能的選項應該最先被實現(比如DNS名稱查詢)。

6.服務發現應該可以被簡單地集成到任何協議。事實上，對協議的實現者來說，使用服務發現比忽略它更簡單。

結束

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

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

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