Python Twisted

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

做者：Jessica McKellar

Twisted是用Python实现的基于事件驱动的网络引擎框架。Twisted诞生于2000年初，在当时的网络游戏开发者看来，不管他们使用哪一种语言，手中都鲜有可兼顾扩展性及跨平台的网络库。Twisted的做者试图在当时现有的环境下开发游戏，这一步走的很是艰难，他们迫切地须要一个可扩展性高、基于事件驱动、跨平台的网络开发框架，为此他们决定本身实现一个，并从那些以前的游戏和网络应用程序的开发者中学习，汲取他们的经验教训。

Twisted支持许多常见的传输及应用层协议，包括TCP、UDP、SSL/TLS、HTTP、IMAP、SSH、IRC以及FTP。就像Python同样，Twisted也具备“内置电池”（batteries-included）的特色。Twisted对于其支持的全部协议都带有客户端和服务器实现，同时附带有基于命令行的工具，使得配置和部署产品级的Twisted应用变得很是方便。

21.1 为何须要Twisted

2000年时，Twisted的做者Glyph正在开发一个名为Twisted Reality的基于文本方式的多人在线游戏。这个游戏采用Java开发，里面满是一堆线程——每一个链接就有3个线程处理。处理输入的线程会在读操做上阻塞，处理输出的线程将在一些写操做上阻塞，还有一个“逻辑”线程将在等待定时器超时或者事件入队列时休眠。随着玩家们在虚拟世界中移动并交互时，线程出现死锁，缓存被污染，程序中的加锁逻辑几乎历来就没对过——采用多线程使得整个软件变得复杂、漏洞百出并且极难扩展。

为了寻求其余的解决方案，做者发现了Python，特别是Python中用于对流式对象好比socket和pipe进行多路I/O复用的select模块（UNIX规范第3版（SUSv3）描述了select）。那时，Java并无提供操做系统的select接口或者任何其余的异步I/O API（针对非阻塞式I/O的包java.nio已经在J2SE 1.4中加入了，2002年发布）。经过用Python中的select模块快速搭建起游戏的原型，这迅速下降了程序的复杂度，而且比多线程版本要更加可靠。

Glyph迅速转向了Python、select以及基于事件驱动的编程。他使用Python的select模块为游戏编写了客户端和服务器。但他想要的还不止于此。从根本上说，他但愿能将网络行为转变为对游戏中的对象的方法调用。若是你能在游戏中收取邮件会怎样，就像Nethack mailer这种守护进程同样？若是游戏中的每位玩家都拥有一个主页呢？Glyph发现他须要优秀的IMAP以及HTTP客户端和服务器的Python实现，而这些都要采用select。

他首先转向了Medusa，这是一个在90年代中期开发的平台，在这里能够采用Python中的asyncore模块来编写网络服务。asyncore是一个异步化处理socket的模块，在操做系统的select API之上构建了一个调度器和回调接口。

这对于Glyph来讲是个激动人心的发现，但Medusa有两个缺点：

1. 这个项目到2001年就再也不维护了，那正是glyph开发Twisted Reality的时候。
2. asyncore只是对socket的一个薄封装层，应用程序的编写者仍然须要直接操做socket。这意味着程序可移植性的担子仍然落在程序员本身身上。此外，那时asyncore对Windows的支持还有问题，Glyph但愿能在Windows上运行一个带有图形用户界面的客户端。

Glyph须要本身实现一个网络引擎平台，并且他意识到Twisted Reality已经打开了问题的大门，这和他的游戏同样有趣。

随着时间的推移，Twisted Reality这个游戏就演化成了Twisted网络引擎平台。它能够作到当时Python中已有的网络平台所没法作到的事情：

• 使用基于事件驱动的编程模型，而不是多线程模型。
• 跨平台：为主流操做系统平台暴露出的事件通知系统提供统一的接口。
• “内置电池”的能力：提供流行的应用层协议实现，所以Twisted立刻就可为开发人员所用。
• 符合RFC规范，已经经过健壮的测试套件证实了其一致性。
• 能很容易的配合多个网络协议一块儿使用。
• 可扩展。

21.2 Twisted架构概览

