Roy Thomas Fielding Rest论文中关于“关键关注点的架构属性”的说明

关键关注点的架构属性
本节描述了用来对本论文中的架构风格进行区别和分类的架构属性。它并非想要成为一份全面的清单，我只包括了明显受到所调查的一组有限风格影响的那些属性。还有一些额外的属性，有时候也被称作软件质量（software qualities），在大多数软件工程的教科书中都会涉及到（例如[58]）。Bass等人[9]检查了与软件架构有关的质量。

2.3.1 性能（Performance）
聚焦于基于网络的应用的风格的主要原因之一，是因为组件交互对于用户可觉察的性能（user-perceived performance）和网络效率（network efficiency）来说是一个决定性因素。由于架构风格影响到这些交互的特性，选择合适的架构风格能够决定一个基于网络的应用部署的成败。一个基于网络的应用的性能首先取决于应用的需求，然后是所选择的交互风格，然后是实现的架构，最后是每个组件的实现。换句话说，应用软件都无法回避为了实现该软件的需求而付出的基本成本；例如，如果应用软件需要数据位于系统A，并由系统B来处理，那么该软件无法避免将数据从A移动到B。同样地，一个架构无法超越其交互模式所允许的效率。例如，将数据从A移动到B的多次交互的成本不可能少于单独一次从A到B的交互。最后，无论架构的质量如何，交互的速度再快也不可能比一个组件实现生产数据，它的接收者消费数据所需的总时间更快。

2.3.1.1 网络性能（Network Performance）
网络性能这个度量手段用来描述通信的某些属性。吞吐量（throughput）是信息（既包括应用的数据也包括通信负载）在组件之间转移的速率。负载（overhead）可分为初始设置（initial setup）的负载和每次交互的负载，这种区分有助于识别能够跨多个交互共享设置负载（分摊）的连接器。带宽（bandwidth）是在一个特定的网络连接之上可用的最大的吞吐量。可用带宽（usable bandwidth）是指应用实际可用的那部分带宽。风格对于网络性能的影响是通过影响每个用户动作的交互的数量和数据元素的粒度来实
现的。一种鼓励小型的强类型（strongly typed）交互的风格，对于一个在已知组件之间转移小型数据的应用来说会很有效率，但是会在包括了大型数据转移或协商接口（negotiatedinterfaces）的应用中导致过多的负载。同样地，一种通过多个组件之间协调来过滤大型数据流的风格，在主要需要小型的控制消息的应用中会显得不合时宜。

2.3.1.2 用户可觉察的性能（User-perceived Performance）
用户可觉察的性能与网络性能的区别是，一个动作的性能是根据其对于使用一个应用的用户的影响来度量，而不是根据网络移动信息的速率来度量。用户可觉察的性能的主要度量手段是延迟和完成时间。延迟（latency）是指从触发初次请求到得到第一个响应指示之间持续的时间。延迟会发生在基于网络的应用的处理过程的如下几个点上：

1) 应用识别出触发动作的事件所需的时间；

2) 在组件之间建立交互所需的时间；

3) 在组件间传输交互数据所需的时间；

4) 组件处理每个交互所需的时间；以及

5) 在应用能够呈现一个可用的结果之前，完成数据的转移和处理交互的结果所需的时间。重要的是要注意到，虽然只有在(3)和(5)中存在着真正的网络通讯，
但是以上所有五点均能够受到架构风格的影响。

