原文鏈接：http://www.aosabook.org/en/twisted.html

作者：Jessica McKellar

Twisted是用Python實現(xiàn)的基于事件驅動的網(wǎng)絡引擎框架。Twisted誕生于2000年初，在當時的網(wǎng)絡游戲開發(fā)者看來，無論他們使用哪種語言，手中都鮮有可兼顧擴展性及跨平臺的網(wǎng)絡庫。Twisted的作者試圖在當時現(xiàn)有的環(huán)境下開發(fā)游戲，這一步走的非常艱難，他們迫切地需要一個可擴展性高、基于事件驅動、跨平臺的網(wǎng)絡開發(fā)框架，為此他們決定自己實現(xiàn)一個，并從那些之前的游戲和網(wǎng)絡應用程序的開發(fā)者中學習，汲取他們的經(jīng)驗教訓。

Twisted支持許多常見的傳輸及應用層協(xié)議，包括TCP、UDP、SSL/TLS、HTTP、IMAP、SSH、IRC以及FTP。就像Python一樣，Twisted也具有“內(nèi)置電池”（batteries-included）的特點。Twisted對于其支持的所有協(xié)議都帶有客戶端和服務器實現(xiàn)，同時附帶有基于命令行的工具，使得配置和部署產(chǎn)品級的Twisted應用變得非常方便。

21.1 為什么需要Twisted

2000年時，Twisted的作者Glyph正在開發(fā)一個名為Twisted Reality的基于文本方式的多人在線游戲。這個游戲采用Java開發(fā)，里面盡是一堆線程——每個連接就有3個線程處理。處理輸入的線程會在讀操作上阻塞，處理輸出的線程將在一些寫操作上阻塞，還有一個“邏輯”線程將在等待定時器超時或者事件入隊列時休眠。隨著玩家們在虛擬世界中移動并交互時，線程出現(xiàn)死鎖，緩存被污染，程序中的加鎖邏輯幾乎從來就沒對過——采用多線程使得整個軟件變得復雜、漏洞百出而且極難擴展。

為了尋求其他的解決方案，作者發(fā)現(xiàn)了Python，特別是Python中用于對流式對象比如socket和pipe進行多路I/O復用的select模塊（UNIX規(guī)范第3版（SUSv3）描述了select）。那時，Java并沒有提供操作系統(tǒng)的select接口或者任何其他的異步I/O API（針對非阻塞式I/O的包java.nio已經(jīng)在J2SE 1.4中加入了，2002年發(fā)布）。通過用Python中的select模塊快速搭建起游戲的原型，這迅速降低了程序的復雜度，并且比多線程版本要更加可靠。

