【软件体系结构】架构风格与基于网络应用软件的架构设计：Roy Tomas Fielding 博士
这篇随笔主要包括两方面：对基础知识点的梳理；以问答的形式加强理解。
（其中问答1-13是来源于网上，后续1-51来源于课本+PPT）
摘要
以下所谈及的软件体系结构是定义了一个框架，通过架构风格来理解软件架构，展示了使用架构风格来指导基于网络应用的架构设计。根据不同的架构风格在为分布式超媒体设计的架构中产生的架构属性，来对这些架构风格进行分类。然后是REST(表述性状态移交)架构风格，描述使用 REST 来指导现代 Web 架构的设计和开发。
绪论
复杂的系统被划分为独立的组件，组件通过相互通信来执行想要完成的任务。软件架构探索的就是如何划分系统、标识组件、组件之间的通信、信息的表达、组成系统的元素的进化。以及上诉内容使用形式化和非形式化的符号加以描述。
软件研究的是对软件设计 进行分类和开发 设计方法学。为一组相互协作的架构约束取一个名字，就是一种架构风格。
前三章就是通过架构风格来理解软件架构的框架，展示使用架构风格指导基于网络应用软件的架构设计。
第5章是 REST，强调组件交互的可伸缩性、接口的通用性、组件的独立部署、以及用来减少交互延迟、增强安全性、封装遗留系统的中间组件。
第一章 软件架构
1. 软件架构是一个软件系统在其运行过程中某个阶段的运行时元素的抽象。一个系统可能由很多层抽象和很多个运行阶段组成，每一个抽象和运行阶段都有自己的软件架构。核心是抽象原则：即通过封装来隐藏系统的一些细节，从而更好地识别和支持系统的架构属性。软件系统通常会有多个运行阶段：启动、初始化、正常处理、重新初始化和停止，每个运行阶段都有自己的架构。
2. 软件架构是由一些架构元素(Elements)（组件、连接器和数据）的配置来定义的，这些元素之间的关系受到约束，以获得所期待的一组架构属性。架构元素包括处理元素、数据元素、连接元素，其形式由元素的属性和元素之间的关系来定义。
组件(Components)是软件指令和内部状态的抽象单元，通过其接口提供数据的转换能力。这样定义是为了将组件和位于连接器中的软件作区分。
连接器(Connectors)是对于组件之间的通讯、合作或者协作进行仲裁的一种抽象机制。连接器的示例有：共享的表述、远程过程调用、消息传递协议和数据流。
数据(Data)是组件通过连接器接收或发送的信息元素。
3. 配置(Configurations)是在系统运行期间的组件、连接器和数据之间的架构关系的结构。三个语义分类对系统进行描述：组件——计算的所在地；连接器——定义组件之间的交互；配置——相互交互的组件和连接器的集合。
4. 架构属性(Properties)包括对组件、连接器和数据的选择和排列所产生的所有属性。包括功能属性和非功能属性。
5. 架构风格(Styles)是一组相互协作的架构约束，这些架构约束限制了架构元素的角色和功能，以及在任何一个遵循该架构风格的架构中允许存在的元素之间的关系。每一种架构风格都为组件的交互提供了一种抽象，并且通过忽略架构中其余部分的偶然性细节，来捕获一种交互模式的本质特征。
6. 模式和模式语言(Patterns and Pattern Languages)用来描述重复出现的抽象。模式既是一个过程也是一个事物；既是对一个活着的事物的描述，也是对生成这个事物的过程的描述。
7. 视图(Views)，三种重要的软件架构视图：处理、数据、连接。处理视图侧重于流经组件的数据流，以及组件之间连接的那些与数据相关的方面。数据视图侧重于处理的流程，而不是连接器。连接视图侧重于组件之间的关系和通信的状态。
8. 设计模式更倾向于面对特定的问题。
后续两章是使用了一种分类方法学来调查公共的架构风格，这种分类方法学侧重于架构属性，这些架构属性是在将架构风格应用于基于网络的超媒体架构时所产生的。
第二章 基于网络应用的架构
1. 区分分布式系统和基于网络系统：分布式系统在用户看来好像是普通的集中式系统，但是运行在多个独立的 CPU 之上。基于网络的系统有能力跨越网络运行，但是这一点无需表达为对用户透明的方式。
应用软件代表的是系统中能够“理解业务”的那部分功能。
2. 评估应用软件架构的设计
3. 关键关注点的架构属性
性能
网络性能(Network Performance)：吞吐量(throughput)是信息在组件之间移交的速率。带宽(bandwidth)是在特定网络连接上可用的最大吞吐量。可用带宽(usable bandwidth)是指应用实际可用的那部分带宽。
用户感知性能(User-perceived Performance)：主要度量手段是延迟(latency)和完成时间(completion time)。延迟是指最初的触发请求到得到最早的响应指示之间持续的时间。完成时间是完成一个应用动作所花费的时间。
网络效率(Network Efficiency)：只有在可能的情况下有效地将对于网络的使用减到最少，才是最高效的架构风格。
可伸缩性(Scalability)：通过主动的配置，一个架构支持大量的组件或大量组件之间的交互的能力。改善可伸缩性：简化组件、将服务分布到很多组件(去交互去中心化)、以及根据监视获得的信息对交互和配置加以控制。架构风格可以通过确定应用状态的位置、分布的范围以及组件之间的耦合度，来影响上述这些因素。还受到：交互的频率、组件负载随时间的分布是平均的还是存在峰值、交互是保证送达还是只需要尽量送达、一个请求是否包括同步或异步处理、以及环境是受控的还是无法控制的。
简单性(Simplicity)：对组件之间的功能分配分离关注点原则，如果功能分配使得单独的组件足够简单，那么理解和实现这些组件就会更加容易。对连接器应用通用性原则就产生了中间件。
可修改性(Modifiability)：是对于应用的架构作出改变的容易程度。
可进化性(Evolvability):
可扩展性(Extensibility):
可定制性(Customizability):
可配置性(Configurability):
可重用性(Reusablity):
可见性
可移植性
可靠性
第三章 基于网络应用的架构风格
1. 分类方法学
基于一些架构风格所产生的架构属性来对架构风格进行分类，才能提供有用的设计指导。
2. 数据流风格(Data-flow Styles)
管道和过滤器(Pipe and Filter, PF): 这里的架构约束是一个过滤器必须完全独立于其他过滤器（零耦合）。架构属性：简单性；可重用性；可扩展性；可进化性；可验证性；用户感知的性能；可配置性。缺点：通过长管道会导致延迟增加；如过滤器不能增量地处理输入，就只能批量的顺序处理，此时不允许交互；无法与其环境进行交互；如解决的问题不适合使用数据流模式，这些架构属性会降低用户感知的性能。
统一管道和过滤器(Uniform Pipe and Filter, UPF): 增加约束所有过滤器必须具有相同的接口。缺点：数据转换回原来的格式或者原来的格式转换为其他格式，这个约束会降低网络性能。
3. 复制风格(Replication Styles)
复制仓库(Replicated Repository, RR): 多进程提供相同服务，来改善数据的可访问性(accessibility of data)和服务的可伸缩性(scalability of service)。cvs,git。优点：改善了用户感知性能。简单性是不确定的，保证维护一致性。
缓存(Cache, $): 复制个别请求，以便可以被后面的请求重用。出现在数据集远远超过单个客户端的容量的情况。可以执行延迟复制(lazy replication)--有用的数据项和主动复制(active replication)--预测请求。将缓存风格与客户-无状态-服务器风格(client-stateless-server style)结合后，就形成了一种基于网络的架构风格。
4. 分层风格(Hierarchical Styles)
客户-服务器(Client-Server, CS): 客户是一个触发进程(triggering process); 服务器是一个反应进程(reactive process)。功能的适当分离会简化服务器组件，从而提高可伸缩性。
分层系统(Layered System, LS)和分层-客户-服务器(Layered-Client-Server, LCS): 每一层为在其之上的层提供服务，并且使用在其之下的层所提供的服务。内部层对相邻外部层之外的所有层被隐藏的，从而改善了可进化行和可重用性，TCP/IP 和 OSI 协议栈，以及硬件接口库。缺点：增加了处理数据的开销和延迟，降低了用户感知的性能。而 LCS 是增加了代理(proxy)组件和网关(geteway)组件。代理组件是一个共享服务器，接受请求、处理并转发给服务器；网关接受请求、处理并转发给“内部层”的服务器，多个层可实现负载均衡和安全性检查。
客户-无状态-服务器(Client-Stateless-Server, CSS): 增加额外约束：在服务器组件之上不允许有会话状态(session state)，会话状态应全部保存在客户端。这些约束改善了可见性、可靠性和可伸缩性等三个架构属性。缺点：降低网络的性能，因为不能将状态保存在服务器上的共享上下文中，发送了很多重复的数据（每次交互的开销）。
客户-缓存-无状态-服务器(Client-Cache-Stateless-Server, C$SS): 增加缓存的好处是能部分或全部消除一些交互，从而提高效率和用户感知的性能。案例：Sun公司的 NFS。
分层-客户-缓存-无状态-服务器(Layered-Client-Cache-Stateless-Server, LC$SS): 案例：互联网的域名系统(DNS)。优点和缺点是 LCS 风格和 C$SS风格的优点和缺点的集合。
远程会话(Remote Session, RS): 每个客户在服务器上启动一个会话，然后调用服务器的一系列服务，最后退出会话。优点：集中维护服务器上的接口更加容易；扩展功能时，可减少已部署客户的不一致问题；交互利用服务器上的上下文，还能提高效率。缺点：保存的应用状态，降低了服务器的可伸缩性；监视程序要知道服务器的完整状态，降低了交互的可见性。
远程数据访问(Remote Data Access, RDA): 用户发送数据库查询(例如SQL)请求服务器，服务器分配工作空间并执行这个查询，将产生一个巨大的结果集。客户进一步操作这个结果集或每次获取其中的一部分。优点：服务器端多次迭代，减小一个巨大的数据集，不用通过网络传输完整的数据集，改善了效率；标准的查询语言改善了可见性。缺点：要理解数据库操作概念，缺少简单性；服务器上保存上下文，降低了可伸缩性；部分故障导致工作空间处于未知状态，可靠性蒙受了损失。
5. 移动代码风格(Mobile Code Styles)
使用了移动性，以便动态地改变处理过程与数据源或结果目的地之间的距离。数据成员被动态地转换为一个组件。
虚拟机(Virtual Machine, VM): 代码必须以某种方式来执行，首选地方式是在一个满足了安全性和可靠性关注点的受控环境中执行。好处是：改善了可扩展性：在一个特定平台上将指令(instruction)和实现(implementation)(可移植性)分离开；会降低可见性：难以简单地通过查看代码了解可执行代码将要做什么事情；降低了简单性：对求值环境进行管理；
远程求值(Remote Evaluation, REV): 假设将要被执行的代码时处在一种受保护的环境中，除了正在被使用的资源，对同一服务器下的其他用户不产生影响。优点：能够定制服务器组件的服务，这改善了可扩展性和可定制性；代码修改动作，以适应服务器内部的环境，能得到更好的效率；缺点：可伸缩性降低了，缺乏可见性导致明显的部署问题。
按需代码(Code on Demand, COD): 向远程服务器发送请求，以获取如何处理资源的代码。优点：为一个已部署的客户添加功能，改善了可扩展性和可配置性；代码修改动作，以适应客户端的环境，并在本地与用户交互，能得到更好的用户感知和性能；由于管理求值环境，简单性降低了，可通过客户端的静态功能得到补偿；服务器将工作交给了客户，从而改善了服务器的可伸缩性。缺点：服务器发送代码而不是简单数据，因此缺乏可见性；如果客户端无法信任服务器，缺乏可见性会导致明显的部署问题。
分层-按需代码-客户-缓存-无状态-服务器(Layered-Code-on-Demand-Client-Cache-Stateless-Server, LCODC$SS): 优点和缺点是 COD 和 LC$SS 的优点缺点。
移动代理(Mobile Agent, MA): 一个完整的计算组件，与它的状态、必需的代码、执行任务所需的数据一起被移动到远程站点。优点：对于何时求值，具有更大的活力；
6. 点对点风格（对等风格）(Peer-to-Peer Styles)
基于事件的集成(Event-based Integration, EBI): 也称作隐式调用(implicit invocation)风格或者事件系统(event system)风格。一个组件能够发布（或广播）一个或者多个事件，系统中的其他组件能够注册对于该事件类型的兴趣，由系统本身来调用所有已注册的组件。对于以大数据监视(data monitoring)为主，而不是以数据获取(data retrieval)为主的应用，EBI 通过使得轮询式交互(polling interactions)变得不再必要，能够提高效率。可伸缩性问题：通知的数量、由通知引发其他组件广播而导致的事件风暴(event storms)、在通知传送系统中的单点故障。这些问题能通过使用分层系统和事件过滤来改善，但损害了简单性。难以预料一个动作将会产生什么样的响应（缺乏可理解性），事件通知并不适合交换大粒度的数据，而且也不支持从局部故障中恢复。
C2: 将 EBI 和 LCS 相结合。异步通知消息向下传送，异步请求数据向上传送，这是组件之间通信的唯一方式。加强了对高层依赖的松耦合和底层实现的零耦合。连接器的职责：消息的路由和广播；消息的过滤。
分布式对象(Distributed Objects, DO): 是用来隔离正在被处理的数据，不支持数据流。
被代理的分布式对象(Brokered Distributed Objects, BDO): 使用在包括了对已封装服务(例如硬件设备)的远程调用的应用中。
7. 局限性
这里的评估是特别为分布式超媒体的需求而量身定制的。
对于架构属性的分组。
8. 相关工作
架构风格和模式的分类方法。
分布式系统和编程范例。
中间件。
9. 小结
第五章 表述性状态移交
1. 推导 REST
Web 架构背后的设计基础理论：由一组应用于架构中元素之上的架构约束组成的架构风格。
从“空”风格开始：“空”风格仅仅是一个空的架构约束集合。从架构的观点来看，空风格描述了一个组件之间没有明显边界的系统。随着架构约束的逐渐被加入，已应用的架构约束如何将架构的过程视图区分开。
客户-服务器：原则是分离关注点。分离用户界面和数据存储，改善了用户界面跨多个平台的可移植性；简化服务器组件，改善了系统的可伸缩性。使得组件可独立地进化。
无状态：每个请求都必须包含理解该请求所必需的所有信息，不能利用存储在服务器端的上下文，会话状态要全部保存在客户端。产生了可见性、可靠性和伸缩性这三个架构属性。缺点是：不能把状态数据保存在服务器上的共享上下文中，增加了发送请求的的重复数据，会降低网络性能。应用状态放在客户端还降低了服务器对于一致的应用行为的控制能力。
缓存：缓存架构约束要求一个请求的响应中的数据被隐式地或显示地标记为可缓存或不可缓存的。优点：有可能部分或全部消除一些交互，从而通过减少一系列交互的平均延迟时间，来提高效率、可伸缩性和用户感知的性能。缺点：如果缓存中陈旧的数据与 将请求直接发送到服务器 得到的数据差别很大，那么缓存会降低可靠性。
统一接口：REST接口被设计为可以高效地移交大粒度地超媒体数据，并针对 Web 的常见情况做了优化，但是也导致该接口对于其他形式的架构交互而言并不是最优的。REST 由四个接口架构约束来定义：资源的识别、通过表述来操作资源、自描述的信息、以及作为应用状态引擎的超媒体。
分层系统：将不常用功能转移到一个共享中间组件中，从而简化组件的实现。中间组件还能够通过支持跨多个网络和处理器的负载均衡，来改善系统的可伸缩性。缺点：增加了数据处理的开销和延迟，因此降低了用户感知的性能。通过在中间层中使用共享缓存来弥补这一缺点。
按需代码：通过下载并执行 applet 形式或脚本形式的代码，对客户端的功能进行扩展。
风格推导小结：
一些初步的问题（含解答）：
简答题：
1. 什么是软件体系结构？软件体系结构为什么重要？核心研究内容是？三个基本要素是什么？
（1）软件体系结构是一个设计，它包括所建立系统中的各元素的描述、元素之间的交互、指导装配的范例和对范例的约束。 可以这么回答：① 软件架构是一个软件系统在其运行过程中某个阶段的运行时元素的抽象。一个系统可能由很多层抽象的和很多个运行阶段组成，每一个抽象和运行阶段都有自己的软件架构。② 软件架构是由一些架构元素（组件、连接器和数据）的配置来定义的，这些元素之间的关系受到约束，以获得所期待的一组架构属性。 （2）①是软件相关人员进行交流的手段；②是一种高层次的设计复用手段；③是早期关键设计决策的体现。 （3） （4）软件体系结构 = 构件 + 连接件 + 约束。软件体系结构是具有一定形式的结构化元素，即构件的集合，包括组件、数据和连接器。组件负责对数据进行加工，数据是被加工的信息，连接器是把体系结构的不同部分(组件)连接起来。这一定义注重区分组件、数据和连接器，这一方法在其他的定义和方法中基本上得到保持。
2. 有哪些架构元素？各架构元素关系是怎样的？
有组件、连接器和数据。组件是软件指令和内部状态的抽象单元，通过其接口提供数据的转换能力；连接器是对于组件之间的通讯、配合或者协作进行仲裁的一种抽象机制；数据是组件通过连接器接收或发送的信息元素。
3. 什么是架构风格？有哪些架构风格？各架构风格都遵循怎样的架构约束？
架构风格是一组相互协作的架构约束，这些架构约束限制了架构元素的角色和功能，以及在任何一个遵循该架构风格的架构中允许存在的元素之间的关系。
也可以说：架构风格是一种用来对架构进行分类和定义它们的公共特征的机质；每一种架构风格都为组件的交互提供了一种抽象。
有数据流风格(Data-flow Styles)的管道和过滤器(Pipe and Filter, PF)和统一管道和过滤器(Uniform Pipe and Filter)
复制风格(Replication Styles)的复制仓库(Replicated Repository, RR)和缓存(Cache, $)
分层风格(Hierarchical Styels)的客户-服务器(Client-Server, CS)、分层系统(Layered System, LS)和分层-客户-服务器(Layered-Client-Server, LCS)、客户-无状态-服务器(Client-Stateless-Server, CSS)、客户-缓存-无状态-服务器(Client-Cache-Stateless-Server, C$SS)、分层-客户-缓存-无状态-服务器(Layered-Client-Cache-Stateless-Server, LC$SS)、远程会话(Remote Session, RS)、远程数据访问(Remote Data Access, RDA)
移动代码风格(Mobile Code Style): 虚拟机(Virtual Machine, VM)、远程求值(Remote Evaluation, REV)、按需代码(Code on Demand, COD)、分层-按需代码-客户-缓存-无状态-服务器(Layered-Code-on-Demand-Client-Cache-Stateless-Server, LCODC$SS)、移动代理(Mobile Agent, MA)
点对点风格(Peer-to-Peer Styles): 基于事件的集成(Event-based-Integration, EBI)、C2、分布式对象(Distributed Objects, DO)、被代理的分布式对象(Brokered Distributed Objects, BDO)
4. 常用的软件体系结构评估的方法有哪些？
体系结构权衡分析法；软件体系结构分析法；中间设计的积极评审。
4. 软件体系结构与软件框架的区别？
(1) 呈现形式不同：体系结构的呈现形式是一个设计规约，而框架则是程序代码。
(2) 目的不同：体系结构的首要目的大多是指导一个软件系统的实施与开发；而框架的首要目的是为复用。因此，一个框架可有其体系结构，用于指导该框架的开发，反之不然。
4. 简述为什么要学习设计模式？
设计模式：是指在软件开发中，经过验证的，用于解决在特定环境下、重复出现的、特定问题的解决方案。
① 设计模式已经成为软件开发人员的“标准词汇”；
② 学习设计模式是个人技术能力的提高捷径；
③ 不用重复发明轮子。
5. 什么是设计模式？它与风格、框架有什么区别与联系？设计模式一般用来解决什么样的问题？设计模式可以分为哪三个层次？
（1）一些设计面向对象的软件开发的经验总结，就是系统的命名、解释和评价某一个重要的面向对象的可重现的面向对象的设计方案。 简单总结：设计模式是对通用设计问题的重复解决方案。
（2）软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式；软件框架是整个或部分系统的可重用设计；模式比框架更加抽象，框架是模式的特例化，设计模式被实现成为框架后，可以极大的减轻从设计到实现的鸿沟；利用了模式的框架比没有利用模式的框架更容易理解、更能被设计与实现重用；通常成熟的框架包含了多种设计模式；一个框架不仅可以具体实现一个模式，还可以具体的实现多个模式；设计模式与风格两者为近义词，通常情况下可以互相通用；风格主要是指大的，宏观的设计。模式既可宏观，也可微观。
（3）同一问题的不同表象。
（4）
6. 简述管道-过滤器(Pipe and Filter, PF)风格，结构特点。
每个组件都有一组输入和输出，组件读入数据流，经过数据处理，然后产生输出数据流。
① 使得组件具有良好的隐蔽性和高内聚、低耦合的特点；
② 允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成；
③ 支持软件重用；
④ 系统维护和增强系统性能简单；
⑤ 允许对一些如吞吐量、死锁等属性的分析；
⑥ 支持并行支持；
不利因素：
① 通常导致进程成为批处理的结构。
② 不适合处理交互的应用。
③ 因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。
7. 简单介绍基于事件的集成(Event-based Integration, EBI)风格，并分析其优缺点。
基于事件的集成(Event-based Integration, EBI): 也称作隐式调用(implicit invocation)风格或者事件系统(event system)风格。一个组件能够发布（或广播）一个或者多个事件，系统中的其他组件能够注册对于该事件类型的兴趣，由系统本身来调用所有已注册的组件。优点：对于以大数据监视(data monitoring)为主，而不是以数据获取(data retrieval)为主的应用，EBI 通过使得轮询式交互(polling interactions)变得不再必要，能够提高效率。缺点：可伸缩性问题：通知的数量、由通知引发其他组件广播而导致的事件风暴(event storms)、在通知传送系统中的单点故障。这些问题能通过使用分层系统和事件过滤来改善，但损害了简单性。难以预料一个动作将会产生什么样的响应（缺乏可理解性），事件通知并不适合交换大粒度的数据，而且也不支持从局部故障中恢复。
8. 简述使用层次架构约束的架构风格有哪些，以及各自适用的设计问题。分析分层系统的优缺点。
分层风格(Hierarchical Styels)的客户-服务器(Client-Server, CS)、分层系统(Layered System, LS)和分层-客户-服务器(Layered-Client-Server, LCS)、客户-无状态-服务器(Client-Stateless-Server, CSS)、客户-缓存-无状态-服务器(Client-Cache-Stateless-Server, C$SS)、分层-客户-缓存-无状态-服务器(Layered-Client-Cache-Stateless-Server, LC$SS)、远程会话(Remote Session, RS)、远程数据访问(Remote Data Access, RDA)
9. 请简述 MVC，介绍各自的作用和用途。
MVC 是三个单词的缩写，分别为：模型(Model)，视图(View)和控制(Controller)。MVC 模式的目的就是实现 Web 系统的职能分工。Model 是应用对象，所有的操作都在这里实现，它若需要取得视图中的对象或更新视图，而通过控制器来进行处理。View 是模型在屏幕上的表示，模型在进行操作后，其结果是通过视图显示的。Controller 用于管理用户与视图发生的交互，定义用户界面对用户输入的响应方式。一旦用户需要对模型进行处理，不能直接执行模型，而必须通过控制器间接实现的。
10. 请简述虚拟机（VM）架构风格，这类软件主要由哪几个部分组成？介绍其作用和用途。
虚拟机风格也称为“解释器”（Interpreters）风格，其特点是通过软件手段建立一个虚拟的机器平台，并在该平台上解释运行所谓的“程序”代码。构成: 正在被解释的程序、虚拟机引擎构件、用来保存被解释程序的状态的构件、用来保存虚拟机引擎状态的构件。
11. 简述 C/S 架构风格，并分析其优缺点。
C/S 风格是最为常见的架构风格。服务器组件提供了一组服务，并监听对这些服务的请求；客户组件通过一个连接器将请求发送给服务器，希望执行一个服务；服务器可以拒绝这个请求，也可以执行这个请求并将响应发送给客户。
12. 简述面向对象体系结构，并画出面向对象体系结构图。
面向对象体系结构中，把系统看作是由一些对象集合组成（而不是函数或方法），消息从一个对象发送到另一个对象。每个对象都有其功能。一个对象是数据以对数据操作的封装体，外界通过接口与其进行交互。
13. 关键关注点的架构属性有哪些？并简单介绍这些架构属性。
性能
网络性能(Network Performance)：吞吐量(throughput)是信息在组件之间移交的速率。带宽(bandwidth)是在特定网络连接上可用的最大吞吐量。可用带宽(usable bandwidth)是指应用实际可用的那部分带宽。
用户感知性能(User-perceived Performance)：主要度量手段是延迟(latency)和完成时间(completion time)。延迟是指最初的触发请求到得到最早的响应指示之间持续的时间。完成时间是完成一个应用动作所花费的时间。
网络效率(Network Efficiency)：只有在可能的情况下有效地将对于网络的使用减到最少，才是最高效的架构风格。
可伸缩性(Scalability)：通过主动的配置，一个架构支持大量的组件或大量组件之间的交互的能力。改善可伸缩性：简化组件、将服务分布到很多组件(去交互去中心化)、以及根据监视获得的信息对交互和配置加以控制。架构风格可以通过确定应用状态的位置、分布的范围以及组件之间的耦合度，来影响上述这些因素。还受到：交互的频率、组件负载随时间的分布是平均的还是存在峰值、交互是保证送达还是只需要尽量送达、一个请求是否包括同步或异步处理、以及环境是受控的还是无法控制的。
简单性(Simplicity)：对组件之间的功能分配分离关注点原则，如果功能分配使得单独的组件足够简单，那么理解和实现这些组件就会更加容易。对连接器应用通用性原则就产生了中间件。
可修改性(Modifiability)：是对于应用的架构作出改变的容易程度。
可进化性(Evolvability):
可扩展性(Extensibility):
可定制性(Customizability):
可配置性(Configurability):
可重用性(Reusablity):
可见性
可移植性
可靠性
一些基础性问题
1. 为什么要学习软件体系结构？
① 软件体系结构是软件运行时元素（run-time elements）的抽象
② 分析软件运行时元素的抽象，可以得到一些常见的模型
③ 模型(Model)是对现实的简化
④ 通过建模（Modelling）或者提取出的模型能够更好地理解正在开发或者已经存在的系统
2. 什么是软件架构？
软件架构是一个软件系统在其运行过程中某个阶段的运行时元素的抽象。 一个系统可能由很多层抽象和很多个运行阶段组成，每一个抽象和运行阶段都有自己的软件架构。
软件架构是由一些架构元素(Elements)（组件、连接器和数据）的配置来定义的，这些元素之间的关系受到约束，以获得所期待的一组架构属性。
3. 简述配置。
配置是在系统运行期间的组件、连接器和数据之间的架构关系的结构。
4. 简述属性。
① 软件架构的架构属性集合包括了对组件、连接器和数据的选择和安排所导致的所有属性
② 架构属性的例子包括了可以由系统获得的功能属性和非功能属性，例如：演进的相对容易程度、组件的可重用性、效率、动态扩展能力；这些常常被称作品质属性。
5. 简述风格。
① 一种架构风格是一组协作的架构约束，这些约束限制了架构元素的角色和功能，以及在任何一个遵循该风格的架构中允许存在的元素之间的关系
② 风格是一种用来对架构进行分类和定义它们的公共特征的机制。每一种风格都为组件的交互提供了一种抽象。
6. 简述设计模式和模式语言。
① 设计模式被定义为一个重要且重复出现的系统构造。
② 模式语言是一种以指导模式应用的结构组织的模式系统
③ 模式的设计空间包括特定于面向对象编程技术的实现问题，例如类继承和接口组合，以及架构风格解决的更高级别的设计问题
④ 一般来说，一个模式，或多个集成模式中的模式语言，可以被认为是实现对象之间所需交互集的方法。 换句话说，模式定义了通过遵循设计和实现选择的路径来解决问题的过程。
⑤ Alexander 的设计理念是确定目标文化共有的生活模式，并确定需要哪些建筑约束来区分给定空间，从而使所需的模式能够自然发生。 这种模式存在于多个抽象级别和所有规模。
7. 简述架构模式。
① 架构模式表达了软件系统的基本结构组织模式。
② 它们提供了一组预定义的子系统。 明确他们的职责，并包括组织他们之间关系的规则和指南。
③ 架构模式代表了我们模式系统中的最高级别模式。 它们帮助您指定应用程序的基本结构。 随后的每一个开发活动都受这种结构的支配——例如，子系统的详细设计、系统不同部分之间的通信和协作，以及它的后期扩展。
8. 简述视图。
除了一个系统内的许多架构，以及组成架构的多种架构风格之外，还可以从许多不同的角度来看待一个架构。
① Perry 和 Wolf [105] 描述了软件架构中的三个重要视图：处理视图、数据视图和连接视图。
② 处理视图强调通过组件的数据流以及组件之间关于数据的连接的某些方面。
③ 数据视图强调处理流程，较少强调连接器。
③ 连接视图强调组件之间的关系和通信状态。
9. 简述基于网络的架构和软件架构有什么区别？
基于网络的架构中，组件之间的通信仅限于消息传递(message passing)或者消息传递的等价物(如果在运行时，基于组件的位置能够选择更加有效的机制的话)
10. 简述基于网络的系统与分布式系统的区别。
① 分布式系统在用户看来像是普通的集中式系统，但是运行在多个独立的CPU之上
② 基于网络的系统有能力跨越网络运转，但是这一点无需表达为对用户透明的方式。在某些情况下，还希望用户知道一个需要网络请求的动作和一个在他们的本地系统就能满足的动作之间的差别，尤其是当使用网络意味着额外的处理成本的时候。
11. 简述应用软件与网络软件的区别。
① 应用软件往往运行在操作系统之上，为了实现给定业务(Business)功能
② 网络软件的主要职责是在不同的主机之间运输比特流(或者数据)，但并关心为什么要运输这些比特流（这里所指的网络软件往往是操作系统的一部分，例如TCP/IP）
③ 基于网络的应用软件会使用网络软件提供的数据传输服务接口
12. 如何对应用软件架构进行评价？
① 架构是架构设计的实现，而非设计本身
② 按理说，一个架构能够根据其运行时的特征来加以评估，但是我们不得不在实现所有的候选架构设计之前，有一种对于这些候选架构设计的评估机制
③ 为了评估一个架构设计，需要检查隐藏在系统约束背后的设计基本原理，并且将从那些约束继承而来的属性与目标应用的目的进行比较
④ 第一个层面的评估由应用的功能需求来设定
⑤ 在满足功能需求的基础上，对多个可供选择的候选架构再考虑非功能架构属性。每个架构都会以不同的程度支持各种识别出的系统所必需的非功能架构属性。
13. 请简述有哪些架构属性？
（1）性能
① 网络性能
吞吐量：是信息（既包括应用的数据也包括通信负载）在组件之间转移的速率
开销
带宽：是在一个特定的网络连接之上可用的最大的吞吐量
可用带宽：是指应用实际可用的那部分带宽
② 用户可觉察性能
延迟：是指从触发初次请求到得到第一个响应指示之间持续的时间
延迟抖动
完成时间：是完成一个应用动作所花费的时间
③ 网络效率
对于一个基于网络的应用，最佳的应用性能是通过不使用网络而获得的。这意味着对于一个基于网络的应用，最高效的架构风格是那些在可能的情况下，能够有效地将对于网络的使用减到最少的架构风格。可以通过重用先前的交互（缓存）、减少与用户动作相关的网络交互（复制数据和关闭连接操作）、或者通过将对数据的处理移到距离数据源更近的地方（移动代码）来减少某些交互的必要性
各种性能问题的影响常常与应用的分布范围有关.
（2）可伸缩性
可伸缩性表示在一个主动的配置中，架构支持大量的组件或大量的组件之间交互的能力。
可伸缩性能够通过以下方法来改善：简化组件、将服务分布到很多组件(分散交互)、以及作为监视的结果对交互和配置进行控制。风格可以通过确定应用状态的位置、分布的范围以及组件之间的耦合度，来影响这些因素。
可伸缩性还受到以下几个因素的影响：交互的频率、组件负担的分布是否平均或出现峰值、交互是必需保证送达(guaranteed delivery)还是只需要尽量送达(best-effort)、一个请求是否包括了同步或异步的处理、以及环境是受控的还是无法控制的（即，是否可以信任其他组件？）
（3）简单性
通过架构风格来导致简单性属性的主要方法是，对组件之间的功能分配应用分离关注点原则
如果功能分配使得单独的组件足够简单，那么它们就更容易被理解和实现。同样地，这样的关注点分离也使得关于整体架构的推理任务变得更加容易
（4）可修改性
可修改性是对于应用的架构所作的修改的容易程度
可修改性能够被进一步分解为在下面所描述的可进化性、可扩展性、可定制性、可配置性和可重用性
基于网络的系统的一个特殊的关注点是动态的可修改性，它要求在对一个已部署的应用做修改时，无需停止和重新启动整个系统
（5）可见性
风格能够通过限制必须使用通用性的接口，或者提供访问监视功能的方法，来影响基于网络的应用中交互的可见性。在这种情况下，可见性是指一个组件对于其他两个组件之间的交互进行监视或仲裁的能力
可见性能够通过以下方式改善性能：交互的共享缓存、通过分层服务提供可伸缩性、通过反射式监视（reflective monitoring）提供可靠性、以及通过允许中间组件（例如，网络防火墙）对交互做检查提供安全性
（6）可移植性
软件可移植性是指软件能够在不同的环境下运行
会导致可移植性属性的风格包括那些将代码和代码所要处理的数据一起移动的风格，例如虚拟机和移动代理(mobile agent)风格；以及那些限制只能使用标准格式的数据元素的风格
（7）可靠性
从应用的架构角度来说，可靠性可以被看作当在组件、连接器或数据之中出现部分故障时，一个架构容易受到系统层面故障影响的程度
架构风格能够通过以下方法提高可靠性：避免单点故障、增加冗余、允许监视、以及用可恢复的动作来缩小故障的范围
14. 简述有哪些架构风格？
（1）Data-flow Styles
① Pipe and filter
② Uniform pipe and filter
（2）Replication Styles
① Replicated Repository
② RR Cache，$
（3）Hierarchical Styles
① Client-Server (CS)
② Layered System (LS) and Layered-Client-Server (LCS)
③ Client-Stateless-Server (CSS)
④ Client-Cache-Stateless-Server (C$SS)
⑤ Layered-Client-Cache-Stateless-Server (LC$SS)
⑥ Remote Session (RS) Remote Data Access (RDA)
（4）Mobile Code Styles
① Virtual Machine (VM)
② Remote Evaluation (REV)
③ Code on Demand (COD)
④ Layered-Code-on-Demand-Client-Cache-Stateless-Server (LCODC$SS)
⑤ Mobile Agent (MA)
（5）Peer-to-Peer Styles
① Event-based Integration (EBI)
② C2
③ Distributed Objects
④ Brokered Distributed Objects
15. 请说明什么是管道-过滤器风格？
在管道和过滤器风格中，每个组件（过滤器）读取其输入端上的数据流并在其输出端产生数据流，通常会对输入流应用转换并增量地处理它们，以便在完全处理输入之前能够开始输出。
约束是过滤器必须完全独立于其他过滤器（零耦合）：它不得与上行和下行数据流接口上的其他过滤器共享状态、控制线程或标识信息。
16. 请简述什么是统一的管道-过滤器风格？
统一的管道-过滤器风格添加了所有过滤器必须具有相同接口的约束。
这种风格的主要例子是在 Unix 操作系统中，其中过滤器进程有一个接口，由一个字符输入数据流（stdin）和两个字符输出数据流（stdout 和 stderr）组成。
17. 请简述复制仓库风格？
① 基于复制仓库风格的系统通过让多个进程提供相同的服务来提高数据的可访问性和服务的可扩展性。
② 这些去中心化的服务器交互，为客户提供只有一种中心化服务的错觉。
③ 分布式文件系统（如 XMS）和远程版本控制系统（如 CVS）是主要示例。
18. 请简述什么是缓存风格？
在缓存风格中发现了复制存储库的一个变体：复制单个请求的结果，以便它可以被以后的请求重用。
这种形式的复制最常出现在潜在数据集远远超过任何一个客户端的容量的情况下，如在 WWW 中，或者在不需要完全访问存储库的情况下。
延迟复制：发生在根据尚未缓存的请求响应复制数据时，依赖于引用的位置和兴趣的共性将有用的项目传播到缓存中以供以后重用
主动复制：可以通过基于预期请求预取可缓存条目来执行主动复制
19. 请简述什么是客户端-服务器风格？
在基于网络的应用程序的架构风格中，客户端-服务器风格是最常见的
提供一组服务的服务器组件侦听对这些服务的请求。
希望执行服务的客户端组件通过连接器向服务器发送请求。 服务器拒绝或执行请求并将响应发送回客户端。
客户端是一个触发过程； 服务器是一个响应进程。 客户端发出的请求会触发服务器的响应。 因此，客户端在其选择的时间启动活动； 它通常会延迟到它的请求得到服务。
另一方面，服务器等待发出的请求，然后对它们做出反应。 一个服务器通常是一个非终止进程，并且经常为多个客户端提供服务。
20. 简述什么是分层系统？
① 分层系统按层次结构组织，每一层为其上层提供服务并使用其下层的服务。
② 分层系统通过隐藏除相邻外层之外的所有内层来减少多层之间的耦合，从而提高可进化性和可重用性。
21. 简述什么是分层-客户-服务器风格？
① 尽管分层系统被认为是一种“纯粹的”风格，但它在基于网络的系统中的使用仅限于它与客户端-服务器风格的组合，以提供分层的客户端-服务器
② 分层客户端服务器向客户端服务器样式添加代理和网关组件。 代理充当一个或多个客户端组件的共享服务器，接收请求并将请求转发到服务器组件，并进行可能的转换。
③ 网关组件对于请求其服务的客户端或代理来说似乎是一个普通的服务器，但实际上是将这些请求转发到它的“内层”服务器，并可能进行转换。
④ 这些额外的中介组件可以添加到多层中，以向系统添加负载平衡和安全检查等功能。
22. 请简述客户端-无状态-服务器风格
① 客户端-无状态-服务器风格源自客户端-服务器，带有附加约束，即服务器组件上不允许有会话状态。
② 从客户端到服务器的每个请求都必须包含理解请求所需的所有信息，并且不能利用服务器上存储的任何上下文。 会话状态完全保存在客户端
23. 请简述什么是客户端-缓存-无状态-服务器风格
① 客户端-缓存-无状态-服务器风格通过添加缓存组件从客户端-无状态-服务器风格派生而来。
② 缓存充当客户端和服务器之间的中介，其中对先前请求的响应（如果它们被认为是可缓存的）可以重用以响应以后的请求，这些请求等效并且可能导致响应与缓存中的响应相同，如果请求被转发到服务器。
③ 有效利用这种风格的示例系统是 Sun Microsystems 的 NFS。
24. 请简述什么是分层-客户端-缓存-无状态-服务器风格？
① 通过添加代理和/或网关组件，layered-client-cache-stateless-server 风格源自 layered-client-server 和 client-cache-stateless-server。
② 使用 LC$SS 风格的示例系统是 Internet 域名系统 (DNS)
25. 请简述什么是远程会话风格？
① 远程会话风格是客户端-服务器的一种变体，它试图最小化客户端组件(而不是服务器组件)的复杂性或最大化可重用性。
② 每个客户端在服务器上发起一个会话，然后调用服务器上的一系列服务，最后退出会话。 应用程序状态完全保存在服务器上。
③ 当需要使用通用客户端（例如 TELNET）或通过模拟通用客户端的接口（例如 FTP）访问远程服务时，通常会使用此风格。
26. 请简述什么是远程数据访问？
① 远程数据访问风格是客户端-服务器的一种变体，它在客户端和服务器之间传播应用程序状态。
② 客户端以标准格式（例如 SQL）向远程服务器发送数据库查询。
③ 服务器分配工作空间并执行查询，这可能会导致非常大的数据集。
④ 然后客户端可以对结果集进行进一步的操作（例如表连接）或一次检索一个结果。 客户端必须了解服务的数据结构才能构建依赖于结构的查询。
27. 请简述什么是移动代码风格？
① 移动代码风格使用移动性来动态更改处理与数据源或结果目标之间的距离。
② 在架构级别引入了站点抽象，作为活动配置的一部分，以便考虑不同组件的位置。
③ 引入位置的概念可以在设计级别对组件之间的交互成本进行建模
28. 请简述什么是虚拟机架构风格？
① 所有移动代码风格的基础是虚拟机或解释器风格的概念。 代码必须以某种方式执行，最好在受控环境中执行，以满足安全性和可靠性问题，而这正是虚拟机风格所提供的。
② 它本身并不是基于网络的风格，但在与客户端-服务器风格（REV 和 COD 风格）中的组件结合使用时，它通常如此使用。
29. 请简述什么是远程求值风格？
① 远程求值风格来源于客户-服务器风格和虚拟机风格，一个客户端组件知道如何来执行一个服务，但缺少执行此服务所必需的资源（CPU周期、数据源等等），这些资源恰好位于一个远程站点上。
② 因此，客户端将如何执行服务的代码发送给远程站点上的一个服务器组件，服务器组件使用可用的资源来执行代码，然后将执行结果发送回客户端。
③ 远程求值风格假设将要被执行的代码是处在一种受保护的环境中，这样除了那些正在被使用的资源外，它不会影响到相同服务器的其他客户端
30. 请简述什么是按需代码风格？
在按需代码风格中，一个客户端组件知道如何访问一组资源，但不知道如何处理它们。它向一个远程服务器发送对于如何处理资源的代码的请求，接收这些代码，然后在本地执行这些代码。
31. 请简述什么是 LCODC$SS 风格？
作为一些架构如何互补的例子，考虑将按需代码风格添加到上面讨论过的分层-客户-缓存-无状态-服务器风格上。因为代码被看作不过是另一种数据元素，因此这并不会妨碍LC$SS风格的优点。
该风格的一个例子是HotJava Web浏览器[java.sun.com]，它允许applet和协议扩展作为有类型的媒体（typed media）来下载。
32. 请简述什么是移动代理风格？
① 在移动代理风格中，一个完整的计算组件，与它的状态、必需的代码、执行任务所需的数据一起被搬移到远程站点
② 该风格可以看作来源于远程求值风格和按需代码风格，因为移动性是同时以这两种方式工作的
33. 请简述什么是基于事件的集成风格？
基于事件的集成风格，也称为隐式调用或事件系统风格，通过消除连接器接口上的标识需求来减少组件之间的耦合。
一个组件可以宣布（或广播）一个或多个事件，而不是直接调用另一个组件。 系统中的其他组件可以注册对该类型事件的兴趣，并且在宣布该事件时，系统本身会调用所有已注册的组件
示例包括 Smalltalk-80 中的模型-视图-控制器范例
34. 请简述什么是 C2 ?
① C2 架构风格直接支持大粒度的重用，并且通过加强基层独立性，支持系统组件的灵活组合。
② 它通过将基于事件的集成与分层客户端服务器相结合来实现。 异步通知消息向下传送，异步请求消息向上传送，是组件间通信的唯一方式。
③ 这个约束加强了对高层依赖的松耦合（服务请求可以被忽略），并且与底层实现了零耦合（无需知道系统使用了通知），从而既改善了对于整个系统的控制，又没有丧失 EBI 的大多数优点。
④ 通知是对组件中状态变化的公告。 C2 不限制通知中应包含的内容：标志、状态的delta改变量、或完整的状态表述都是有可能的。
⑤ 连接器的主要职责是消息的路由和广播； 它的次要职责是消息过滤。
⑥ 引入对消息的分层过滤，解决了 EBI 系统的可伸缩性问题，同时也改善了可进化性和可重用性。能够使用包括了监视能力的重量级连接器来改善可见性和减少局部故障所导致的可靠性问题。
35. 请简述什么是分布式对象风格？
① 分布式对象风格将系统组织为一组作为对等交互的组件。 对象是一个实体，它封装了一些私有状态信息或数据、一组操作数据的相关操作或过程，可能还有一个控制线程，因此它们可以被整体的视为一个单一的单元。
② 一般来说，一个对象的状态是完全隐藏的，并且不受所有其他对象的影响。 检查或修改它的唯一方法是对对象的可公开访问的操作之一发出请求或调用。
③ 这为每个对象创建了一个定义良好的接口，使对象操作的规范公开，同时保持其操作的实现及其状态信息的表示私有，从而提高可进化性。
36. 请简述什么是被代理的分布式对象风格？
为了降低对象标识的影响，现代分布式对象系统通常使用一种或多种中间架构风格来辅助通信。 这包括基于事件的集成风格和被代理的客户端/服务器风格。
在被代理的分布式对象风格中引入了名称解析器组件，其目的是使用将满足请求的对象的特定名称来回答对通用服务名称的客户端对象请求。
尽管提高了可重用性和可进化性，但额外的间接级别需要额外的网络交互，从而降低效率和用户感知性能。
37. 请简述什么是中间件？
包括标准编程接口和协议的分布式系统服务。 这些服务被称为中间件，因为它们充当操作系统和网络软件之上和行业特定应用程序之下的层。
38. 请简述什么是 REST ？
表述性状态移交
REST 是一种混合风格，源自前前面提到的几种基于网络的架构风格，并结合了定义统一连接器接口的附加约束。
39. 请简述什么是”空“风格？
“空”风格仅仅是一个空的约束集合。从架构的观点来看，空风格描述了一个组件之间没有明显边界的系统。这就是我们描述REST的起点。
40. 请简述客户-服务器约束背后的原则？
客户-服务器约束背后的原则是分离关注点。通过分离用户接口和数据存储这两个关注点，改善了用户接口跨多个平台的可移植性。
同时通过简化服务器组件，改善了系统的可伸缩性。然而，对于 Web来说，最重要的是这种关注点的分离允许组件独立地进化，从而支持多个组织领域的Internet规模的需求。
41. 请简述客户-无状态-服务器风格。
同22。为客户-服务器交互添加一个约束：通信必须在本质上是无状态的，因此从客户到服务器的每个请求都必须包含理解该请求所必需的所有信息，不能利用任何存储在服务器上的上下文，会话状态(Session State) 要全部保存在客户端。
42. 请简述什么是缓存？
为了改善网络的效率，添加了缓存约束，从而形成了客户-缓存-无状态-服务器风格
缓存约束要求一个请求的响应中的数据被隐式地或显式地标记为可缓存的或不可缓存的。如果响应是可缓存的，那么客户端缓存就可以为以后的相同请求重用这个响应的数据。
添加缓存约束的好处在于，它们有可能部分或全部消除一些交互，从而通过减少一系列交互的平均延迟时间，来提高效率、可伸缩性和用户可觉察的性能；然而付出的代价是：如果缓存中陈旧的数据与将请求直接发送到服务器得到的数据差别很大，那么缓存会降低可靠性。
43. 请简述什么是统一接口？
使REST架构风格区别于其它基于网络的架构风格的核心特征是，它强调组件之间要有一个统一的接口。通过在组件接口上应用通用性的软件工程原则，整体的系统架构得到了简化，交互的可见性也得到了改善。实现与它们所提供的服务是解耦的，这促进了独立的可进化性
然而，付出的代价是统一接口降低了效率，因为信息都使用标准化的形式来转移，而不能使用特定于应用的需求的形式。REST接口被设计为可以高效地转移大粒度的超媒体数据，并针对Web的常见情况做了优化，但是这也导致了该接口对于其他形式的架构交互并不是最优的。
为了获得统一的接口，需要有多个架构约束来指导组件的行为。REST由四个接口约束来定义：资源的识别、通过表述对资源执行的操作、自描述的消息、以及作为应用状态引擎的超媒体。
44. 请简述什么是分层系统？
为了进一步改善与Internet规模的需求相关的行为，我们添加了分层的系统约束。分层系统风格通过限制组件的行为（即，每个组件只能“看到”与其交互的紧邻层），将架构分解为若干等级的层。
通过将组件对系统的知识限制在单一层内，为整个系统的复杂性设置了边界，并且提高了底层独立性。
使用层来封装遗留(Lagacy)的服务，使新的服务免受遗留客户端的影响，通过将不常用的功能转移到一个共享的中间组件中，从而简化组件的实现。中间组件还能够通过支持跨多个网络和处理器的负载均衡，来改善系统的可伸缩性。
分层系统的主要缺点是：增加了数据处理的开销和延迟，因此降低了用户可觉察的性能，对于一个支持缓存约束的基于网络的系统来说，可以通过在中间层使用共享缓存所获得的好处来弥补这一缺点。
在组织领域的边界设置共享缓存能够获得显著的性能提升，这些中间层还允许对跨组织边界的数据强制执行安全策略，例如防火墙所要求的那些安全策略。
分层系统约束和统一接口约束相结合，导致了与统一管道和过滤器风格类似的架构属性，尽管REST的交互是双向的，但是超媒体交互的大粒度的数据流每一个都能够被当作一个数据流网络来处理，其中包括一些有选择地应用在数据流上的过滤器组件，以便在数据传递的过程中对它的内容进行转换 在REST 中，中间组件能够主动地转换消息的内容，因为这些消息是自描述的，并且其语义对于中间组件是可见的。
45. 请简述什么是按需代码风格？
通过下载并执行applet形式或脚本形式的代码，REST允许对客户端的功能进行扩展。这样，通过减少必须被预先实现的功能的数目，简化了客户端的开发。允许在部署之后下载功能代码也改善了系统的可扩展性。然而，这也降低了可见性，因此它只是REST的一个可选的约束。
46. 请简述 REST 数据元素有哪些？对应的具体现代 Web 实例是什么？
47. 请简述什么是资源和资源标识符？
REST 中信息的关键抽象是资源。
任何可以命名的信息都可以是资源：文档或图像、时间服务（例如“洛杉矶今天的天气”）、其他资源的集合、非虚拟对象（例如人）等 . 换句话说，任何可能成为作者超文本参考目标的概念都必须符合资源的定义。
资源是到一组实体的概念映射，而不是在任何特定时间点对应于映射的实体。
REST 使用资源标识符来标识组件之间交互中涉及的特定资源。
REST 连接器提供了一个通用接口，用于访问和操作资源的值集，而不管成员函数（隶属函数）如何定义或处理请求的软件类型如何。
分配资源标识符的命名机构，使引用资源成为可能，负责随着时间的推移维护映射的语义有效性（即，确保成员函数不会改变）
48. 请简述什么是表述？
REST 组件通过使用表述来捕获该资源的当前或预期状态并在组件之间传输该表述来对资源执行操作。
表述是一个字节序列，加上描述这些字节的表示元数据。
表述的其他常用但不太精确的名称包括：文档、文件和 HTTP 消息实体、实例或变体。
表述包括数据、描述数据的元数据，有时还包括描述元数据的元数据（通常用于验证消息完整性）。
元数据采用名称-值对的形式，其中名称对应于定义值结构和语义的标准。
响应消息可能包括表述元数据和资源元数据：关于资源的信息，不是特定于所提供的表述。
控制数据定义了组件之间消息的目的，例如请求的操作或响应的含义。
它还用于参数化请求并覆盖某些连接元素的默认行为。 例如，可以通过请求或响应消息中包含的控制数据来修改缓存行为
表述的数据格式称为媒体类型。
表述可以包含在消息中，并由接收者根据消息的控制数据和媒体类型的性质进行处理。
一些媒体类型旨在用于自动处理，一些媒体类型旨在呈现供用户查看，还有一些能够两者兼而有之。
复合媒体类型可用于在单个消息中包含多个表述。
媒体类型的设计可以直接影响分布式超媒体系统的用户感知性能。
在接收者可以开始呈现表述之前必须接收的任何数据都会增加交互的延迟。
一种将最重要的渲染信息放在前面的数据格式，这样可以在接收其余信息的同时逐步渲染初始信息，与必须在此之前完全接收的数据格式相比，它的用户感知性能要好得多可以开始渲染。
例如，即使网络性能相同，Web 浏览器在接收大型 HTML 文档时也可以增量呈现它，它提供的用户感知性能明显优于在呈现之前等待整个文档被完全接收的浏览器。
请注意，表述的呈现能力也可能受到内容选择的影响。 如果在呈现动态大小的表格和嵌入对象之前必须确定它们的尺寸，则它们在超媒体页面的查看区域内的出现将增加其延迟。
49. 请简述什么是连接器？
REST使用多种不同的连接器类型来对访问资源和转移资源表述的活动进行封装
连接器代表了一个组件通信的抽象接口，通过提供清晰的关注点分离，并且隐藏资源的底层实现和通信机制，从而改善了架构的简单性
接口的通用性也使得组件的可替换性成为了可能：如果用户对系统的访问仅仅是通过一个抽象的接口，那么接口的实现就能够被替换，而不会对用户产生影响。由于组件的网络通信是由一个连接器来管理的，所以在多个交互之间能够共享信息，以便提高效率和响应能力(???)
50. 请简述 REST 交互无状态约束能够实现的四个功能。
所有的REST交互都是无状态的。也就是说，无论之前有任何其他请求，每个请求都包含了连接器理解该请求所必需的全部信息。这个约束能够实现四个功能：
1）它使得连接器无需保存请求之间的应用状态，从而降低了物理资源的消耗并改善了可伸缩性；
2）它允许对交互进行并行处理，处理机制无需理解交互的语义；
3）它允许中间组件孤立地查看并理解一个请求，当需要对服务作出动态安排时，这是必需要满足的；
4）它强制每个请求都必须包含可能会影响到一个已缓存响应的可重用性的所有信息
51. 请简述什么是组件？
用户代理使用客户端连接器发起请求并成为响应的最终接收者。
最常见的示例是 Web 浏览器，它提供对信息服务的访问并根据应用程序需要呈现服务响应。
源服务器使用服务器连接器来管理所请求资源的命名空间。
它是其资源表示的最终来源，并且必须是旨在修改其资源值的任何请求的最终接收者。
每个源服务器为其服务提供一个通用接口作为资源层次结构。
资源实现细节隐藏在接口后面
代理组件是客户端选择的中介，用于提供其他服务的接口封装、数据转换、性能增强或安全保护。
网关（也称为反向代理）组件是由网络或源服务器强加的中介，用于提供其他服务的接口封装，用于数据转换、性能增强或安全实施。
请注意，代理和网关之间的区别在于客户端决定何时使用代理。
52. 请简述什么是 REST 视图。
我们对 REST 架构元素的理解是孤立的
我们可以使用架构视图来描述元素如何协同工作以形成架构
三种类型的视图——过程、连接器和数据——对于阐明 REST 的设计原则很有用
53. 请简述 REST 过程视图。
架构的过程视图的主要作用是，通过展示数据在系统中的流动路径，得出组件之间的交互关系
用户代理被描绘在三个并行交互的中间：a、b 和 c。 用户代理的客户端连接器缓存不满足交互，因此每个请求都根据每个资源标识符的属性和客户端连接器的配置路由到资源。
请求 (a) 已发送到本地代理，后者依次访问 DNS 查找找到的缓存网关，该网关将请求转发给源服务器，源服务器的内部资源由封装的对象请求代理架构定义。请求 (b) 直接发送到源服务器，源服务器能够从自己的缓存中满足请求。请求 (c) 被发送到代理，该代理能够直接访问 WAIS（一种与 Web 架构分离的信息服务），并将 WAIS 响应转换为通用连接器接口识别的格式。
每个组件只知道与它们自己的客户端或服务器连接器的交互； 整个流程拓扑是我们视图的产物。
架构的连接器视图专注于组件之间的通信机制。对于基于 REST 的架构，我们对定义通用资源接口的约束特别感兴趣。客户端连接器检查资源标识符，以便为每个请求选择适当的通信机制。
REST 不限制特定协议的通信，但它确实限制了组件之间的接口，因此限制了组件之间可能以其他方式进行的交互和实现假设的范围。 例如，Web 的主要传输协议是 HTTP，但该架构还包括对源自预先存在的网络服务器（包括 FTP、Gopher 和 WAIS）的资源的无缝访问。
54. 请简述什么是数据视图。
一个架构的数据视图展示了信息在组件之间流动时的应用状态。因为REST被明确定位于分布式信息系统，它将一个应用看作是一种信息（information）和控制（control）的聚合体，用户可以通过这个聚合体执行他们想要完成的任务。
组件交互以动态大小的消息的形式发生。小粒度或中粒度消息用于控制语义，但大部分应用程序工作是通过包含完整资源表示的大粒度消息完成的。最常见的请求语义形式是检索资源的表示（例如，HTTP 中的“GET”方法），通常可以缓存以供以后重用。
REST 将所有控制状态集中到响应交互而接收到的表述中。 目标是通过消除服务器在当前请求之外保持对客户端状态的感知的任何需要来提高服务器可伸缩性。 因此，应用程序的状态由其未决请求、连接组件的拓扑结构（其中一些可能正在过滤缓冲数据）、这些连接器上的活动请求、响应这些请求的表示数据流以及对这些请求的处理来定义 用户代理收到的表述。
只要没有未完成的请求，应用程序就会达到稳定状态； 即，它没有未决请求，并且对其当前请求集的所有响应都已完全接收或接收到可以将它们视为表示数据流的程度。对于浏览器应用程序，此状态对应于“网页”，包括主要表述和辅助表述，例如内嵌图像、嵌入的小程序和样式表。应用稳态的重要性体现在它们对用户感知性能和网络请求流量突发性的影响中。
浏览器应用程序的用户感知性能由稳态之间的延迟决定：在一个网页上选择超媒体链接和为下一个网页呈现可用信息之间的时间段。因此，浏览器性能的优化集中在减少这种通信延迟上。
由于基于 REST 的架构主要通过资源表述的传输进行通信，因此延迟可能会受到通信协议设计和表示数据格式设计的影响。在接收到响应数据时增量呈现响应数据的能力取决于媒体类型的设计和每个表述中的布局信息（内嵌对象的视觉尺寸）的可用性。
一个有趣的观察是，最有效的网络请求是不使用网络的请求。换句话说，重用缓存响应的能力可显着提高应用程序性能。尽管由于查找开销，使用缓存会为每个单独的请求增加一些延迟，但即使是一小部分请求导致可用缓存命中，平均请求延迟也会显着降低
应用程序状态由用户代理控制和存储，并且可以由来自多个服务器的表示组成。 除了将服务器从存储状态的可扩展性问题中解放出来之外，这还允许用户直接操作状态（例如，Web 浏览器的历史记录），预测该状态的更改（例如，链接映射和表示的预取），并跳转 从一个应用程序到另一个应用程序（例如，书签和 URI 条目对话框）
因此，模型应用程序是一个引擎，通过检查和选择当前表示集合中的替代状态转换，从一个状态移动到下一个状态。毫不奇怪，这与超媒体浏览器的用户界面完全匹配。 但是，该样式并不假定所有应用程序都是浏览器。事实上，应用程序的详细信息通过通用连接器接口对服务器隐藏，因此用户代理同样可以是为索引服务执行信息检索的自动机器人、寻找符合特定标准的数据的个人代理或维护 蜘蛛忙于在信息中查找损坏的引用或修改的内容。