Twisted是一个事件驱动型的网络引擎。因为事件驱动编程模型在Twisted的设计哲学中占有重要的地位，所以这里有必要花点时间来回顾一下究竟事件驱动意味着什么。

事件驱动编程是一种编程范式，这里程序的执行流由外部事件来决定。它的特色是包含一个事件循环，当外部事件发生时使用回调机制来触发相应的处理。另外两种常见的编程范式是（单线程）同步以及多线程编程。

让咱们用例子来比较和对比一下单线程、多线程以及事件驱动编程模型。图21.1展现了随着时间的推移，这三种模式下程序所作的工做。这个程序有3个任务须要完成，每一个任务都在等待I/O操做时阻塞自身。阻塞在I/O操做上所花费的时间已经用灰色框标示出来了。

图21.1 线程模型

在单线程同步模型中，任务按照顺序执行。若是某个任务由于I/O而阻塞，其余全部的任务都必须等待，直到它完成以后它们才能依次执行。这种明确的执行顺序和串行化处理的行为是很容易推断得出的。若是任务之间并无互相依赖的关系，但仍然须要互相等待的话这就使得程序没必要要的下降了运行速度。

在多线程版本中，这3个任务分别在独立的线程中执行。这些线程由操做系统来管理，在多处理器系统上能够并行处理，或者在单处理器系统上交错执行。这使得当某个线程阻塞在某个资源的同时其余线程得以继续执行。与完成相似功能的同步程序相比，这种方式更有效率，但程序员必须写代码来保护共享资源，防止其被多个线程同时访问。多线程程序更加难以推断，由于这类程序不得不经过线程同步机制如锁、可重入函数、线程局部存储或者其余机制来处理线程安全问题，若是实现不当就会致使出现微妙且使人痛不欲生的bug。

在事件驱动版本的程序中，3个任务交错执行，但仍然在一个单独的线程控制中。当处理I/O或者其余昂贵的操做时，注册一个回调到事件循环中，而后当I/O操做完成时继续执行。回调描述了该如何处理某个事件。事件循环轮询全部的事件，当事件到来时将它们分配给等待处理事件的回调函数。这种方式让程序尽量的得以执行而不须要用到额外的线程。事件驱动型程序比多线程程序更容易推断出行为，由于程序员不须要关心线程安全问题。

当咱们面对以下的环境时，事件驱动模型一般是一个好的选择：

1. 程序中有许多任务，并且…
2. 任务之间高度独立（所以它们不须要互相通讯，或者等待彼此）并且…
3. 在等待事件到来时，某些任务会阻塞。

当应用程序须要在任务间共享可变的数据时，这也是一个不错的选择，由于这里不须要采用同步处理。

网络应用程序一般都有上述这些特色，这使得它们可以很好的契合事件驱动编程模型。

重用已有的应用

在Twisted建立以前就已经有了许多针对多种流行的网络协议的客户端和服务器实现了。为何Glyph不直接用Apache、IRCd、BIND、OpenSSH或者任何其余已有的应用，而要为Twisted从头开始从新实现各个协议的客户端和服务器呢？

问题在于全部这些已有的实现都存在有从头写起的网络层代码，一般都是C代码。而应用层代码直接同网络层耦合在一块儿，这使得它们很是难以以库的形式来复用。当要一块儿使用这些组件时，若是但愿在多个协议中暴露相同的数据，则它们必须以黑盒的形式来看待，这使得开发者根本没机会重用代码。此外，服务器和客户端的实现一般是分离的，彼此之间不共享代码。要扩展这些应用，维护跨平台的客户端-服务器兼容性的难度本不至于这么大。

Twisted中的客户端和服务器是用Python开发的，采用了一致性的接口。这使得开发新的客户端和服务器变得很容易实现，能够在客户端和服务器之间共享代码，在协议之间共享应用逻辑，以及对某个实现的代码作测试。

Reactor模式

Twisted实现了设计模式中的反应堆（reactor）模式，这种模式在单线程环境中调度多个事件源产生的事件到它们各自的事件处理例程中去。

Twisted的核心就是reactor事件循环。Reactor能够感知网络、文件系统以及定时器事件。它等待而后处理这些事件，从特定于平台的行为中抽象出来，并提供统一的接口，使得在网络协议栈的任何位置对事件作出响应都变得简单。