Glyph迅速轉向了Python、select以及基于事件驅動的編程。他使用Python的select模塊為游戲編寫了客戶端和服務器。但他想要的還不止于此。從根本上說，他希望能將網(wǎng)絡行為轉變?yōu)閷τ螒蛑械膶ο蟮姆椒ㄕ{用。如果你能在游戲中收取郵件會怎樣，就像Nethack mailer這種守護進程一樣？如果游戲中的每位玩家都擁有一個主頁呢？Glyph發(fā)現(xiàn)他需要優(yōu)秀的IMAP以及HTTP客戶端和服務器的Python實現(xiàn)，而這些都要采用select。

他首先轉向了Medusa，這是一個在90年代中期開發(fā)的平臺，在這里可以采用Python中的asyncore模塊來編寫網(wǎng)絡服務。asyncore是一個異步化處理socket的模塊，在操作系統(tǒng)的select API之上構建了一個調度器和回調接口。

這對于Glyph來說是個激動人心的發(fā)現(xiàn)，但Medusa有兩個缺點：

這個項目到2001年就不再維護了，那正是glyph開發(fā)Twisted Reality的時候。

asyncore只是對socket的一個薄封裝層，應用程序的編寫者仍然需要直接操作socket。這意味著程序可移植性的擔子仍然落在程序員自己身上。此外，那時asyncore對Windows的支持還有問題，Glyph希望能在Windows上運行一個帶有圖形用戶界面的客戶端。

Glyph需要自己實現(xiàn)一個網(wǎng)絡引擎平臺，而且他意識到Twisted Reality已經(jīng)打開了問題的大門，這和他的游戲一樣有趣。

隨著時間的推移，Twisted Reality這個游戲就演化成了Twisted網(wǎng)絡引擎平臺。它可以做到當時Python中已有的網(wǎng)絡平臺所無法做到的事情：

• 使用基于事件驅動的編程模型，而不是多線程模型。
• 跨平臺：為主流操作系統(tǒng)平臺暴露出的事件通知系統(tǒng)提供統(tǒng)一的接口。
• “內(nèi)置電池”的能力：提供流行的應用層協(xié)議實現(xiàn)，因此Twisted馬上就可為開發(fā)人員所用。
• 符合RFC規(guī)范，已經(jīng)通過健壯的測試套件證明了其一致性。
• 能很容易的配合多個網(wǎng)絡協(xié)議一起使用。
• 可擴展。

21.2 Twisted架構概覽

Twisted是一個事件驅動型的網(wǎng)絡引擎。由于事件驅動編程模型在Twisted的設計哲學中占有重要的地位，因此這里有必要花點時間來回顧一下究竟事件驅動意味著什么。

事件驅動編程是一種編程范式，這里程序的執(zhí)行流由外部事件來決定。它的特點是包含一個事件循環(huán)，當外部事件發(fā)生時使用回調機制來觸發(fā)相應的處理。另外兩種常見的編程范式是（單線程）同步以及多線程編程。

讓我們用例子來比較和對比一下單線程、多線程以及事件驅動編程模型。圖21.1展示了隨著時間的推移，這三種模式下程序所做的工作。這個程序有3個任務需要完成，每個任務都在等待I/O操作時阻塞自身。阻塞在I/O操作上所花費的時間已經(jīng)用灰色框標示出來了。

圖21.1 線程模型

在單線程同步模型中，任務按照順序執(zhí)行。如果某個任務因為I/O而阻塞，其他所有的任務都必須等待，直到它完成之后它們才能依次執(zhí)行。這種明確的執(zhí)行順序和串行化處理的行為是很容易推斷得出的。如果任務之間并沒有互相依賴的關系，但仍然需要互相等待的話這就使得程序不必要的降低了運行速度。

在多線程版本中，這3個任務分別在獨立的線程中執(zhí)行。這些線程由操作系統(tǒng)來管理，在多處理器系統(tǒng)上可以并行處理，或者在單處理器系統(tǒng)上交錯執(zhí)行。這使得當某個線程阻塞在某個資源的同時其他線程得以繼續(xù)執(zhí)行。與完成類似功能的同步程序相比，這種方式更有效率，但程序員必須寫代碼來保護共享資源，防止其被多個線程同時訪問。多線程程序更加難以推斷，因為這類程序不得不通過線程同步機制如鎖、可重入函數(shù)、線程局部存儲或者其他機制來處理線程安全問題，如果實現(xiàn)不當就會導致出現(xiàn)微妙且令人痛不欲生的bug。

在事件驅動版本的程序中，3個任務交錯執(zhí)行，但仍然在一個單獨的線程控制中。當處理I/O或者其他昂貴的操作時，注冊一個回調到事件循環(huán)中，然后當I/O操作完成時繼續(xù)執(zhí)行?；卣{描述了該如何處理某個事件。事件循環(huán)輪詢所有的事件，當事件到來時將它們分配給等待處理事件的回調函數(shù)。這種方式讓程序盡可能的得以執(zhí)行而不需要用到額外的線程。事件驅動型程序比多線程程序更容易推斷出行為，因為程序員不需要關心線程安全問題。

當我們面對如下的環(huán)境時，事件驅動模型通常是一個好的選擇：

程序中有許多任務，而且…

任務之間高度獨立（因此它們不需要互相通信，或者等待彼此）而且…

在等待事件到來時，某些任務會阻塞。

當應用程序需要在任務間共享可變的數(shù)據(jù)時，這也是一個不錯的選擇，因為這里不需要采用同步處理。

網(wǎng)絡應用程序通常都有上述這些特點，這使得它們能夠很好的契合事件驅動編程模型。

重用已有的應用

在Twisted創(chuàng)建之前就已經(jīng)有了許多針對多種流行的網(wǎng)絡協(xié)議的客戶端和服務器實現(xiàn)了。為什么Glyph不直接用Apache、IRCd、BIND、OpenSSH或者任何其他已有的應用，而要為Twisted從頭開始重新實現(xiàn)各個協(xié)議的客戶端和服務器呢？

問題在于所有這些已有的實現(xiàn)都存在有從頭寫起的網(wǎng)絡層代碼，通常都是C代碼。而應用層代碼直接同網(wǎng)絡層耦合在一起，這使得它們非常難以以庫的形式來復用。當要一起使用這些組件時，如果希望在多個協(xié)議中暴露相同的數(shù)據(jù)，則它們必須以黑盒的形式來看待，這使得開發(fā)者根本沒機會重用代碼。此外，服務器和客戶端的實現(xiàn)通常是分離的，彼此之間不共享代碼。要擴展這些應用，維護跨平臺的客戶端-服務器兼容性的難度本不至于這么大。

Twisted中的客戶端和服務器是用Python開發(fā)的，采用了一致性的接口。這使得開發(fā)新的客戶端和服務器變得很容易實現(xiàn)，可以在客戶端和服務器之間共享代碼，在協(xié)議之間共享應用邏輯，以及對某個實現(xiàn)的代碼做測試。

Reactor模式

Twisted實現(xiàn)了設計模式中的反應堆（reactor）模式，這種模式在單線程環(huán)境中調度多個事件源產(chǎn)生的事件到它們各自的事件處理例程中去。

Twisted的核心就是reactor事件循環(huán)。Reactor可以感知網(wǎng)絡、文件系統(tǒng)以及定時器事件。它等待然后處理這些事件，從特定于平臺的行為中抽象出來，并提供統(tǒng)一的接口，使得在網(wǎng)絡協(xié)議棧的任何位置對事件做出響應都變得簡單。

基本上reactor完成的任務就是：

while True:timeout = time_until_next_timed_event()events = wait_for_events(timeout)events += timed_events_until(now())for event in events:event.process()

Twisted目前在所有平臺上的默認reactor都是基于poll API的（UNIX規(guī)范第3版（SUSv3）中描述）。此外，Twisted還支持一些特定于平臺的高容量多路復用API。這些reactor包括基于FreeBSD中kqueue機制的KQueue reactor，支持epoll接口的系統(tǒng)（目前是Linux 2.6）中的epoll reactor，以及基于Windows下的輸入輸出完成端口的IOCP reactor。

在實現(xiàn)輪詢的相關細節(jié)中，Twisted需要考慮的包括：

• 網(wǎng)絡和文件系統(tǒng)的限制
• 緩沖行為
• 如何檢測連接丟失
• 出現(xiàn)錯誤時的返回值

Twisted的reactor實現(xiàn)同時也考慮了正確使用底層的非阻塞式API，并正確處理各種邊界情況。由于Python中沒有暴露出IOCP API，因此Twisted需要維護自己的實現(xiàn)。

管理回調鏈

回調是事件驅動編程模型中的基礎，也是reactor通知應用程序事件已經(jīng)處理完成的方式。隨著程序規(guī)模不斷擴大，基于事件驅動的程序需要同時處理事件處理成功和出錯的情況，這使得程序變得越來越復雜。若沒有注冊一個合適的回調，程序就會阻塞，因為這個事件處理的過程絕不會發(fā)生。出現(xiàn)錯誤時需要通過應用程序的不同層次從網(wǎng)絡棧向上傳遞回調鏈。

下面是兩段Python偽碼，分別是同步和異步模式下獲取URL的玩具代碼。讓我們相互比較一下這兩個版本，看看基于事件驅動的程序有什么缺陷：

以同步的方式獲取URL：

import getPagedef processPage(page):print pagedef logError(error):print errordef finishProcessing(value):print "Shutting down..."exit(0)url = "http://google.com" try:page = getPage(url)processPage(page) except Error, e:logError(error) finally:finishProcessing()

以異步的方式獲取URL：

from twisted.internet import reactor import getPagedef processPage(page):print pagefinishProcessing()def logError(error):print errorfinishProcessing()def finishProcessing(value):print "Shutting down..."reactor.stop()url = "http://google.com" # getPage takes: url, # success callback, error callback getPage(url, processPage, logError)reactor.run()

在異步版的URL獲取器中，reactor.run()啟動reactor事件循環(huán)。在同步和異步版程序中，我們假定getPage函數(shù)處理獲取頁面的工作。如果獲取成功就調用processPage，如果嘗試獲取頁面時出現(xiàn)了Exception（異常），logError就得到調用。無論哪種情況，最后都要調用finishProcessing。

異步版中的logError回調正對應于同步版中的try/except塊。對processPage的回調對應于else塊，無條件回調的finishProcessing就對應于finally塊。

在同步版中，代碼結構直接顯示出有一個try/except塊，logError和processPage這兩者間只會取其一調用一次，而finishProcessing總是會被調用一次。在異步版中需要由程序員自己負責正確調用成功和失敗情況下的回調鏈。如果由于編程錯誤，在processPage或者logError的回調鏈之后沒有調用finishProcessing，reactor事件循環(huán)將永遠不會停止，程序就會卡住。

這個玩具式的例子告訴我們在開發(fā)Twisted的頭幾年里這種復雜性令程序員感到非常沮喪。而Twisted應對這種復雜性的方式是新增一個稱為Deferred（延遲）的對象。

Deferreds

Deferred對象以抽象化的方式表達了一種思想，即結果還尚不存在。它同樣能夠幫助管理產(chǎn)生這個結果所需要的回調鏈。當從函數(shù)中返回時，Deferred對象承諾在某個時刻函數(shù)將產(chǎn)生一個結果。返回的Deferred對象中包含所有注冊到事件上的回調引用，因此在函數(shù)間只需要傳遞這一個對象即可，跟蹤這個對象比單獨管理所有的回調要簡單的多。

Deferred對象包含一對回調鏈，一個是針對操作成功的回調，一個是針對操作失敗的回調。初始狀態(tài)下Deferred對象的兩條鏈都為空。在事件處理的過程中，每個階段都為其添加處理成功的回調和處理失敗的回調。當一個異步結果到來時，Deferred對象就被“激活”，那么處理成功的回調和處理失敗的回調就可以以合適的方式按照它們添加進來的順序依次得到調用。

異步版URL獲取器采用Deferred對象后的代碼如下：

from twisted.internet import reactor import getPagedef processPage(page):print pagedef logError(error):print errordef finishProcessing(value):print "Shutting down..."reactor.stop()url = "http://google.com" deferred = getPage(url) # getPage returns a Deferred deferred.addCallbacks(success, failure) deferred.addBoth(stop)reactor.run()

在這個版本中調用的事件處理函數(shù)與之前相同，但它們都注冊到了一個單獨的Deferred對象上，而不是分散在代碼各處再以參數(shù)形式傳遞給getPage。

Deferred對象創(chuàng)建時包含兩個添加回調的階段。第一階段，addCallbacks將 processPage和logError添加到它們各自歸屬的回調鏈中。然后addBoth再將finishProcessing同時添加到這兩個回調鏈上。用圖解的方式來看，回調鏈應該如圖21.2所示：

圖21.2 回調鏈

Deferred對象只能被激活一次，如果試圖重復激活將引發(fā)一個異常。這使得Deferred對象的語義相當接近于同步版中的try/except塊。從而讓異步事件的處理能更容易推斷，避免由于針對單個事件的回調調用多了一個或少了一個而產(chǎn)生微妙的bug。

理解Deferred對象對于理解Twisted程序的執(zhí)行流是非常重要的。然而當使用Twisted為我們提供的針對網(wǎng)絡協(xié)議的高層抽象時，通常情況下我們完全不需要直接使用Deferred對象。

Deferred對象所包含的抽象概念是非常強大的，這種思想已經(jīng)被許多其他的事件驅動平臺所借用，包括jQuery、Dojo和Mochikit。

Transports

Transports代表網(wǎng)絡中兩個通信結點之間的連接。Transports負責描述連接的細節(jié)，比如連接是面向流式的還是面向數(shù)據(jù)報的，流控以及可靠性。TCP、UDP和Unix套接字可作為transports的例子。它們被設計為“滿足最小功能單元，同時具有最大程度的可復用性”，而且從協(xié)議實現(xiàn)中分離出來，這讓許多協(xié)議可以采用相同類型的傳輸。Transports實現(xiàn)了ITransports接口，它包含如下的方法：

write 以非阻塞的方式按順序依次將數(shù)據(jù)寫到物理連接上 writeSequence 將一個字符串列表寫到物理連接上 loseConnection 將所有掛起的數(shù)據(jù)寫入，然后關閉連接 getPeer 取得連接中對端的地址信息 getHost 取得連接中本端的地址信息

將transports從協(xié)議中分離出來也使得對這兩個層次的測試變得更加簡單。可以通過簡單地寫入一個字符串來模擬傳輸，用這種方式來檢查。

Protocols

Protocols描述了如何以異步的方式處理網(wǎng)絡中的事件。HTTP、DNS以及IMAP是應用層協(xié)議中的例子。Protocols實現(xiàn)了IProtocol接口，它包含如下的方法：

makeConnection 在transport對象和服務器之間建立一條連接 connectionMade 連接建立起來后調用 dataReceived 接收數(shù)據(jù)時調用 connectionLost 關閉連接時調用

我們最好以一個例子來說明reactor、protocols以及transports這三者之間的關系。以下是完整的echo服務器和客戶端的實現(xiàn)，首先來看看服務器部分：

from twisted.internet import protocol, reactorclass Echo(protocol.Protocol):def dataReceived(self, data):# As soon as any data is received, write it backself.transport.write(data)class EchoFactory(protocol.Factory):def buildProtocol(self, addr):return Echo()reactor.listenTCP(8000, EchoFactory()) reactor.run()

接著是客戶端部分：

from twisted.internet import reactor, protocolclass EchoClient(protocol.Protocol):def connectionMade(self):self.transport.write("hello, world!")def dataReceived(self, data):print "Server said:", dataself.transport.loseConnection()def connectionLost(self, reason):print "connection lost"class EchoFactory(protocol.ClientFactory):def buildProtocol(self, addr):return EchoClient()def clientConnectionFailed(self, connector, reason):print "Connection failed - goodbye!"reactor.stop()def clientConnectionLost(self, connector, reason):print "Connection lost - goodbye!"reactor.stop()reactor.connectTCP("localhost", 8000, EchoFactory()) reactor.run()

運行服務器端腳本將啟動一個TCP服務器，監(jiān)聽端口8000上的連接。服務器采用的是Echo協(xié)議，數(shù)據(jù)經(jīng)TCP transport對象寫出。運行客戶端腳本將對服務器發(fā)起一個TCP連接，回顯服務器端的回應然后終止連接并停止reactor事件循環(huán)。這里的Factory用來對連接的雙方生成protocol對象實例。兩端的通信是異步的，connectTCP負責注冊回調函數(shù)到reactor事件循環(huán)中，當socket上有數(shù)據(jù)可讀時通知回調處理。

Applications

Twisted是用來創(chuàng)建具有可擴展性、跨平臺的網(wǎng)絡服務器和客戶端的引擎。在生產(chǎn)環(huán)境中，以標準化的方式簡化部署這些應用的過程對于Twisted這種被廣泛采用的平臺來說是非常重要的一環(huán)。為此，Twisted開發(fā)了一套應用程序基礎組件，采用可重用、可配置的方式來部署Twisted應用。這種方式使程序員避免堆砌千篇一律的代碼來將應用程序同已有的工具整合在一起，這包括精靈化進程（daemonization）、日志處理、使用自定義的reactor循環(huán)、對代碼做性能剖析等。

應用程序基礎組件包含4個主要部分：服務（Service）、應用（Application）、配置管理（通過TAC文件和插件）以及twistd命令行程序。為了說明這個基礎組件，我們將上一節(jié)的Echo服務器轉變成一個應用。

Service

Service就是IService接口下實現(xiàn)的可以啟動和停止的組件。Twisted自帶有TCP、FTP、HTTP、SSH、DNS等服務以及其他協(xié)議的實現(xiàn)。其中許多Service都可以注冊到單獨的應用中。IService接口的核心是：

startService 啟動服務。可能包含加載配置數(shù)據(jù)，設定數(shù)據(jù)庫連接或者監(jiān)聽某個端口 stopService 關閉服務?？赡馨瑢顟B(tài)保存到磁盤，關閉數(shù)據(jù)庫連接或者停止監(jiān)聽端口

我們的Echo服務使用TCP協(xié)議，因此我們可以使用Twisted中IService接口下默認的TCPServer實現(xiàn)。

Application

Application是處于最頂層的Service，代表了整個Twisted應用程序。Service需要將其自身同Application注冊，然后就可以用下面我們將介紹的部署工具twistd搜索并運行應用程序。我們將創(chuàng)建一個可以同Echo Service注冊的Echo應用。

TAC文件

當在一個普通的Python文件中管理Twisted應用程序時，需要由開發(fā)者負責編寫啟動和停止reactor事件循環(huán)以及配置應用程序的代碼。在Twisted的基礎組件中，協(xié)議的實現(xiàn)都是在一個模塊中完成的，需要使用到這些協(xié)議的Service可以注冊到一個Twisted應用程序配置文件中（TAC文件）去，這樣reactor事件循環(huán)和程序配置就可以由外部組件來進行管理。

要將我們的Echo服務器轉變成一個Echo應用，我們可以按照以下幾個簡單的步驟來完成：

將Echo服務器的Protocol部分移到它們自己所歸屬的模塊中去。

在TAC文件中：

創(chuàng)建一個Echo應用。

創(chuàng)建一個TCPServer的Service實例，它將使用我們的EchoFactory，然后同前面創(chuàng)建的應用完成注冊。

管理reactor事件循環(huán)的代碼將由twistd來負責，我們下面會對此進行討論。這樣，應用程序的代碼就變成這樣了：

echo.py文件：

from twisted.internet import protocol, reactorclass Echo(protocol.Protocol):def dataReceived(self, data):self.transport.write(data)class EchoFactory(protocol.Factory):def buildProtocol(self, addr):return Echo()

twistd

twistd（讀作“twist-dee”）是一個跨平臺的用來部署Twisted應用程序的工具。它執(zhí)行TAC文件并負責處理啟動和停止應用程序。作為Twisted在網(wǎng)絡編程中具有“內(nèi)置電池”能力的一部分，twistd自帶有一些非常有用的配置標志，包括將應用程序轉變?yōu)槭刈o進程、定義日志文件的路徑、設定特權級別、在chroot下運行、使用非默認的reactor，甚至是在profiler下運行應用程序。

我們可以像這樣運行這個Echo服務應用：

$ twistd –y echo_server.tac

在這個簡單的例子里，twistd將這個應用程序作為守護進程來啟動，日志記錄在twistd.log文件中。啟動和停止應用后，日志文件內(nèi)容如下：

2011-11-19 22:23:07-0500 [-] Log opened. 2011-11-19 22:23:07-0500 [-] twistd 11.0.0 (/usr/bin/python 2.7.1) starting up. 2011-11-19 22:23:07-0500 [-] reactor class: twisted.internet.selectreactor.SelectReactor. 2011-11-19 22:23:07-0500 [-] echo.EchoFactory starting on 8000 2011-11-19 22:23:07-0500 [-] Starting factory <echo.EchoFactory instance at 0x12d8670> 2011-11-19 22:23:20-0500 [-] Received SIGTERM, shutting down. 2011-11-19 22:23:20-0500 [-] (TCP Port 8000 Closed) 2011-11-19 22:23:20-0500 [-] Stopping factory <echo.EchoFactory instance at 0x12d8670> 2011-11-19 22:23:20-0500 [-] Main loop terminated. 2011-11-19 22:23:20-0500 [-] Server Shut Down.

通過使用Twisted框架中的基礎組件來運行服務，這么做使得開發(fā)人員能夠不用再編寫類似守護進程和記錄日志這樣的冗余代碼了。這同樣也為部署應用程序建立了一個標準的命令行接口。

Plugins

對于運行Twisted應用程序的方法，除了基于TAC文件外還有一種可選的方法，這就是插件系統(tǒng)。TAC系統(tǒng)可以很方便的將Twisted預定義的服務同應用程序配置文件注冊，而插件系統(tǒng)能夠方便的將用戶自定義的服務注冊為twistd工具的子命令，然后擴展應用程序的命令行接口。

在使用插件系統(tǒng)時：

由于只有plugin API需要保持穩(wěn)定，這使得第三方開發(fā)者能很容易地擴展軟件。

插件發(fā)現(xiàn)能力已經(jīng)集成到系統(tǒng)中了。插件可以在程序首次運行時加載并保存，每次程序啟動時會重新觸發(fā)插件發(fā)現(xiàn)過程，或者也可以在程序運行期間反復輪詢新插件，這使得在程序已經(jīng)啟動后我們還可以判斷是否有新的插件安裝上了。

當使用Twisted插件系統(tǒng)來擴展軟件時，我們要做的就是創(chuàng)建IPlugin接口下實現(xiàn)的對象并將它們放到一個特定的位置中，這里插件系統(tǒng)知道該如何去找到它們。

我們已經(jīng)將Echo服務轉換為一個Twisted應用程序了，而將其轉換為一個Twisted插件也是非常簡單直接的。在我們之前的Echo模塊中，除了包含有Echo協(xié)議和EchoFactory的定義之外，現(xiàn)在我們還要添加一個名為twistd的目錄，其中還包含著一個名為plugins的子目錄，這里正是我們需要定義echo插件的地方。通過這個插件，我們可以啟動一個echo服務，并將需要使用的端口號作為參數(shù)指定給twistd工具。

from zope.interface import implementsfrom twisted.python import usage from twisted.plugin import IPlugin from twisted.application.service import IServiceMaker from twisted.application import internetfrom echo import EchoFactoryclass Options(usage.Options):optParameters = [["port", "p", 8000, "The port number to listen on."]]class EchoServiceMaker(object):implements(IServiceMaker, IPlugin)tapname = "echo"description = "A TCP-based echo server."options = Optionsdef makeService(self, options):"""Construct a TCPServer from a factory defined in myproject."""return internet.TCPServer(int(options["port"]), EchoFactory())serviceMaker = EchoServiceMaker()

現(xiàn)在，我們的Echo服務器將作為一個服務選項出現(xiàn)在twistd –help的輸出中。運行twistd echo –port=1235將在端口1235上啟動一個Echo服務器。

Twisted還帶有一個可拔插的針對服務器端認證的模塊twisted.cred，插件系統(tǒng)常見的用途就是為應用程序添加一個認證模式。我們可以使用twisted.cred中現(xiàn)成的AuthOptionMixin類來添加針對各種認證的命令行支持，或者是添加新的認證類型。比如，我們可以使用插件系統(tǒng)來添加基于本地Unix密碼數(shù)據(jù)庫或者是基于LDAP服務器的認證方式。

twistd工具中附帶有許多Twisted所支持的協(xié)議插件，只用一條單獨的命令就可以完成啟動服務器的工作了。這里有一些通過twistd啟動服務器的例子：

twistd web –port 8080 –path .

這條命令將在8080端口啟動一個HTTP服務器，在當前目錄中負責處理靜態(tài)和動態(tài)頁面請求。

twistd dns –p 5553 –hosts-file=hosts

這條命令在端口5553上啟動一個DNS服務器，解析指定的文件hosts中的域名，這個文件的內(nèi)容格式同/etc/hosts一樣。

sudo twistd conch –p tcp:2222

這條命令在端口2222上啟動一個SSH服務器。ssh的密鑰必須獨立設定。

twistd mail –E –H localhost –d localhost=emails

這條命令啟動一個ESMTP POP3服務器，為本地主機接收郵件并保存到指定的emails目錄下。

我們可以方便的通過twistd來搭建一個用于測試客戶端功能的服務器，但它同樣是可裝載的、產(chǎn)品級的服務器實現(xiàn)。

在部署應用程序的方式上，Twisted通過TAC文件、插件以及命令行工具twistd的部署方式已經(jīng)獲得了成功。但是有趣的是，對于大多數(shù)大型Twisted應用程序來說，部署它們?nèi)匀恍枰貙懸恍┻@類管理和監(jiān)控組件；Twisted的架構并沒有對系統(tǒng)管理員的需求呈現(xiàn)出太多的友好性。這也反映了一個事實，那就是對于系統(tǒng)管理員來說Twisted歷來就沒有太多架構可言，而這些系統(tǒng)管理員才是部署和維護應用程序的專家。在這方面，Twisted在未來架構設計的決策上需要更積極的征求這類專家級用戶的反饋意見。

