设计可用性很高的.NET应用程序

在当今Internet时代，人们需要的信息可以很快地得到，用户希望应用程序是连续可用的。停机会给你的业务带来很多影响，这些影响不仅体现在可以计量的方面（比如损失的销售量），也体现在一些无形的领域（比如你们公司的形象）。在本文中，我将讲述一些用来得到高度可用的应用程序的好的做法，以及在.NET中需要人们特别注意的事项。

首先，我要定义一下高度可用是什么意思，你如何可以确定你的应用程序的可用性。作为特色，人们是根据有多少个“九”来谈论可用性的。例如，如果你的应用程序达到99.9%的可用性，我们就认为它的可用性有三个九。九越多越好，因为它说明你更接近100%的可用性。业界把目标定在达到五个九，即达到99.999%的可用性，相当于每年有约5分钟的停机（见表1）。

为了估算你的系统的可用性，你可以用这个公式：

Availability = (MTBF / (MTBF + MTTR)) X 100

平均故障间隔时间（Mean Time Between Failure（MTBF））是应用程序出现故障前，平均运行的时间。你可以用整个正常运行时间除以应用程序故障数量来计算它。平均修复时间（Mean Time To Recovery（MTTR））是在应用程序恢复使用前，平均需要的时间，通常它就是我们所指的停机时间。你可以用使应用程序恢复正常所需的小时数除以应用程序故障数来计算它。该公式也说明了一个要点。可用性不仅仅是使故障数达到最小，它同使应用程序恢复正常所需的时间达到最小是同样重要的。

你可以通过几种方法来限制应用程序在你的企业中的停机时间。然而，你首先应该考虑你的应用程序需要达到何种程度的可用性，你可以投资多少来得到你期望的可用性。不同类型的应用程序在不同时间需要不同程度的可用性。并不是所有的应用程序都需要一年365天、一周7天、一天24小时的正常运行时间；实际上，大多数应用程序并不需要。金融应用程序，如银行或股票经纪人所用的网站，可能需要这样的正常运行时间，但是其他内部运用的商业应用程序，只需要应用程序在每周一到周五、每天9点到5点可用，即当工人们工作、需要的时候可用。

虽然一些应用程序的正常运行时间可能很短，但是本质上它不能在那段时间内出现故障。数据采集就是一个很好的例子。假设你的应用程序存储了来自CAT扫描仪的数据。在进行扫描时，你的应用程序也许只需要20分钟的正常运行时间，但你不想它在那段时间出问题，否则病人就得再被扫描一次。

仔细研究你的应用程序的可用性需求，然后确定在那段时间内，应用程序可以容忍多长时间的停机。你也应该考虑得到你期望的程度的可用性所需要的成本。可用性每增加一个九就会使你在冗余硬件和软件上的投资更多，而且需要额外的受过高水平培训的IT人员。在此，我将略述一下你可以采用什么方法来得到更多的九，如果那就是你的目标的话。

采取措施来消除停机
你可以通过几种方法来帮你消除停机。下面是一些最好的方法：

为一个好的备援和恢复计划做投资。我的文章“避免灾难性的停机”（在上一期.NET Magazine中）略述了如何建立这样一个计划。有些停机是不可避免的，尤其当它们是由外部因素引起时——如安全性被破坏或自然灾难。幸运的是，通过运用一个谨慎考虑后产生的、并经过彻底测试的备援和恢复计划，在出现故障时，你就可以使停机时间降到最少。如果停机是不可避免的，那就需要做好准备使应用程序很快地恢复正常运行。你也应该让所有你的服务器上的时钟同网络时间协议（Network Time Protocol（NTP））同步，或采用一个类似的方法（见资源）。这对于一个好的备援和恢复计划是很重要的，因为它可以帮你调查并跟踪问题。

运用冗余硬件。首先，提供冗余硬盘存储器。因为硬盘存储的内容是变化的，所以硬盘是出现故障率最高的硬件之一。由于这个原因，你应该用RAID 1或更高级的RAID来提供冗余磁盘存储器。热插拔驱动器也可以降低停机时间；它们可以让你很快地替换一个出故障的驱动器，而不会使服务器停止工作。你也应该将多个磁盘控制器连接到磁盘阵列。通常你可以通过用两个或更多个连接到一个共享的磁盘阵列的服务器群来实现它。同样，如果你的磁盘控制器运用写缓存（write caching）性能，它也应该有一个备援电池来保证所有写入磁盘的东西最终都成功写入了。

