网络应用系统产品质量评价属性

摘自Roy Thomas Fielding博士论文第二章，该章给出了网络系统软件的属性评价指标，同时以指出，分类方式并不是唯一的，这是一个权衡取舍的过程。

Architectural Styles and the Design of Network-based Software Architectures

1 性能（更多的是网络效率，而不单指某个程序的功能运行效率）

关注基于网络的应用程序的样式的主要原因之一是，组件交互可能是决定用户感知性能和网络效率的主要因素。由于体系结构风格会影响这些交互的性质，因此在基于网络的应用程序的部署中，选择合适的体系结构风格可以决定成功与失败。

基于网络的应用程序的性能首先受应用程序需求的约束，然后受所选择的交互样式的约束，接着受实现的体系结构的约束，最后受每个组件的实现的约束。换句话说，软件无法避免实现应用程序需求的基本成本;例如，如果应用程序要求数据位于系统A并在系统B上进行处理，那么软件就无法避免将数据从A移动到B。同样，架构不可能比其交互风格允许的更有效;例如，将数据从A移动到B的多个交互的成本不能低于从A到B的单个交互的成本。最后，不管体系结构的质量如何，任何交互都不能比组件实现产生数据和其接收者消费数据的速度快。

（1）网络性能

网络性能度量用于描述通信的某些属性。吞吐量是信息(包括应用程序数据和数据)处理的速率和通信开销，是在组件之间传递的。开销可以分为初始设置开销和每次交互开销，这种区别对于识别可以跨多个交互共享设置开销的连接器非常有用。带宽是对给定网络链路上最大可用吞吐量的度量。可用带宽是指应用程序实际可用的那部分带宽。

风格通过影响每个用户操作的交互次数和数据元素的粒度来影响网络性能。鼓励小型强类型交互的样式在涉及已知组件之间的小数据传输的应用程序中是有效的，但是在涉及大型数据传输或协商接口的应用程序中会造成过多的开销。同样，涉及多个组件的协调以过滤大型数据流的样式在主要需要小型控制消息的应用程序中是不合适的。

（2）用户感知性能

用户感知性能与网络性能的不同之处在于，一个操作的性能是根据其对应用程序前用户的影响来衡量的，而不是根据网络移动信息的速度来衡量的。用户感知性能的主要度量是延迟和完成时间。

延迟是最初的刺激和反应的第一个指示之间的时间周期。延迟发生在处理基于网络的应用程序操作的几个点上:1)应用程序识别发起该操作的事件所需的时间;2)设置组件间交互所需的时间;3)将每个交互传递给组件所需的时间;4)处理这些组件上的每个交互所需的时间；5)在应用程序能够开始呈现可用结果之前，完成交互结果的充分传输和处理所需的时间。值得注意的是，尽管只有3)和5)表示实际的网络通信，但所有这五点都可能受到体系结构风格的影响。此外，每个用户操作的多个组件交互会增加延迟，除非它们并行发生。

完成是完成应用程序操作所花费的时间。完成时间取决于上述所有措施。操作完成时间和延迟之间的差异表示应用程序增量处理接收到的数据的程度。例如，可以在接收大图像时呈现大图像的Web浏览器提供的用户感知性能明显好于等到整个图像完全接收后再呈现的Web浏览器，尽管两者的网络性能相同。

需要注意的是，优化延迟的设计考虑通常会降低完成时间，反之亦然。例如，如果算法在产生编码转换之前对数据的重要部分进行采样，则数据流的压缩可以产生更有效的编码，从而缩短在网络上传输编码数据的完成时间。但是，如果这种压缩是为了响应用户操作而动态执行的，那么在传输之前缓冲大样本可能会产生不可接受的延迟。平衡这些权衡可能很困难，特别是当不知道接收方更关心延迟(例如，Web浏览器)还是完成(例如，Web spider)时。

（3）网络效率

关于基于网络的应用程序的一个有趣观察是，最佳的应用程序性能是在不使用网络的情况下获得的。这本质上意味着，对于基于网络的应用程序来说，最有效的架构风格是那些能够在可能的情况下有效地减少网络使用的风格，通过重用先前的交互(缓存)，减少与用户操作(复制数据和断开连接的操作)相关的网络交互的频率，或者通过将数据处理移动到更靠近数据源的地方(移动代码)来消除某些交互的需要。

各种性能问题的影响通常与应用程序的分布范围有关。一种风格在局部条件下的优点在面对全局条件时可能会变成缺点。因此，样式的属性必须与交互距离相关:在单个进程内、在单个主机上跨进程、在局域网(LAN)内或在广域网(WAN)上传播。当将跨WAN(其中涉及单个组织)的交互与跨Internet(涉及多个信任边界)的交互进行比较时，其他问题就变得明显了。

2、可扩展性