21.3 反思與教訓

Twisted最近剛剛渡過了其10周年的誕辰。自項目成立以來，由于受2000年早期的網(wǎng)絡游戲啟發(fā)，目前的Twisted已經(jīng)在很大程度上實現(xiàn)了作為一個可擴展、跨平臺、事件驅動的網(wǎng)絡引擎的目標。Twisted廣泛使用于生產(chǎn)環(huán)境中，從Google、盧卡斯電影到Justin.TV以及Launchpad軟件協(xié)作平臺都有在使用。Twisted中的服務器端實現(xiàn)是多個開源軟件的核心，包括BuildBot、BitTorrent以及TahoeLAFS。

Twisted從最初開發(fā)到現(xiàn)在，其架構已經(jīng)經(jīng)歷了幾次大的變動。Deferred對象作為一個關鍵部分被增加了進來。如前文所述，這是用來管理延后的結果以及相應的回調鏈。

還有一個重要的部分被移除掉了，在目前的實現(xiàn)中已經(jīng)幾乎看不到任何影子了，這就是Twisted應用持久化（Twisted Application Persistence）。

Twisted應用持久化

Twisted應用持久化（TAP）是指將應用程序的配置和狀態(tài)保存在一個pickle中。要運行采用了這種方案的應用需要兩個步驟：

