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

Web 应用程序的关键特性

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

可伸缩性

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

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

可用性

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

可维护性

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

可靠性

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


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

衡量可伸缩性

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

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

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

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

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

衡量可用性

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


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

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

衡量可维护性

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

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

衡量可靠性

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

评论

1 楼 yepp 2006-11-14  

提高可伸缩性和可用性的编程实践
此部分简要讨论了构建应用程序时要考虑的一些实际编程问题。

编程的可伸缩性

考虑向上扩展和向外扩展时，无需在确保应用程序可向上扩展方面花费很多精力，而应该在编码时采取一些措施来确保开发出来的应用程序可以向外扩展。

无状态性
对于可向外扩展的应用程序来说，需要具备的最重要的因素是无状态性。如果一次调用会导致存储某些数据用于后续调用，则称这样的应用程序是有状态的。之所以说它有状态，是因为这种应用程序的结果取决于在应用程序的状态。在多层应用程序中，状态的概念因而也被引入每一层中。在一个由 Web 层、应用层和数据库层组成的三层系统中，每一层都可以有自己的特性：有状态或无状态。
对于可向外扩展的解决方案，对应用程序的一次调用可能在某一台机器上处理，而后续调用可能在另一台机器上处理。如果处理不当，则可能会导致得到错误的结果。

内存缓存
各种请求的内存缓存从一方面说明了无状态规则。应用程序保存其状态的一种方法是存储在内存中。但是，如上所述，如果在两台不同的机器上处理两个连续请求，则一台机器可能无法使用存储在另一台机器中的数据。这可能导致应用程序出现错误。要使应用程序可向外扩展，您必须确保内存缓存的使用不是由于正确性方面的原因。
如果只是由于性能方面的原因而使用内存缓存，则在内存缓存中存储数据可能不会是个大问题。如果下一个请求是在同一台机器上执行，则该应用程序可能无法得到应有的性能优势。

磁盘使用量
一些请求将数据存储到磁盘上以供后续请求使用。如果存储数据的磁盘并不被服务器机群中的所有机器所共享，那么这样做可能会引来问题。所幸的是，可以在整个服务器机群中共享辅助存储器来避免此问题。但是，如果只是由于性能方面的原因要使用数据，则解决方案架构师可能需要确定是要在整个服务器机群内共享这些数据还是要单独保存这些数据。
如果由于性能方面的原因将数据存储在磁盘上并且共享时可能导致争用资源的问题，则通常不应当共享资源。如果确定应用程序逻辑决定了争用不会导致出现重大的性能瓶颈，则可将其共享。

IPC 机制
应用程序中使用进程间通信（Inter Process Communication，IPC）机制来在应用程序各个组件之间同步各种事件。但是，这些同步机制只能在一台机器上起作用，而不能在在多台机器上同时起作用。如果应用程序的目标是要能向外扩展，则在代码中必须避免使用这些机制。
实现各种 IPC 机制的方法可能不会非常直接，而且实现某些方法可能还需要大量的重新设计。

维护请求间的排序
一些应用程序要求按照特定顺序来处理某些请求。这可能会导致出现问题，因为请求可能不会按顺序到达服务器机群中的目标机器上。
请看一例。假设在一个医院信息系统（HIS）中，必须要将系统中的所有活动信息发送到另一个 HIS 系统中以做另外的处理。假定病人登记的时间比为病人下订单（通常实际情况也是如此）的时间长。如果第二个 HIS 系统在收到登记信息之前就收到了订单详表，则在这个 HIS 系统中将会出现错误。但是，第一个 HIS 系统中不会出现这种错误，因为它在第一个 HIS 系统中是按正确顺序执行的。

这种情况会导致应用程序的状态不连续。对于这类情况，需要重新设计应用程序才能避免问题。

假定操作系统的内存管理功能
很多应用程序都假定由操作系统提供内存管理功能或进程调度功能。在此过程中，通常也假定存在内存管理或进程调度特性。例如，轮流调度可能是在应用程序本身中假定的。这样做有时可能会在向外扩展应用程序时导致错误。在为以后要向外扩展的应用程序设计或创建架构时都要考虑这个问题。
可用性
当设计开发需要具有高可用性的应用程序时，请牢记以下几点：

使用适当的负载平衡器
当应用程序被向外扩展后，必须使用一个负载平衡器将负载分散到各台机器之中。但是，如果一个应用程序既要能向外扩展又要具有可用性，并且需要具有五个 9s 或六个 9s 可用性时，则在一定程度上关注灾难恢复问题会带来更多益处。如果没有灾难恢复，则可能很难满足可用性要求。可以采用这样一种负载平衡器，它可放置在各个地理位置而无需中断应用程序。目前已经有些专门的负载平衡器可用于解决这一问题。

选用集群还是机群
考虑选择与机群解决方案对立的集群解决方案时需要慎重。集群解决方案的各系统之间具有紧密耦合性，允许使用大量可用功能。但是，这种解决方案有一个缺陷，就是对集群中的机器数有限制。这可能影响可伸缩程度。一些集群解决方案不允许在不关闭集群的情况下向集群中添加或从集群中删除机器。这可能会严重影响解决方案的可用性。

使用机群可以将任意数目的机器连接到机群中。这种解决方案还允许添加或删除机群中的机器而无需关闭机群。但是，机群是一种松散耦合的解决方案，因此在使用机群时不能实现自动心跳和共享某些资源（而集群允许）。

可维护性

系统的可维护性取决于设计和体系结构策略，以及系统开发时所用的机制。关于可维护性的全面而详细的介绍超出了本文的范围。

可靠性

系统的可靠性取决于编码、设计和需求采集时所用的技术。这一主题过于宽泛，超出了本文的范围。