然后，将容错RAM用于你的服务器，并运用Error Corrective Coding（ECC）内存，它自动纠正内存模块中的错误，避免数据被破坏，及可能出现的系统瘫痪。另外，一些主板也支持热备份内存槽。它们提供了额外的内存模块，如果现有的内存模块出现故障，这些额外的内存模块就可以提供即时的故障转移（failover）。

你也需要提供冗余网络传输。运用多个网卡，开发小组可以在冗余的单独的物理网络上进行配置以免一个网络路径出现问题，或者它也可以将这些网卡作为一个单独的逻辑网卡用一个单独的MAC地址通过软件来配置，以免其中一个网卡、一条网线或网络集线器端口出故障。

为设备提供冗余电源也很重要。将两个或更多个冗余的、热插拔电源用于每个服务器，而且，如果可能，将每个电源放在一个单独的电力供应网（power grid）上。为服务器和网络设备提供备份电池电源，或者备份发电器电源。确信，服务器的配置可以使它在备份电池电源用完时自动关闭，一旦电源恢复，它又可以重新启动。

最后，为你的硬件提供一个好的操作环境。你的数据处理中心应该有适当的温度和湿度控制器、活动地板来预防水灾和静电放电、以及用于电气设备的安全的灭火系统，如那些运用Halon的灭火系统。

运用支持故障转移（failover）的软件。你应该随时尽可能地运用支持集群（clustering）的操作系统、服务器和应用程序软件。集群就是配置几台机器，它们是同样的，在一个单独的应用程序中一起工作。这样的话，如果一台服务器停了，应用程序就可以从出故障的一台服务器转移到另一台服务器。集群也可以为你的应用程序提供可扩展性。你可以集合前端服务器，如Web服务器；也可以集合后端服务器，如数据库服务器，来避免任何单个点的故障（关于其它可供选择的方法，见工具条“研究一种集群方法）”）。如果你的开发小组编写了用于内部的软件应用程序，那么确保它们支持集群，或者实现定制的故障转移方法。消息列队和事务处理服务也可以使你的应用程序从故障中转移，因为它们可以用来维持多个服务器之间的状态信息。

运用网络负载平衡（Network Load Balancing（NLB））。NLB将自动跨多个服务器分配你的客户端访问量。一般你将它同集群一起使用。这样的话，如果集群中的一个节点出现故障，NLB会自动检测故障，并将客户端的访问量重新导向到集群中的其它节点。

将安全性设为最优先考虑的项目。实现安全性不仅要确保你有一个好的防火墙和最新的安全修补措施。它也包括为你的数据管理中心提供好的物理的安全性，让雇员只能访问那些他们需要用来执行他们的指定任务的业务。

广泛运用事件记录和监控。当你将这么多冗余硬件构建到你的系统中时，运用监控性的应用程序就很重要了，当出现故障时，它们就可以通知相关的人。你可能想知道你的RAID 5阵列中的硬盘驱动器什么时候出现了故障，这样你就可以在另外的硬盘也出了故障、你丢失了逻辑驱动器上的所有数据前很快地替换它。或者，如果一个集群中的一个节点出了故障，你就需要诊断问题并尽快使其恢复。监控所有系统，使其正常运转，这是很重要的。你也可能想知道在系统上是否有不寻常的负载，或者你是否已经用完了存储空间。

下面就是你应该监控的一些事项清单，当出现异常时，你应该警惕这些方面：

· 磁盘空间

· 内存的使用

· CPU的使用

· 网络负载

· 应用程序列队

· 硬件故障

· 软件应用程序错误

· 数据库事务处理时间

· 安全记录

好的监控警报也可以让你知道你什么时候需要增加你的系统的容量，它们也可以帮你解决系统瓶颈问题或者可能出现的故障问题。

设置一个支持性底层框架。并不是所有类型的故障都出现在自动监控或事件记录中。应用程序的用户应该有方法来联系一个支持小组，它可以跟踪问题，从最初的问题报告直到将问题解决。支持小组应该有适当的方法来一步步解决问题，提供必要的与IT人员或者软件开发人员的联系信息，让他们来解决问题。支持小组也帮助你跟踪问题，这样这些问题今后就会被避免。