基本上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规范第3版（SUSv3）中描述）。此外，Twisted还支持一些特定于平台的高容量多路复用API。这些reactor包括基于FreeBSD中kqueue机制的KQueue reactor，支持epoll接口的系统（目前是Linux 2.6）中的epoll reactor，以及基于Windows下的输入输出完成端口的IOCP reactor。

在实现轮询的相关细节中，Twisted须要考虑的包括：

• 网络和文件系统的限制
• 缓冲行为
• 如何检测链接丢失
• 出现错误时的返回值

Twisted的reactor实现同时也考虑了正确使用底层的非阻塞式API，并正确处理各类边界状况。因为Python中没有暴露出IOCP API，所以Twisted须要维护本身的实现。

管理回调链

回调是事件驱动编程模型中的基础，也是reactor通知应用程序事件已经处理完成的方式。随着程序规模不断扩大，基于事件驱动的程序须要同时处理事件处理成功和出错的状况，这使得程序变得愈来愈复杂。若没有注册一个合适的回调，程序就会阻塞，由于这个事件处理的过程毫不会发生。出现错误时须要经过应用程序的不一样层次从网络栈向上传递回调链。

下面是两段Python伪码，分别是同步和异步模式下获取URL的玩具代码。让咱们相互比较一下这两个版本，看看基于事件驱动的程序有什么缺陷：

以同步的方式获取URL：

import getPage
 
def processPage(page):
    print page
 
def logError(error):
    print error
 
def 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 getPage
 
def processPage(page):
    print page
    finishProcessing()
 
def logError(error):
    print error
    finishProcessing()
 
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事件循环。在同步和异步版程序中，咱们假定getPage函数处理获取页面的工做。若是获取成功就调用processPage，若是尝试获取页面时出现了Exception（异常），logError就获得调用。不管哪一种状况，最后都要调用finishProcessing。

异步版中的logError回调正对应于同步版中的try/except块。对processPage的回调对应于else块，无条件回调的finishProcessing就对应于finally块。

在同步版中，代码结构直接显示出有一个try/except块，logError和processPage这二者间只会取其一调用一次，而finishProcessing老是会被调用一次。在异步版中须要由程序员本身负责正确调用成功和失败状况下的回调链。若是因为编程错误，在processPage或者logError的回调链以后没有调用finishProcessing，reactor事件循环将永远不会中止，程序就会卡住。

这个玩具式的例子告诉咱们在开发Twisted的头几年里这种复杂性令程序员感到很是沮丧。而Twisted应对这种复杂性的方式是新增一个称为Deferred（延迟）的对象。

Deferreds

Deferred对象以抽象化的方式表达了一种思想，即结果还尚不存在。它一样可以帮助管理产生这个结果所须要的回调链。当从函数中返回时，Deferred对象承诺在某个时刻函数将产生一个结果。返回的Deferred对象中包含全部注册到事件上的回调引用，所以在函数间只须要传递这一个对象便可，跟踪这个对象比单独管理全部的回调要简单的多。

Deferred对象包含一对回调链，一个是针对操做成功的回调，一个是针对操做失败的回调。初始状态下Deferred对象的两条链都为空。在事件处理的过程当中，每一个阶段都为其添加处理成功的回调和处理失败的回调。当一个异步结果到来时，Deferred对象就被“激活”，那么处理成功的回调和处理失败的回调就能够以合适的方式按照它们添加进来的顺序依次获得调用。

异步版URL获取器采用Deferred对象后的代码以下：

from twisted.internet import reactor
import getPage
 
def processPage(page):
    print page
 
def logError(error):
    print error
 
def 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()

在这个版本中调用的事件处理函数与以前相同，但它们都注册到了一个单独的Deferred对象上，而不是分散在代码各处再以参数形式传递给getPage。

Deferred对象建立时包含两个添加回调的阶段。第一阶段，addCallbacks将 processPage和logError添加到它们各自归属的回调链中。而后addBoth再将finishProcessing同时添加到这两个回调链上。用图解的方式来看，回调链应该如图21.2所示：