可伸缩性是指体系结构在活动配置中支持大量组件或组件之间交互的能力。可以通过简化组件、跨多个组件分发服务(分散交互)以及将交互和配置监控结果作为一个整体来控制，从而提高可伸缩性。风格通过确定应用程序状态的位置、分布的范围以及组件之间的耦合来影响这些因素。

可伸缩性还受到以下因素的影响:交互的频率、组件上的负载是随时间均匀分布还是出现峰值、交互是需要有保证的交付还是需要尽最大努力、请求是涉及同步处理还是异步处理、环境是受控的还是无政府的(即，您能信任其他组件吗?)

3、简洁性

体系结构风格诱导简洁性的主要方法是将关注点分离原则应用于组件内功能的分配。如果功能的分配使得单个组件基本上不那么复杂，那么它们将更容易理解和实现。同样，这种分离简化了对整个体系结构进行推理的任务。我选择将复杂性、可理解性和可验证性的特性放在简单性的一般属性下，因为它们对于基于网络的系统是密切相关的。

将通用性原则应用于体系结构元素还可以提高简单性，因为它减少了体系结构中的变化。连接器的通用性要求，于是产生了网络中间件。

4、可修改性

可修改性是指对应用程序体系结构进行更改的难易程度。可修改性可以进一步细分为可演化性、可扩展性、可定制性、可配置性和可重用性，如下所述。一个特别的关注点事基于网络的系统具有动态可修改性，即对已部署的应用程序进行修改，而无需停止和重新启动整个系统。

即使有可能构建一个完全符合用户需求的软件系统，这些需求也会随着时间而变化，就像社会随着时间而变化一样。由于参与基于网络的应用程序的组件可能分布在多个组织边界上，因此系统必须为渐进和碎片化的更改做好准备，在这种情况下，新旧实现共存，而不会阻止新实现利用其扩展功能。

（1）可演化性

可演化性表示组件实现可以在不负面影响其他组件的情况下进行更改的程度。组件的静态演化通常取决于实现对体系结构抽象的执行情况，因此对于任何特定的体系结构风格来说都不是独一无二的。但是，如果动态演化包含对应用程序状态的维护和位置的约束，则它可能受到样式的影响。用于从分布式系统的局部故障条件中恢复的相同技术[133]可用于支持动态进化。

（2）可扩展性

可扩展性被定义为向系统添加功能的能力。动态可扩展性意味着可以将功能添加到已部署的系统中，而不会影响系统的其余部分。可扩展性是通过减少组件之间的耦合而在体系结构风格中产生的，例如基于事件的集成。

（3）可定制性

可定制性指的是暂时专门化体系结构元素的行为的能力，这样它就可以执行不寻常的服务。如果组件服务的一个客户端可以扩展该组件，而不会对该组件的其他客户端产生不利影响，那么该组件就是可定制的。支持自定义的样式还可以提高简单性和可伸缩性，因为通过直接实现最频繁的服务并允许客户端定义不频繁的服务，可以减少服务组件的大小和复杂性。可定制性是由远程计算和按需代码风格引起的属性。

(4)可配置性

可配置性与可扩展性和可重用性都有关，因为它指的是部署后对组件或组件配置的修改，以便它们能够使用新的服务或数据元素类型。管道-过滤器和随需应变代码风格是两个例子，它们分别诱导了配置和组件的可配置性。

（5）可重用性

如果应用程序的组件、连接器或数据元素可以在其他应用程序中无需修改即可重用，那么可重用性就是应用程序体系结构的属性。在体系结构风格中引入可重用性的主要机制是减少组件之间的耦合(身份知识)和约束组件接口的通用性。统一的管道-过滤器样式举例说明了这些类型的约束。

5、可见性

架构风格还可以通过通用性限制接口或提供对监视的访问，从而影响基于网络的应用程序中交互的可见性。在这种情况下，可见性是指组件监视或调解其他两个组件之间的交互的能力。可见性可以通过共享交互缓存提高性能，通过分层服务提高可伸缩性，通过反射监视提高可靠性，通过允许中介(例如，网络防火墙)检查交互提高安全性。移动代理样式就是一个缺乏可见性可能导致安全问题的例子。

这种“可见性”一词的用法与Ghezzi等人的说法不同，后者指的是对开发过程的可见性，而不是对产品的可见性。

6、可移植性

如果软件可以在不同的环境中运行，那么它就是可移植的。诱导可移植性的样式包括那些将代码与要处理的数据一起移动的样式，例如虚拟机和移动代理样式，以及那些将数据元素约束为一组标准化格式的样式。

7、可靠性

从应用程序体系结构的角度来看，可靠性可以被看作是体系结构在组件、连接器或数据中存在部分故障时，在系统级别上易受故障影响的程度。样式可以通过避免单点故障、启用冗余、允许监视或将故障范围减小到可恢复的操作来提高可靠性。

摘自：《Architectural Styles and the Design of Network-based Software Architectures》------------Roy Thomas Fielding。