（转）Web 的应用程序的关键特性

[b][size=18]Web 应用程序的关键特性[/size][/b]

每个企业应用程序都必须具备上述特性，以及可靠性、可升级性、可收益性、可支持性、可购性和可售性。本文主要分析了前四种特性。

[b]可伸缩性[/b]

应用程序的可伸缩性有两个独立的方向——向上扩展和向外扩展。向上扩展包括升级硬件或优化软件以确保单个服务器机组能够支持更多用户。例如，如果一个机器在向上扩展前支持 100 个用户，则在应用向上扩展后，它支持的用户可能增加到 125 个。

向外扩展就是在能添加更多服务器来执行同样的功能时，无需中断软件，即可增加应用程序所支持的用户数。添加另一组服务器后，用户可能从 100 个增加到 175 个。用户数不会倍增，原因在于共享负载的服务器之间进行通信也需要系统开销。这也决定了软件要能够无缝地在多个这类服务器之间共享单个服务器的负载。

[b]可用性[/b]

通常，我们所说的可用性即是指高可用性。具有高可用性的应用程序应该在一年中的大部分时间里都处于启动且运行的状态，因而对高可用性的衡量方法就是看它在一年里的停机时间。有关衡量技巧的详细信息，请参阅衡量可用性。这里说的停机时间还包括为应用程序维护和升级所规划的停机时间。

[b]可维护性[/b]

如果应用程序在生命周期内始终能够满足用户需求，则可认为该应用程序具有可维护性。如果应用程序可以根据需要增加用户数、升级用户需要的功能并可根据需要将新功能添加到应用程序中，则应用程序具有可维护性。

[b]可靠性[/b]

由于软件中的错误而造成应用程序停机称为不可靠性因素。应用程序应该具有高可靠性因素以确保它同时具有高可用性，这一点十分重要。任何一次停机，包括由于软件错误造成的停机，都会降低可用性。


[b][size=18]衡量方法[/size][/b]
必须要能够衡量应用程序的各种性能，这样才能在产品的生命周期内对其进行监视。此部分将探讨一些衡量方法。

[b]衡量可伸缩性[/b]

衡量可伸缩性时经常采用以下两种衡量方法：

特定的机器配置能够支持的用户数，可以衡量应用程序的向上扩展能力。例如，配有 4 GB RAM 和 80 GB HDD 的 Pentium 4 PC 能够支持 100 个用户。

在通过服务器机群增加支持应用程序的服务器后最多可支持的用户数，可以衡量应用程序的向外扩展能力。您还可以通过服务器机群最多可支持的服务器数目来衡量向外扩展能力。

虽然这些方法可以在顶层衡量可伸缩性，但您还需要针对支持的用户数来定义工作流。如果不把它考虑在内，则有可能出现不同级别的工作流复杂度所支持的用户数也不同的情况。

精确定义工作流和各类用户的比例是一项复杂的任务，并不在本文讨论范围之内。

[b]衡量可用性[/b]

可用性是用应用程序在一年内非停机时间的百分比来衡量的。表 1 给出了可用性百分比与一年内可接受的停机时间。


表 1. 可用性与一年内可接受的停机时间
可用性百分比 可接受的最长停机时间
99.9% 8.8 小时
99.99% 53 分钟
99.999% 5 分钟
99.9999% 32 秒

一些重要的系统（例如空中交通控制系统或医疗系统）需要在 99.9999% 的时间里都处于运行状态。也可以用可用性百分比中包含 9 的数目来表示可用性，例如 99.9% 被称为三个 9s 可用性。从三个 9s 可用性到六个 9s 可用性，最长的可停机时间将急剧缩短。

[b]衡量可维护性[/b]

要衡量应用程序的可维护性，请检查由应用程序造成的系统开销的百分比。例如，如果重新开发一种特性需要 x 小时，而在应用程序顶层开发需要 y 小时，则该特性的应用程序可维护性为 y/x。对于一个理想的应用程序，可维护性应当为 0，这意味着任何特性都能在应用程序中立即实现。当这个数字是通过很多特性获得的平均值时，则实际的可维护性就确定了。

系统的可维护性还随着解决问题花费时间的增长而降低。通过在分子中增加解决问题花费时间的方法可以获得系统可维护性的一个实际度量单位。

[b]衡量可靠性[/b]

应用程序的可靠性可通过每千行代码中识别出的错误数来衡量。例如，每千行代码（KLOC）中的 0.1 个错误可能就是系统可靠性的一个度量单位。但是，在某些应用程序中，对错误和增强功能加以分类可能是一项复杂的任务。对于十分重要的软件，不管软件是大是小，可能以任何形式危及到软件生存的错误始终应当为零。