图21.2 回调链

Deferred对象只能被激活一次，若是试图重复激活将引起一个异常。这使得Deferred对象的语义至关接近于同步版中的try/except块。从而让异步事件的处理能更容易推断，避免因为针对单个事件的回调调用多了一个或少了一个而产生微妙的bug。

理解Deferred对象对于理解Twisted程序的执行流是很是重要的。然而当使用Twisted为咱们提供的针对网络协议的高层抽象时，一般状况下咱们彻底不须要直接使用Deferred对象。

Deferred对象所包含的抽象概念是很是强大的，这种思想已经被许多其余的事件驱动平台所借用，包括jQuery、Dojo和Mochikit。

Transports

Transports表明网络中两个通讯结点之间的链接。Transports负责描述链接的细节，好比链接是面向流式的仍是面向数据报的，流控以及可靠性。TCP、UDP和Unix套接字可做为transports的例子。它们被设计为“知足最小功能单元，同时具备最大程度的可复用性”，并且从协议实现中分离出来，这让许多协议能够采用相同类型的传输。Transports实现了ITransports接口，它包含以下的方法：

write                   以非阻塞的方式按顺序依次将数据写到物理链接上
writeSequence           将一个字符串列表写到物理链接上
loseConnection          将全部挂起的数据写入，而后关闭链接
getPeer                 取得链接中对端的地址信息
getHost                 取得链接中本端的地址信息

将transports从协议中分离出来也使得对这两个层次的测试变得更加简单。能够经过简单地写入一个字符串来模拟传输，用这种方式来检查。

Protocols

Protocols描述了如何以异步的方式处理网络中的事件。HTTP、DNS以及IMAP是应用层协议中的例子。Protocols实现了IProtocol接口，它包含以下的方法：

makeConnection               在transport对象和服务器之间创建一条链接
connectionMade               链接创建起来后调用
dataReceived                 接收数据时调用
connectionLost               关闭链接时调用

咱们最好以一个例子来讲明reactor、protocols以及transports这三者之间的关系。如下是完整的echo服务器和客户端的实现，首先来看看服务器部分：

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

接着是客户端部分：

from twisted.internet import reactor, protocol
 
class EchoClient(protocol.Protocol):
    def connectionMade(self):
        self.transport.write("hello, world!")
 
def dataReceived(self, data):
    print "Server said:", data
        self.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服务器，监听端口8000上的链接。服务器采用的是Echo协议，数据经TCP transport对象写出。运行客户端脚本将对服务器发起一个TCP链接，回显服务器端的回应而后终止链接并中止reactor事件循环。这里的Factory用来对链接的双方生成protocol对象实例。两端的通讯是异步的，connectTCP负责注册回调函数到reactor事件循环中，当socket上有数据可读时通知回调处理。

Applications

Twisted是用来建立具备可扩展性、跨平台的网络服务器和客户端的引擎。在生产环境中，以标准化的方式简化部署这些应用的过程对于Twisted这种被普遍采用的平台来讲是很是重要的一环。为此，Twisted开发了一套应用程序基础组件，采用可重用、可配置的方式来部署Twisted应用。这种方式使程序员避免堆砌千篇一概的代码来将应用程序同已有的工具整合在一块儿，这包括精灵化进程（daemonization）、日志处理、使用自定义的reactor循环、对代码作性能剖析等。

应用程序基础组件包含4个主要部分：服务（Service）、应用（Application）、配置管理（经过TAC文件和插件）以及twistd命令行程序。为了说明这个基础组件，咱们将上一节的Echo服务器转变成一个应用。

Service

Service就是IService接口下实现的能够启动和中止的组件。Twisted自带有TCP、FTP、HTTP、SSH、DNS等服务以及其余协议的实现。其中许多Service均可以注册到单独的应用中。IService接口的核心是：

startService    启动服务。可能包含加载配置数据，设定数据库链接或者监听某个端口
stopService     关闭服务。可能包含将状态保存到磁盘，关闭数据库链接或者中止监听端口

咱们的Echo服务使用TCP协议，所以咱们可使用Twisted中IService接口下默认的TCPServer实现。

Application