此外，每个用户动作的多个组件交互也会增加延迟，除非它们能够并行处理。完成时间（completion）是完成一个应用动作所花费的时间。完成时间取决于所有上述
的延迟点。动作的完成时间和它的延迟之间的区别在于，延迟代表了一种应用增量处理正在接收的数据的程度。例如，一个能够在接收的同时显示一个大型图片的Web浏览器，与等待全部数据接收完之后才显示图片的Web浏览器相比，会提供好得多的用户可觉察性能，即使两者都具有相同的网络性能。重要的是要注意到，对延迟进行优化的设计常常会产生延长完成时间的副作用，反之亦然。例如，如果算法在产生已编码的转换之前，对数据的重要部分进行采样，则对于一段数据流的压缩就能够产生更加有效率的编码。对于跨越网络转移已编码的数据来说，这会导致更短的完成时间。然而，如果压缩是在响应用户动作的过程中以一种即时（on-the-fly）的方式来执行的，在转移之前缓存大型的采样数据会产生不可接受的延迟。平衡这些权衡是很困难的，特别是当不知道接收者是更关心延迟（例如，Web浏览器）还是更关心完成时间（例如，Web爬虫）的时候。

2.3.1.3 网络效率（Network Efficiency）
关于基于网络的应用的一个有趣的观察是：最佳的应用性能是通过不使用网络而获得的。这基本上意味着对于一个基于网络的应用，最高效的架构风格是那些在可能的情况下，能够有效地将对于网络的使用减到最少的架构风格。可以通过重用先前的交互（缓存）、减少与用户动作相关的网络交互（复制数据和关闭连接操作）、或者通过将对数据的处理移到距离数据源更近的地方（移动代码）来减少某些交互的必要性。各种性能问题的影响常常与应用的分布范围有关。一种风格在局部的场合下的优点当面对全局性的场合时也许会变成缺点。因此风格的属性必须受到与交互距离相关的限制：是在单个进程中还是在单个机器上的多个进程之间、是在一个区域网（LAN）内还是分布在广域网（WAN）上。是只涉及到一个组织，还是与跨Internet的交互相比，涉及到多个可信任的边界。

2.3.2 可伸缩性（Scalability）
可伸缩性表示在一个主动的配置中，架构支持大量的组件或大量的组件之间交互的能力。可伸缩性能够通过以下方法来改善：简化组件、将服务分布到很多组件（分散交互）、以及作为监视的结果对交互和配置进行控制。风格可以通过确定应用状态的位置、分布的范围以及组件之间的耦合度，来影响这些因素。可伸缩性还受到以下几个因素的影响：交互的频率、组件负担的分布是否平均或出现峰值、交互是必需保证送达（guaranteed delivery）还是只需要尽量送达（best-effort）、一个请求是否包括了同步或异步的处理、以及环境是受控的还是无法控制的（即，你是否可以信任其他组件？）。

2.3.3 简单性（Simplicity）
通过架构风格来导致简单性属性的主要方法是，对组件之间的功能分配应用分离关注点原则（principle of separation of concerns）。如果功能分配使得单独的组件足够简单，那么它们就更容易被理解和实现。同样地，这样的关注点分离也使得关于整体架构的推理任务变得更加容易。我选择将复杂性（complexity）、可理解性（understandability）和可验证性（verifiability）统一在简单性这个通用的属性中，是因为它们在基于网络的系统中有着密切的关联。对架构元素应用通用性原则（principle of generality）也有助于提高简单性，因为它减少了架构中的变数。对连接器应用通用性原则就产生了中间件[22]。

2.3.4 可修改性（Modifiability）
可修改性是对于应用的架构所作的修改的容易程度。可修改性能够被进一步分解为在下面所描述的可进化性、可扩展性、可定制性、可配置性和可重用性。基于网络的系统的一个特殊的关注点是动态的可修改性[98]，它要求在对一个已部署的应用做修改时，无需停止和重新启动整个系统。即使有可能建造一个完美地匹配用户需求的软件系统，那些需求也会随时间发生变化，就像社会的变化一样。因为基于网络的应用中的组件可能跨多个组织边界来分布，系统必须准备好应对逐渐的和片段的修改，一些旧的组件实现将会与一些新的组件实现共存，而不会妨碍新的组件实现使用它们的扩展功能。

