互动科普

 使分布式计算系统得以重新自行组织的技术可以在系统的一部分被毁坏时重新恢复系统的运行。

 在Internet网络上冲浪不再仅仅是一项富有魅力的消遗了。数量不断增多的各种机构——从计算机公司到出版社——正在转向其运行方式与World Wide Web大同小异的各种联机服务。这些联机服务可以帮助管理重要的信息，加强决策过程并捉高效率。但是，随着越来越多的企业开始依赖于这一新技术，许多企业也受到计算机网络化所带来的问题的影响。这些问题对分布式计算系统的用户是特别明显的（分布式计算系统把散布在由计算机和终端组成的一个广泛网络上的程序、服务台和数据文件连接起来）。

每一个计算机用户都知道，跨网络运行的程序易出故障。事实上，分布式计算领域的一位先驱者、数据设备公司的Leslie B. Lamport就曾把分布式计算系统定义为这样一种系统，在这个系统中，“你根本就不知道其存在的一台汁算机所出的故障有可能连累你自己的计算机无法运行。”Web网络肯定也不含幸免于这类问题（见框图内的文字）。1995年下半年，Web网络的用户报告发生了若干起“灯光暗淡”事件（brownout）。这种事件使Internet网络上的通信大部分无法进行。这类故障的起因被归咎于软件错误、传输线路上的通信量太大或Web网络服务台过载或完全失效等种种不同原因（服务台就是存储用户从工作站选取的文件的计算机）。最可能的情况是若干因素的共同作用导致“灯光暗淡”事件的发生。遗憾的是，随着计算机网络的继续扩大——不只是World Wide web网络，也包括复盖银行、学校和许多办公室的分布计算系统——这类事件将迅速增多。

当计算机出故障时，有时受损的只是用户的时间与情绪。如果离你最近的银行自动现金出纳机出了故障，那么街对面的那台现金出纳机或许在正常运行。然而，非常复杂的网络如果出了毛病，就可能造成严重的后果；1994年7月15日，NASDAQ证券交易所——一个全电子的股票市场——因为出了一个使整个系统受到影响的莫名其妙的问题而晚开盘两个小时。工作人员开始以为是软件故障造成了这次事故，但最终发现问题出在一个运行不正常的磁盘上。由于交易只推迟了几小时，所以没有失去多少收入。然而这一事件本来有可能是场大灾难：如果交易没有及时恢复的话，股市将遭受重大损失。

另一个例子是，从1990年1月起，美国电报电活公司的电话系统因系统内的一个电子交换机出了故障而经历了一场火规模的停机。通话被自动地转到一台备用的交换机上，但这一交换机也因软件故障而不能工作。这一故障波及到整个网络。导致持续时间长达9小时的全国性停机，在这段时间巾有6万人无法使用任何电话服务，7千万次通话无法完成。对于一个熟悉哪怕是管理一个简单的网络时所遇到的问题的人来说，令人惊奇的不是会出现这些事故，而是这些事故没有出现得更频繁。

 建造可靠的电子桥梁

即使是持续时间很短的分布式系统故障对于需要二十四小时不间断运行的场合也可能造成很大的问题。空中交通管理网络和金融计算机网络必须特别可靠并随时更新。一条“主机不回答”的信息或者显示过时的飞机航线信息或股价信息的使人误解的图象很容易导致事故或金融灾难。随着人们的生活方式及工作方式的不断变革，他们的收人、财产乃至健康的安全性和稳定性将在越来越大的程度上依赖于分布式计算系统。因此，虽然谈论信息高速公路的潜在利益是一件不费力的事情，但是我们认为，联系计算机的桥梁有必要加以更细致的检查：多方面的计算机科学家（包括本文的两位作者）自七十年代后期起一直在致力于开发旨在改进分布式计算机网络的软件，使这些网络更安全，对故障具有更强的抵抗能力。此项工作被这一领域中的研究人员称为“设计可靠的分布式计算系统”。

分布式系统为什么会出故障？如果我们除开那些因管理不善或设计不当而失效的系统，则绝大多数一般的情况都是在一个点上的某一问题触发一连串的事件，使得整个网络上的程序一个接一个地最终失效。对付这一威胁的一种办法是加强各个部分——例如使用经专门设计而具有容错能力的计算机和磁盘。但是顶板仍然有可能泄漏，导致电路短路；功率可能发生波动；通信连线可能因疏忽大意而被切断。计算机黑客或心怀不满的雇员的捣乱也可能危及分布式系统。虽然工程师和计算机程序设计人员能够改进硬件和软件的耐久性能，但永远也不可能做出一台绝对可靠的计算机。