使用mktap工具創(chuàng)建一個代表該應用的pickle（該工具現(xiàn)已廢棄不用）。

使用twistd命令行工具進行unpickle操作，然后運行該應用。

這個過程是受Smalltalk images的啟發(fā)，因為我們討厭那種臨時性的且難以使用的專用配置語言，不希望它們在項目中不斷擴散。我們更希望在Python中表示配置的細節(jié)。

很快，TAP文件就引入了不必要的復雜性。修改Twisted中的類并不會使pickle中這些類的實例得到改變。在pickle對象上使用新版本的類方法或屬性時可能會使整個應用崩潰。因此“升級版”的概念得以引入，即將pickle對象升級到新的API版本。但這就會出現(xiàn)升級版本的矩陣化現(xiàn)象，出現(xiàn)各種不同版本的pickle對象，因此單元測試時需要維護涵蓋所有可能的升級路徑。想全面地跟蹤所有的接口變化依然很難，而且容易出錯。

TAP以及相關的組件全部被廢除了，最終從Twisted中完全剔除掉。取而代之的是TAC文件和插件系統(tǒng)。TAP這個縮寫被重新定義為Twisted Application Plugin（Twisted應用插件），如今已經(jīng)很難在Twisted中找到pickle系統(tǒng)的蹤跡了。