Application是处于最顶层的Service，表明了整个Twisted应用程序。Service须要将其自身同Application注册，而后就能够用下面咱们将介绍的部署工具twistd搜索并运行应用程序。咱们将建立一个能够同Echo Service注册的Echo应用。

TAC文件

当在一个普通的Python文件中管理Twisted应用程序时，须要由开发者负责编写启动和中止reactor事件循环以及配置应用程序的代码。在Twisted的基础组件中，协议的实现都是在一个模块中完成的，须要使用到这些协议的Service能够注册到一个Twisted应用程序配置文件中（TAC文件）去，这样reactor事件循环和程序配置就能够由外部组件来进行管理。

要将咱们的Echo服务器转变成一个Echo应用，咱们能够按照如下几个简单的步骤来完成：

1. 将Echo服务器的Protocol部分移到它们本身所归属的模块中去。

2. 在TAC文件中：

   1. 建立一个Echo应用。
   2. 建立一个TCPServer的Service实例，它将使用咱们的EchoFactory，而后同前面建立的应用完成注册。

管理reactor事件循环的代码将由twistd来负责，咱们下面会对此进行讨论。这样，应用程序的代码就变成这样了：

echo.py文件：

from twisted.internet import protocol, reactor
 
class 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应用程序的工具。它执行TAC文件并负责处理启动和中止应用程序。做为Twisted在网络编程中具备“内置电池”能力的一部分，twistd自带有一些很是有用的配置标志，包括将应用程序转变为守护进程、定义日志文件的路径、设定特权级别、在chroot下运行、使用非默认的reactor，甚至是在profiler下运行应用程序。

咱们能够像这样运行这个Echo服务应用：

$ twistd –y echo_server.tac

在这个简单的例子里，twistd将这个应用程序做为守护进程来启动，日志记录在twistd.log文件中。启动和中止应用后，日志文件内容以下：

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框架中的基础组件来运行服务，这么作使得开发人员可以不用再编写相似守护进程和记录日志这样的冗余代码了。这一样也为部署应用程序创建了一个标准的命令行接口。

Plugins

对于运行Twisted应用程序的方法，除了基于TAC文件外还有一种可选的方法，这就是插件系统。TAC系统能够很方便的将Twisted预约义的服务同应用程序配置文件注册，而插件系统可以方便的将用户自定义的服务注册为twistd工具的子命令，而后扩展应用程序的命令行接口。

在使用插件系统时：

1. 因为只有plugin API须要保持稳定，这使得第三方开发者能很容易地扩展软件。

2. 插件发现能力已经集成到系统中了。插件能够在程序首次运行时加载并保存，每次程序启动时会从新触发插件发现过程，或者也能够在程序运行期间反复轮询新插件，这使得在程序已经启动后咱们还能够判断是否有新的插件安装上了。

当使用Twisted插件系统来扩展软件时，咱们要作的就是建立IPlugin接口下实现的对象并将它们放到一个特定的位置中，这里插件系统知道该如何去找到它们。

咱们已经将Echo服务转换为一个Twisted应用程序了，而将其转换为一个Twisted插件也是很是简单直接的。在咱们以前的Echo模块中，除了包含有Echo协议和EchoFactory的定义以外，如今咱们还要添加一个名为twistd的目录，其中还包含着一个名为plugins的子目录，这里正是咱们须要定义echo插件的地方。经过这个插件，咱们能够启动一个echo服务，并将须要使用的端口号做为参数指定给twistd工具。

from zope.interface import implements
 
from twisted.python import usage
from twisted.plugin import IPlugin
from twisted.application.service import IServiceMaker
from twisted.application import internet
 
from echo import EchoFactory
 
class 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 = Options
 
def makeService(self, options):
    """
    Construct a TCPServer from a factory defined in myproject.
    """
    return internet.TCPServer(int(options["port"]), EchoFactory())
 
serviceMaker = EchoServiceMaker()

如今，咱们的Echo服务器将做为一个服务选项出如今twistd –help的输出中。运行twistd echo –port=1235将在端口1235上启动一个Echo服务器。