即使系统的每一部分都极其可靠，问题也不会就此结束。仅仅是把可靠的计算机和无错误的程序互连起来不会得出一个可靠的分布式系统，而只是得出一个在绝大多数情况下可较好运行的网络。电子邮件程序、电子公告牌和Web网络在设计时所使用的各个组成部分如果单独来看都是非常可靠的。但是，当系统的某一组成部分发生了意想不到的事情时，这些系统就常常停止运行：例如，在一台计算机或一条通信线路过载时，系统就可能出故障。因此，需要某种额外的躁护。

在过去二十年中，程序设计人员通过开发容错软件——即允许计算机在出现问题的情况下恢复正常运行的程序——来解决可靠性问题。这一方法消除了系统内部一环扣一环的依赖关系，正是这种依赖关系使整个系统的运行与任一单个组成部分的运行相关。使用这个新方法的系统即使在某些点脱离网络时也不一定就失效。相反，它们将迅速地重新进行配置，避开失效的服务台而重新开始运行。

 备用作后援

计算机科学家把这类布局称作具有高度可用性的分布式系统。这些系统的设计使它们能连续地复制关键信息，并把多个备用拷贝布置在其各台计算机中，因此，它们能适应不断变化的情况——一个点上的磁盘驱动器工作不正常，另一个点上过载，一条通信连线断开，等等。只要故障不发生得过于频繁以致软件来不及作出反应，这些系统就可以通过从其它地方调来一个需用文件的复制品或一个联机程序的复制件而作出反应。这样，一个系统就整体说来仍是可用的，并且，在理想情况下可向仍然与网络连接的用户提供不问断的服务。

建造高度可用的分布式系统的一个简单而流行的方法是使用一个主系统和备用系统。如果主机失效，就可以把备用系统投入运行。如果数据从不变化的话，两者间的切换是很容易的。然而，如果当系统在运行时数据式文件发生变化，那么转换就比较困难了。而且，在一个包括服务台、数据、文件和程序的分布广泛的网络上，要区分一个真正失效的系统和一个只是碰到通信麻烦的系统可能是很困难的。

假定一台计算机要更新主服务台和备用服务台上的信息，但是其中一个服务台停止对信息作出回答。如果问题仅仅出在通信线路上，则在经过足够长时间之后信息将通过线路。但是，如果服务台真的失效了，则进行更新的计算机将无限期地等待下去；在这段时间中，系统将无法被使用。然而，如果要进行更新的计算机不适当地停止等待并把更新信只传送给一个服务台，那么主服务台和备用服务台就不再相同了。此时如果系统试图使用过时的服务台，就会发生错误。

可以从NASDAQ金融市场为例来说明解决这个难题的一种方法。这一网络有两个中央交易服务台。为了防止混乱，在任一给定时刻只有一个服务台在工作。NASDAQ的操作人员自行决定何时切换到备用的服务台上。遗憾的是，只有极少的分布式系统能够依靠操作人员的才智来发现故障并把整个系统从一个服务台转换到另一个服务台上。程序设计人员必须使这一决策自动化，以便切换能够顺利地进行。

此外，高度可用的分布式系统常常有大量服务台和程序。因此，这些系统通常备有一个成员表，成员表跟踪每个程序，记下它是在工作还是没有工作。如果一个程序因任何原因不回答，就被记为出了故障。系统在一个点上发现一个故障后，于是就可以重新配置自身并把任务分流到仍在工作的点上

NASDAQ系统还说明了关于分布式系统的可靠性的又一个问题。1994年发生的那起使交易推迟两小时的事故中，如果操作人员立即切换到备用系统上的话，则这一事故本来是可以避免的。然而操作人员却选择了等待，因为他们担心可能是一个软件故障使主系统失效。如果存在这样一种故障，则备用系统也可能失效，正如美国电报电话公司的备用系统失效了一样。由于不可能保证软件绝对没有错误，因此必须有某种形式的保护措施来减少一个关键服务台的备用部分在主服务台出故障后也失效的可能性。

程序设计人员应付这一挑战的方法是所谓“主动复制”。在主动复制中，一个系统的软件通过使用所谓过程组来建立关键程序或服务台的多余拷贝。一个过程组把一组密切合作的程序连接起来。一个分布式系统可能有许多过程组，而程序则可能同时属于几个过程组。每个过程组有一个名字（很象文件名），并有它自己的当前成员表。最重要的是，过程组提供了一种把信息发送给其成员的手段。这一信息传递功能保证了过程组的每个成员都按相同次序接收每一个信息，即使发送方在发送信息的过程中出了故障。