我們從TAP的慘敗中得到的教訓是：如果可維護性要達到合理化的程度，則持久性數(shù)據(jù)就需要有一個明確的模式。更一般的是，我們學到了如何為項目增加復雜度：為了解決某個問題而需要引入一個新系統(tǒng)時，我們要正確理解這個方案的復雜性，并經(jīng)過測試。新系統(tǒng)所帶來的價值應該明顯大于其復雜性。確保了這一點之后我們才能將方案付諸于項目中。

web2：重構的教訓

雖然這基本上不屬于架構設計上的決策，但從項目管理的角度來看，重寫Twisted的Web實現(xiàn)對于Twisted的外在形象以及維護者對代碼庫中其他部分做架構改善的能力卻有著長遠的影響，因此這里值得我們簡單討論一下。

在2000年中期，Twisted的開發(fā)者決定完全重寫twisted.web API，在Twisted代碼庫中將其作為一個單獨的項目實現(xiàn)，這就是web2。web2將包含許多針對原有twisted.web的改善和提升，包括完全支持HTTP1.1，以及對流式數(shù)據(jù)的API支持。

web2最初只是試驗性的項目，但最終被大型項目所采用，甚至意外的得以在Debian系統(tǒng)上打包發(fā)布。twisted.web和web2的開發(fā)一直并行持續(xù)了多年，新用戶常常被這兩個并行的項目搞混，關于究竟應該使用哪種實現(xiàn)缺乏明確的提示，這使得新用戶很沮喪。轉換到web2的情況從未出現(xiàn)，終于在2011年開發(fā)者將其從代碼庫中移除，官方主頁上再也看不到它了。web2中做出的一些改進也被慢慢地移植回twisted.web中。