2.3.4.1 可进化性（Evolvability）
进化性代表了一个组件实现能够被改变而不会对其他组件产生负面影响的程度。组件的静态进化通常依赖于其实现是否加强了架构的抽象，因此这并非是任何特定架构风格所独有的。然而，动态进化能够受到风格的影响，如果该风格包括了对于维护（maintenance）和应用状态的位置（location of application state）的约束。在分布式系统中用来从局部故障（partial failure）状况中恢复（recover from partial failure conditions）的相同技术 [133] 也能够被用来支持动态进化。

2.3.4.2 可扩展性（Extensibility）
可扩展性被定义为将功能添加到一个系统中的能力[108]。动态可扩展性意味着功能能够被添加到一个已部署的系统中，而不会影响到系统的其他部分。导致可扩展性的方法是在一个架构中减少组件之间的耦合，就像在基于事件的集成（event-based intergration）的例子中展示的那样。

2.3.4.3 可定制性（Customizability）
可定制性是指临时性地规定一个架构元素的行为的能力，然后该元素能够提供一种非常规的服务。一个组件是可定制的，是指一个客户能够扩展该组件的服务，而不会对该组件的其他客户产生影响[50]。支持可定制性的风格也可能会提高简单性和可扩展性，这是因为通过仅仅直接实现最常用的服务，允许客户端来定义不常用的服务，服务组件的尺寸和复杂性将会降低。可定制性是通过远程求值（remote evaluation）风格和按需代码（code-ondemand）风格所导致的一种架构属性。

2.3.4.4 可配置性（Configurability）
可配置性既与可扩展性有关，也与可重用性有关，因为它是指在部署后（postdeployment）对于组件，或者对于组件配置的修改，这样组件能够使用新的服务或者新的数
据元素类型。管道和过滤器风格和按需代码风格是两个可以分别为组件配置和组件带来可配置性的例子。

2.3.4.5 可重用性（Reusability）
可重用性是应用的架构的一个属性，如果一个应用的架构中的组件、连接器或数据元素能够在不做修改的情况下在其他应用中重用，那么该架构就具有可重用性。在架构风格中导致可重用性的主要机制是降低组件之间的耦合（对于其他组件的标识的了解）和强制使用通用的组件接口。统一管道和过滤器风格是这种约束（译者注：即，强制使用通用的组件接口）的例子。

2.3.5 可见性（Visibility）
风格也能够通过限制必须使用通用性的接口，或者提供访问监视功能的方法，来影响基于网络的应用中交互的可见性。在这种情况下，可见性是指一个组件对于其他两个组件之间的交互进行监视或仲裁的能力。可见性能够通过以下方式改善性能：交互的共享缓存、通过分层服务提供可伸缩性、通过反射式监视（reflective monitoring）提供可靠性、以及通过允许中间组件（例如，网络防火墙）对交互做检查提供安全性。移动代理风格（mobile agentstyle）是缺乏可见性可能会导致安全问题的一个例子。这种对于术语“可见性”的使用方法与Ghezzi等人[58]的使用方法存在着区别，他们所说的可见性是对开发过程而言的，而非对产品而言的。

2.3.6 可移植性（Portability）
如果软件能够在不同的环境下运行，软件就是可移植的[58]。会导致可移植性属性的风格包括那些将代码和代码所要处理的数据一起移动的风格，例如虚拟机和移动代理（mobileagent）风格；以及那些限制只能使用标准格式的数据元素的风格。

2.3.7 可靠性（Reliability）
从应用的架构角度来说，可靠性可以被看作当在组件、连接器或数据之中出现部分故障时，一个架构容易受到系统层面故障影响的程度。架构风格能够通过以下方法提高可靠性：避免单点故障、增加冗余、允许监视、以及用可恢复的动作来缩小故障的范围。

参考：Architectural Styles and the Design of Network-based Software Architectures http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm   以及中文版的翻译 http://www.redsaga.com/opendoc/REST_cn.pdf