如果某一程序对于保持系统可用性是必不可少的，则系统将使用一组程序，其中每一个程序都是原始程序的复制品。为了更新复制的程序所管理的数据，系统向过程组发送一个信息。每一成员对此信息的反应是更新其特有的拷贝。由于所有程序都按相同次序观察相同的更新数据，因此它们将保持在相互相容的状态。

主动复制使一个系统具有容错性能，因为任何一个组成员都能够处理任何请求：如果一台计算机失效，工作任务将发送到仍在运行的台上。此外，如果一项请求不会改变数据，则某一点就可以处理此询问而不必占用整个系统。这样，各项任务就可以由不同的程序同时进行处理，通过并行处理而加快了处理速度。

当然，如果一个过程组的所有成员都以同样错误的方式处理一个输入信息，则从理论上说所有成员可能同时失效。虽然主动复制似乎会受这类故障的影响，但情况已证明并非如此。程序设计人员常常注意到，在测试软件时最容易被忽略的错误是那些与收到数据的次序有关的错误。这些错误只有在事件以可能性极小的次序或时间发生时才会出现。当一个系统使用主动复制时，复制的拷贝从相同次序扫描更新的数据；但是，更新的数据仅是一个程序扫描的请求的一小部分。在绝大多数时间中，复制的程序并行工作，每个程序均按一个独特的次序处理它自己的一组询问。因此即使一个软件错误逃过了检测，并影响到一项网络化应用的几个部分，但它仍然不可能引起任一特定的过程组的所有成员同时失效。

主动复制的基本原则是很简单的，但实现它所需的软件就不简单了。管理不断变化的成员表并与过程组通信是相当困难的，特别是在面临不可避免的失效和信息丢失的情况下。虽然在过去10年中分布式计算已经普及，但主动复制仅是在最近才走出了实验室。

 可靠网络的工具

过去几年中，已有十几个软件研究小组开发出供可靠的分布式计算系统使用的软件包。所有这些软件包都通过主动复制来实现高度的可用性，虽然它们每一个的重点多少有些不同。例如，有些软件包重在提高速度而另一些软件包则更强调对安全性的要求。

我们在康奈尔大学的研究工作产生了两个这样的软件包。本文作者之一（Birman）领导的研究小组在1987年引入了Isis；后来，我们又研究了Horus，它是在1994年引入的。“Isis”和“Horus”这两个名字来自埃及神话。地狱判官Osiris在与战神Set进行的一次搏斗中被撕成了碎片，而女神Isis则出力使他得以复生。Horus是Osis的儿子，他最终战胜了Set。使用这两个神话名字是用来比喻Isis和Horus软件包有助于使一个分布式系统在受到故障的干扰后恢复运行。

像Isis这样的软件包使用一组复制并更新数据、跟踪过程组并协助处理成员变动的软件功能（或“工具”）。Isis也能够把数据处理工作分配给各个服务台（这一过程称为“均分负载”）使用均分负载的分布式系统具有并行处理的许多优点，但却不需要专用的并行计算机。通过把输入的工作分配给多个协调一致地运行的服务台，Isis使系统能够迅速地管理大量的任务。此外，如果一项特定的应用需要额外的计算功能，用户可以再增加一个服务台，均分负载法将自动地适应这一具有新尺度的过程组。Isis和Horus之类的工具有可能同时改进性能井提高可靠性；这种可能性常常使它们的开发者都感到意外：开发者们往往认为提高一个系统的可靠性将会降低它的速度，并使其变得更昂贵。

主动复制已经用于许多场合，包括若干通信网络、证券市场、银行和经纪公司。在挪威，研究人员开发出以该技术为基础的一个环境监测系统。法国空中交通管制部门也在探索此方法在新一代空中交通管制软件中的应用。另外，若干家制造厂运用过程组来协调工作，并在有设备要从生产线取下进行维修时重新配置生产线。

然而，随着计算机科学家们开始探索要求越来越高的用途，他们发现，主动复制存在着若干重要的局限性。均分负载并不总是可行的，也不一定是最好的：某些系统（特别是存储在服务台中的数据变化得非常迅速的那些系统）在其组成部分被复制时速度就会慢下来。例如，在电视会议技术中，主动复制的确改进了那些当部分参加者被断开时仍须保持运行的服务台网络的容错性能。但是，这种方法在用于向遥远用户传送电视数据时将会使系统的速度放慢，同时也不会提高其可靠性。