Twisted獲得了難以導航且結構混亂，容易使新開發(fā)者感到困惑的“惡名”，這個印象部分歸功于web2。以至于數(shù)年之后，Twisted社區(qū)仍然在同這種不和諧的名聲做斗爭。

我們從web2中汲取的教訓是：從頭開始重構一個項目通常都是糟糕的主意。但如果必須這么做，請確保開發(fā)者社區(qū)能夠懂得這么做的長遠意義，而且在用戶社群中要有明確的選擇該使用哪種實現(xiàn)。

如果Twisted能夠倒退回web2的時代，開發(fā)者們應該會對twisted.web做一系列向后兼容型的修改而不是去重構。

緊跟互聯(lián)網(wǎng)的浪潮

我們使用互聯(lián)網(wǎng)的方式還在持續(xù)演進中。把多種協(xié)議的實現(xiàn)作為軟件核心的一部分，這個技術決策使得Twisted背負了維護這些協(xié)議的沉重負擔。隨著標準的改變以及對新協(xié)議的采納，原有的實現(xiàn)必須跟著演進，同時需要嚴格的保證向后兼容性。

Twisted基本上是一個志愿者驅動型的項目，項目發(fā)展的限制因素不是技術社區(qū)的熱情，而在于志愿者的時間。比如說，1999年的RFC 2616中定義了HTTP 1.1規(guī)范，而在Twisted的HTTP協(xié)議實現(xiàn)中增加對HTTP 1.1的支持卻在2005年才開始，等到完成時已經(jīng)是2009年了。1998年RFC 2460中定義了對IPv6的支持，而Twisted對其的支持還在進行中，但是直到2011年都未能合并進去。