测试你的应用程序的故障转移性能。设置一个测试环境，可以让你模拟各种类型的硬件和软件故障。该环境是至关重要的，它可以确保应用程序的修补措施和升级方法是可靠的，并且运行良好。

考虑外购。当你在评估需要用来实现一个高度可用的应用程序的底层框架时，很显然，它会很贵。你需要将冗余硬件和额外的软件许可用于冗余服务器。你需要集群软件、NLB硬件和软件、以及多个通过Network Access Points（NAPs）与Internet的冗余连接。你还需要一个拔尖的IT团队和支持人员来使应用程序顺利运行。由于这个原因，考虑将你的应用程序的hosting外包给那些擅长于这个领域的供应商是很有意义的。从经济角度来看，他们通常可以给你提供更高程度的可用性，这种可用性会远远高于你用同样成本自己实现的可用性。现在你已经了解了高可用性的含义以及达到这种可用性你可以采用的最好的方法，让我们来看看所有这些对于.NET应用程序意味着什么吧。

从.NET的角度来考虑
当人们谈论.NET应用程序时，他们就会想到Web服务。因为.NET应用程序的趋势就是运用Web服务，所以.NET应用程序比其它应用程序更具有分布式的特点。在创建高度可用的应用程序上，这种分布式的本性就像一把双刃的剑。为了进一步说明，假设你有一个电子商务应用程序或在线商店（见图1）。为简便起见，样例程序用了来自不同外方的两个Web服务来处理信用卡交易。（实际上，应用程序可以在内部和外部运用几个Web服务来执行任务，如目录跟踪和跟踪船运货物。）

图1. 创建一个高可用性的电子商务.NET应用程序

首先，我讲述一下Web服务给高度可用的应用程序提供了哪些优势。Web服务提供了一种方式来分解应用程序处理并将它分布到多个冗余服务器。你可以把提供Web服务的服务器放在单独的物理位置上，相互之间隔得很远。在这个例子中，位于不同场所的两个不同的公司提供了两个信用卡处理服务。这就使由于自然灾害或者本地网络服务中断而损害应用程序的机会减小了。另外，每个供应商可以有多个同样的Web服务用于冗余。这种将处理过程逻辑分离到Web服务中的方法提供了简单的应用程序故障转移。你的应用程序只需要尝试一个Web服务地点，如果它没有响应或没有返回一个错误，应用程序就可以继续运行，并尝试另一个执行同样功能的Web服务。

然而，当你创建一个高度可用的应用程序时，分布式的Web服务也给我们带来了一些挑战。连接Web服务的网络传输可能不可靠。如果你的传输是通过Internet，那么情况尤其如此，如图1中所示。因此，运用Internet来连接你的Web服务，而不是使他们本地化或者通过一个私有的WAN来连接，会使出现故障的机率增大。通常，ISPs不做任何服务保证。所以，服务的网络质量不能保证。

为了确保你的应用程序的可用性，你至少需要通过不同的ISPs的两个独立的Internet连接，最好连接到不同的NAPs。在通过Internet或WAN连接到Web服务时，你通常也需要考虑延迟更长和带宽更低这些局限性。

这些都是你在设计你的应用程序时需要重点考虑的事项。它们可能决定你可以将哪些过程实现为Web服务，或者你的Web服务之间的布置和连接速度。正如样例中两个信用卡处理公司所做的那样，你可以决定运用由一个外方提供的一个Web服务。在这种情况下，你的应用程序的可用性将取决于那个公司的Web服务的可用性。我们建议你得到外方的一个Service Level Agreement（服务级别协议书）（SLA），它可以确保供应商满足你的应用程序可用性目标。另外，同不只一个Web服务供应商建立协约也可以提高你的应用程序的可用性。

你在设计高度可用的.NET应用程序时，记住你需要冗余硬件、软件和网络连接来转移故障。而且你应该认真考虑至少外购你的应用程序的一些功能。

关于作者:
Todd Walker持有MCSE和MCSD证书，他是位于Columbia，S.C.的Hunter Stone Inc.公司的CTO。Hunter Stone是一家微软认证伙伴（Microsoft Certified Partner），为中等规模和大规模的公司提供基于Microsoft .NET平台的定制的软件应用程序开发。Todd的联系方式是[e-mail]。