对灵活性的要求促使我们开发了Horus。与Isis工具一样，Horus也支持主动复制，但它的灵活性要大得多。Horus所依据的基本原理是模块化，类似于儿童的一套Legos；Horus的不同结构单元可以根据某一过程组的特殊需求以任意组合方式装配在一起。一个单元可能负责数据的加密，使黑客不能侵入副系统中。另一个单元可能处理当信息丢失或出错时可能出现的潜在通信故障。使用Horus的程序设计人员确定他们的系统实际上需要的是哪些特性，从而使他们能够根据其预定的用途对系统作定向的调节。此外，Horus还可以用定向设计的模块来扩充，以适应我们在自己的研制工作中可能没有遇到或者没有预见到的特殊需求。

Horus在世界各地的用户组日益增多。在康奈尔大学，Brian C. Smith使用Horus建立了一个用于“groupware”场舍的电视会议系统。有关Horus的资料可以下列网络地址上索取：htp://www.cscounell.edu/Info/Projeets/HORUS/

 意志危机？

我们对Isis和Horus的研究已经使我们相信仔细的规划能够保证计算机网络的可靠性。但是使信息高速公路变得可靠可能会使耗用的时间和金钱超出计算机制造商和用户愿意投入的时问和资金。分布式应用的软件通常是用现有的技术建造的，而现有的技术当初的设计并不是为了保证可靠性。此外，研究人员需要寻求更好的方法来设计可靠的、性能非常优良的大规模系统：一个在有50个用户同时访问时极其可靠的系统可能被证明慢得无结法令人接受，因此在有5000个用户访问时就变得不可靠了。

虽然程序设计人员已在某些场合中成功地应用了可靠的分布式计算技术，但公众听得更多的却是关于不可靠系统的种种故障。例如，在过去几年中，已有几十起关于现行的空中交通管制系统出问题的报导。1995年秋，洛杉矶的空中交通管制系统失灵，使工作人员无法与飞机通信，结果一场空中碰撞事故只差几秒钟就几乎发生。

更糟的是，由美国联邦航空管理局在1982年委托研制的最新的空中交通管制软件已被反复地推迟，其规模也缩小了。联邦航空管理局选择最初的建议书恰恰是因为它对分布式计算采取的新颖方针；现在，拟议中的软件的高度可用性和分布式等特点似乎差不多完全消失了。然而空中交通管制工作人员批评现有的系统不完善到了危险的地步，特别是因为它缺乏分布式软件的体系结构并随着老化而变得不可靠。诸如此类受到广泛宣传的挫折助长了一种普遍的看法，即计算机软件存在着一场危机[见《科学》1995年1月“软件的慢性危机”一文]。

但是，如果我们的确是处在一场软件开发危机中的话，那它可能是一场意志的危机而不是手段的危机。并不是所有的开发人员都急于使它们的网络软件可靠，而公众对于可靠性的压力似乎也不超出若干特别敏感的应用场合。事实上，那些推销分布式计算软件包的公司常常在其产品许可证中声明它们的技术的可靠程度不足以使它们用于关键场合，这就意味着可靠性不是一个合理的目标。在我们看来，这种情况类似于一个不大可能出现的情景：汽车制造商在推销它们的汽车时警告说这些汽车在公路上行驶是不安全的。在计算机中相当于安全带和气袋的安全手段很少用于软件开发。软件开发人员和使用程序的人的注意力主要集中在复杂的、对用户友好的接口以及提高速度和改进性能上

可靠性常常使人想起低速而笨重不堪的计算系统这样一幅图景，它与在数据高速公路上不费吹灰之力地眨眼间就取得信息的诱惑是格格不入的。然而，可靠的技术不一定就是用起来缓慢的与令人扫兴的技术：金门桥就是一个既可靠又优雅的典范。连接计算机的信息桥每过一小时就会发现更多的应用。我们热衷于把精美的电子桥纳入每一种场合中，但这种热情不应当掩盖我们对这类桥梁能否支撑信息流的合理的担忧。我们相信，可靠的分布式系统是迅速而可靠地连接计算机的一项宝贵工具，它创造了信息社会中的诸多商业和娱乐机遇，但是我们也相信，在许多情况下，除非可以设法使一个分布式系统可靠地运行，否则就最好不要建造——或使用——这样一个系统。