隨著所支持的操作系統(tǒng)的接口改變，實現(xiàn)也要跟著演進。比如，epoll事件通知機制是在2002年加入到Linux 2.5.44版中的，Twisted隨之也發(fā)展出基于epoll的reactor事件循環(huán)來利用這個新的系統(tǒng)接口。2007年時，蘋果公司發(fā)布的OS 10.5 Leopard系統(tǒng)中，系統(tǒng)調用poll的實現(xiàn)居然不支持外設，對于蘋果公司來說這個問題足以讓他們在系統(tǒng)自帶的Python中屏蔽掉select.poll接口。Twisted不得不自行解決這個問題，并從那時起就對用戶提供文檔說明。

有時候，Twisted的開發(fā)并沒有緊跟網(wǎng)絡世界的變化，有一些改進被移到核心層之外的程序庫中去了。比如Wokkel project，這是對Twisted的Jabber/XMPP支持的改進合集，已經(jīng)作為“待合入”的獨立項目有幾年之久了，但還沒有看到合入的希望。在2009年也曾經(jīng)嘗試過增加WebSocket到Twisted中，因為瀏覽器已經(jīng)開始采納對新協(xié)議的支持了。但開發(fā)計劃最終卻轉到其他外部項目中去了，因為開發(fā)者們決定暫不包含新的協(xié)議，直到IETF把它從草案轉變成標準以后再說。

所有這一切都在說明，庫和附加組件的擴散有力的證明了Twisted的靈活性和可擴展性。通過采用嚴格的測試驅動開發(fā)策略以及文檔化和編碼規(guī)范標準，這樣做能夠幫助項目避免出現(xiàn)需要“回爐”的情況。在維護大量所支持的協(xié)議和平臺的同時保持向后兼容性。Twisted是一個成熟、穩(wěn)定的項目，并繼續(xù)保持有非?；钴S的開發(fā)狀態(tài)。

Twisted期待著在下一個十年里成為你遨游互聯(lián)網(wǎng)的引擎。

總結

以上是生活随笔為你收集整理的Python Twisted介绍的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。