Twisted还带有一个可拔插的针对服务器端认证的模块twisted.cred，插件系统常见的用途就是为应用程序添加一个认证模式。咱们可使用twisted.cred中现成的AuthOptionMixin类来添加针对各类认证的命令行支持，或者是添加新的认证类型。好比，咱们可使用插件系统来添加基于本地Unix密码数据库或者是基于LDAP服务器的认证方式。

twistd工具中附带有许多Twisted所支持的协议插件，只用一条单独的命令就能够完成启动服务器的工做了。这里有一些经过twistd启动服务器的例子：

twistd web –port 8080 –path .

这条命令将在8080端口启动一个HTTP服务器，在当前目录中负责处理静态和动态页面请求。

twistd dns –p 5553 –hosts-file=hosts

这条命令在端口5553上启动一个DNS服务器，解析指定的文件hosts中的域名，这个文件的内容格式同/etc/hosts同样。

sudo twistd conch –p tcp:2222

这条命令在端口2222上启动一个SSH服务器。ssh的密钥必须独立设定。

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

这条命令启动一个ESMTP POP3服务器，为本地主机接收邮件并保存到指定的emails目录下。

咱们能够方便的经过twistd来搭建一个用于测试客户端功能的服务器，但它一样是可装载的、产品级的服务器实现。

在部署应用程序的方式上，Twisted经过TAC文件、插件以及命令行工具twistd的部署方式已经得到了成功。可是有趣的是，对于大多数大型Twisted应用程序来讲，部署它们仍然须要重写一些这类管理和监控组件；Twisted的架构并无对系统管理员的需求呈现出太多的友好性。这也反映了一个事实，那就是对于系统管理员来讲Twisted从来就没有太多架构可言，而这些系统管理员才是部署和维护应用程序的专家。在这方面，Twisted在将来架构设计的决策上须要更积极的征求这类专家级用户的反馈意见。

21.3 反思与教训

Twisted最近刚刚渡过了其10周年的诞辰。自项目成立以来，因为受2000年早期的网络游戏启发，目前的Twisted已经在很大程度上实现了做为一个可扩展、跨平台、事件驱动的网络引擎的目标。Twisted普遍使用于生产环境中，从Google、卢卡斯电影到Justin.TV以及Launchpad软件协做平台都有在使用。Twisted中的服务器端实现是多个开源软件的核心，包括BuildBot、BitTorrent以及TahoeLAFS。

Twisted从最初开发到如今，其架构已经经历了几回大的变更。Deferred对象做为一个关键部分被增长了进来。如前文所述，这是用来管理延后的结果以及相应的回调链。

还有一个重要的部分被移除掉了，在目前的实现中已经几乎看不到任何影子了，这就是Twisted应用持久化（Twisted Application Persistence）。

Twisted应用持久化

Twisted应用持久化（TAP）是指将应用程序的配置和状态保存在一个pickle中。要运行采用了这种方案的应用须要两个步骤：

1. 使用mktap工具建立一个表明该应用的pickle（该工具现已废弃不用）。

2. 使用twistd命令行工具进行unpickle操做，而后运行该应用。

这个过程是受Smalltalk images的启发，由于咱们讨厌那种临时性的且难以使用的专用配置语言，不但愿它们在项目中不断扩散。咱们更但愿在Python中表示配置的细节。

很快，TAP文件就引入了没必要要的复杂性。修改Twisted中的类并不会使pickle中这些类的实例获得改变。在pickle对象上使用新版本的类方法或属性时可能会使整个应用崩溃。所以“升级版”的概念得以引入，即将pickle对象升级到新的API版本。但这就会出现升级版本的矩阵化现象，出现各类不一样版本的pickle对象，所以单元测试时须要维护涵盖全部可能的升级路径。想全面地跟踪全部的接口变化依然很难，并且容易出错。

TAP以及相关的组件所有被废除了，最终从Twisted中彻底剔除掉。取而代之的是TAC文件和插件系统。TAP这个缩写被从新定义为Twisted Application Plugin（Twisted应用插件），现在已经很难在Twisted中找到pickle系统的踪影了。

咱们从TAP的惨败中获得的教训是：若是可维护性要达到合理化的程度，则持久性数据就须要有一个明确的模式。更通常的是，咱们学到了如何为项目增长复杂度：为了解决某个问题而须要引入一个新系统时，咱们要正确理解这个方案的复杂性，并通过测试。新系统所带来的价值应该明显大于其复杂性。确保了这一点以后咱们才能将方案付诸于项目中。

web2：重构的教训

虽然这基本上不属于架构设计上的决策，但从项目管理的角度来看，重写Twisted的Web实现对于Twisted的外在形象以及维护者对代码库中其余部分作架构改善的能力却有着长远的影响，所以这里值得咱们简单讨论一下。

在2000年中期，Twisted的开发者决定彻底重写twisted.web API，在Twisted代码库中将其做为一个单独的项目实现，这就是web2。web2将包含许多针对原有twisted.web的改善和提高，包括彻底支持HTTP1.1，以及对流式数据的API支持。

web2最初只是试验性的项目，但最终被大型项目所采用，甚至意外的得以在Debian系统上打包发布。twisted.web和web2的开发一直并行持续了多年，新用户经常被这两个并行的项目搞混，关于究竟应该使用哪一种实现缺少明确的提示，这使得新用户很沮丧。转换到web2的状况从未出现，终于在2011年开发者将其从代码库中移除，官方主页上再也看不到它了。web2中作出的一些改进也被慢慢地移植回twisted.web中。

Twisted得到了难以导航且结构混乱，容易使新开发者感到困惑的“恶名”，这个印象部分归功于web2。以致于数年以后，Twisted社区仍然在同这种不和谐的名声作斗争。

咱们从web2中汲取的教训是：从头开始重构一个项目一般都是糟糕的主意。但若是必须这么作，请确保开发者社区可以懂得这么作的长远意义，并且在用户社群中要有明确的选择该使用哪一种实现。

若是Twisted可以倒退回web2的时代，开发者们应该会对twisted.web作一系列向后兼容型的修改而不是去重构。

紧跟互联网的浪潮

咱们使用互联网的方式还在持续演进中。把多种协议的实现做为软件核心的一部分，这个技术决策使得Twisted背负了维护这些协议的沉重负担。随着标准的改变以及对新协议的采纳，原有的实现必须跟着演进，同时须要严格的保证向后兼容性。

Twisted基本上是一个志愿者驱动型的项目，项目发展的限制因素不是技术社区的热情，而在于志愿者的时间。好比说，1999年的RFC 2616中定义了HTTP 1.1规范，而在Twisted的HTTP协议实现中增长对HTTP 1.1的支持却在2005年才开始，等到完成时已是2009年了。1998年RFC 2460中定义了对IPv6的支持，而Twisted对其的支持还在进行中，可是直到2011年都未能合并进去。

随着所支持的操做系统的接口改变，实现也要跟着演进。好比，epoll事件通知机制是在2002年加入到Linux 2.5.44版中的，Twisted随之也发展出基于epoll的reactor事件循环来利用这个新的系统接口。2007年时，苹果公司发布的OS 10.5 Leopard系统中，系统调用poll的实现竟然不支持外设，对于苹果公司来讲这个问题足以让他们在系统自带的Python中屏蔽掉select.poll接口。Twisted不得不自行解决这个问题，并从那时起就对用户提供文档说明。

有时候，Twisted的开发并无紧跟网络世界的变化，有一些改进被移到核心层以外的程序库中去了。好比Wokkel project，这是对Twisted的Jabber/XMPP支持的改进合集，已经做为“待合入”的独立项目有几年之久了，但尚未看到合入的但愿。在2009年也曾经尝试过增长WebSocket到Twisted中，由于浏览器已经开始采纳对新协议的支持了。但开发计划最终却转到其余外部项目中去了，由于开发者们决定暂不包含新的协议，直到IETF把它从草案转变成标准之后再说。

全部这一切都在说明，库和附加组件的扩散有力的证实了Twisted的灵活性和可扩展性。经过采用严格的测试驱动开发策略以及文档化和编码规范标准，这样作可以帮助项目避免出现须要“回炉”的状况。在维护大量所支持的协议和平台的同时保持向后兼容性。Twisted是一个成熟、稳定的项目，并继续保持有很是活跃的开发状态。

Twisted期待着在下一个十年里成为你遨游互联网的引擎。