网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
运行时抽象
一个软件架构是一个软件系统在其操作的某个阶段的运行时(run-time)元素的抽象。一个系统可能由很多层抽象和很多个操作阶段组成，每个抽象和操作阶段都有自己的软件架构。
软件架构的核心是抽象原则：通过封装来隐藏系统的一些细节，从而更好地识别和支持系统的属性。一个复杂的系统包含有多层的抽象，每一层抽象都有自己的架构。架构代表了在某个层次上系统行为的抽象，架构的元素被描述为提供给同层的其他元素的抽象接口。在每一个元素之中，也可能还存在着另一个架构，定义了子元素的系统，这个系统实 现了由父元素的抽象接口所展示的行为。这样的架构可以递归下去直到最基本的系统元素：它们不能再被分解为抽象层次更低的元素。
除了架构的层次，软件系统通常拥有多个操作阶段，例如启动、初始化、正常处理、重新初始化和停止。每个操作阶段都有自己的架构。例如，配置文件在启动阶段会被当作架构的一个数据元素来处理，但是在正常处理阶段则不会当作一个架构元素，因为在这个阶段这些信息已经分布到了系统中的各处。
软件架构 (Software Architecture)和软件结构(Software Structure)之间的一个重要的区别是：
- 软件架构是软件系统在运行时的抽象。
- 软件结构是静态源代码的属性。
元素（Elements）
一个软件架构由一些架构元素(组件、连接器和数据)的配置来定义，这些元素之间的关系受到约束，以获得想要得到的一组架构属性。
软件架构定义为一组架构元素，这些元素具有通过一组基本原理(rationale)来描述的特殊形式。架构元素包括处理、数据、连接元素。形式则由元素的属性和元素之间的关系(即元素之上的约束)来定义。这些基本原理通过捕获选择架构风格、选择元素和形式的动机为架构提供了底层的基础。
组件（Components）
一个组件是软件指令和内部状态的一个抽象单元，通过其接口提供对于数据的转换。
组件是软件指令和内部状态的一个抽象单元，通过其接口提供对于数据的转换。转换的例子包括从二级存储将数据加载到内存、执行一些运算、转换为另外一种格式、使用其他数据来封装等等。每个组件的行为是架构的一部分，能够被其他组件观察到(observed)或看到(discerned)。
连接器（Connectors）
一个连接器是对于组件之间的通讯、协调或者合作进行仲裁的一种抽象机制。
连接器是是对于组件之间的通讯、协调或者合作进行仲裁的一种抽象机制。连接器的例子包括共享的表述、远程过程调用（RPC）、消息传递协议和数据流。
数据（Data）
一个数据是组件通过一个连接器接收或发送的信息元素。
配置（Configuration）
一个配置是在系统的运行期间组件、连接器和数据之间的架构关系的结构。
属性（Attributes）
软件架构的架构属性集合包括了对组件、连接器和数据的选择和排列所导致的所有属性。 架构属性的例子包括了可以由系统获得的功能属性和非功能属性。
架构设计的目标是创建一个包含一组架构属性的架构，这些架构属性形成了系统需求的一个超集。不同架构属性的相对重要性取决于想要得到的系统本身的特性。
风格（Style）
一种架构风格是一组协作的架构约束，这些约束限制了架构元素的角色和功能，以及在任何一个遵循该风格的架构中允许存在的元素之间的关系。
因为一种架构既包含功能属性又包含非功能属性，直接比较不同类型系统的架构，或者甚至是比较在不同环境中的相同类型的系统会比较困难。风格是一种用来对架构进行分类和定义它们的公共特征的机制。
模式和模式语言（Pattern And Pattern Language）
面向对象编程社区一直在基于对象的(Object-Based)软件开发领域探索如何使用设计模式和模式语言来描述重复出现的抽象。一种设计模式被定义为一种重要的和重复出现的系统构造。一种模式语言是一个模式的系统，以一种对这些模式的应用加以指导的结构来进行组织。
视图（View）
一种架构视图常常是特定于应用的，并且基于应用的领域而千变万化…我们已经看到架构视图解决了很多的问题，包括:与时间相关的问题(Temporal Issues)、状态和控制方法、数据表述、事务生命周期、安全保护、峰值要求和优雅降级(Graceful Degradation)。无疑，除了上述的这些视图，还存在着很多可能的视图。
基于网络的应用的架构
架构可以存在于软件系统的多个层次上。基于网络的架构(Network-Based Architectures)与软件架构(Software Architectures)的 主要区别通常是：组件之间的通信仅限于消息传递(Message Passing)或者消息传递的等价物。
一种架构风格是一组协作的架构约束，给它取一个名称是为了便于引用。每个架构设计决策可以被看作是对一种风格的应用。因为添加的一个约束可能是从一种新的风格继承来的，我们可以将所有可能的架构风格的空间看作是一棵继承树，这棵树的根节点是“空”风格(没有约束)。当它们的约束不存在冲突时，多种风格可以进行组合，形成混合风格，最终可以形成一种代表了架构设计的完整抽象的混合风格。因此一个架构设计能够通过将约束的集合分解到一棵继承树的方法来加以分析，并且可以评估由这棵树所代表的约束的累积效果。
关键的架构属性
下面列举的是明显受到该风格影响的属性，而并非是一个全面的架构属性清单。
- 性能（Performance）：包含吞吐量（Throughput）、负载（Overhead）、带宽（Bandwidth）、延迟（Latency）、完成时间（Completion）等。
- 可伸缩性（Scalability）
- 简单性（Simplicity）
- 可修改性（Modifiability）：包含可进化性（Evolvability）、可扩展性（Extensibility）、可定制性（Customizability）、可配置型（Configurability）、可重用性（Reusability）。
- 可见性（Visibility）
- 可移植性（Portability）
- 可靠性（Reliability）
基于网络的架构风格
- 数据流风格（Data-flow Styles）：管道和过滤器
- 复制风格（Replication Styles）：复制仓库、缓存
- 分层风格（Hierarchical Styles）：客户-服务器（Client-Server）、分层系统（Layered System）、客户-无状态-服务器（Client-Stateless-Server）、客户-缓存-无状态-服务器（Client-Cache-Stateless-Server）、分层-客户-缓存-无状态-服务器（Layered-Client-Cache-Stateless-Server）、远程会话（Remote Session）、远程数据访问（Remote Data Access）
- 移动代码风格（Mobile Code Styles）：虚拟机（Virtual Machine）、远程求值（Remote Evaluation）、按需代码（Code on Demand）、分层-按需代码-客户-缓存-无状态-服务器（Layered-Code on Demand-Client-Cache-Stateless-Server）、移动代理（Mobile Agent）
- 点对点风格（Peer-to-Peer Styles）：基于事件的集成（Event-Based Integration）、C2、分布式对象（Distributed Objects）、被代理的分布式对象（Brokered Distributed Objects）
设计Web架构：问题与洞察力
Web的主要目的是旨在成为一种共享的信息空间(A Shared Information Space)，人们和机器都可以通过它来进行沟通。”我们需要的是一种人们用来保存和构造他们自己的信息的方式，无论信息在性质上是永久的还是短暂的，这样信息对于他们自己和其他人都是可用的，并且能够引用和构造由其他人保存的信息，而不必每个人都保持和维护一份本地的副本。
上面是万维网应用领域的需求，持续至今，Web是成功的。Internet开发者社区曾担心Web使用的快速增长率伴随着HTTP的一些糟糕网络特性，将很快超过Internet基础设施容量，并导致崩溃。
早期的 Web 架构基于一些可靠的原则:分离关注点、简单性、通用性，但是缺乏对于 架构的描述和基本原理。
万维网架构需求的挑战是开发一个用来设计架构改进的方法，使得能够在改进部署之前对它们进行评估。
表述性状态转移（Representational State Transfer，REST）
表述性状态转移是一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。REST 强调组件交互的可伸缩性、接口的通用性、组件的独立部署、以及用来减少交互延迟、增强安全性、封装遗留系统的中间组件(intermediary components)。
REST风格推导
“空”风格仅仅是一个空的约束集合。从架构的观点来看，空风格描述了一个组件之间没有明显边界的系统。这就是我们描述 REST的起点。
客户-服务器（Client-Server）
客户-服务器约束背后的原则是分离关注点。通过分离用户接口和数据存储这两个关注点，我们改善了用户接口跨多个平台的可移植性；同时通过简化服务器组件，改善了系统的可伸缩性。然而，对于 Web来说，最重要的是这种关注点的分离允许组件独立地进化， 从而支持多个组织领域的 Internet 规模的需求。
无状态（Stateless）
再为客户-服务器交互添加一个约束：通信必须在本质上是无状态的，因此从客户到服务器的每个请求都必须包含理解该请求所必需的所有信息，不能利用任何存储在服务器上的上下文，会话状态因此要全部保存在客户端。
这个约束导致了可见性、可靠性和可伸缩性三个架构属性。
- 改善了可见性是因为监视系统不必为了确定一个请求的全部性质而去查看该请求之外的多个请求。
- 改善了可靠性是因为它减轻了从局部故障中恢复的任务量。
- 改善了可伸缩性是因为不必在多个请求之间保存状态，从而允许服务器组件迅速释放资源，并进一步简化其实现，因为服务器不必跨多个请求管理资源的使用。
与大多数架构上抉择一样，无状态这一约束反映出设计上的权衡。其缺点是：由于不能将状态数据保存在服务器上的共享上下文中，因此增加了在一系列请求中发送的重复数据(每次交互的开销)，可能会降低网络性能。
缓存（Cache）
添加缓存约束的好处在于，它们有可能部分或全部消除一些交互，从而通过减少一系列交互的平均延迟时间，来提高效率、可伸缩性和用户可觉察的性能。然而，付出的代价是，如果缓存中陈旧的数据与将请求直接发送到服务器得到的数据差别很大，那么缓存会降低可靠性。
早期的 Web 架构，如下图所示，是通过客户-缓存-无状态-服务器的约束集合来定义的。也就是说，1994 年之前的 Web 架构的设计基本原理聚焦于在 Internet 上交换静态文档的无状态的客户-服务器交互。交互的通信协议仅包含了对非共享缓存的初步支持，但是并没有限定接口要对所有的资源提供一组一致的语义。相反，Web 依赖于使用一个公共的客户-服务器实现库来维护 Web 应用之间的一致性。除了静态的文档之外，请求还能够识别出动态生成响应的服务，例如图像地图(Image-Maps)和服务器端脚本 (Server-Side Scripts)。
统一接口（Uniform Interface）
使REST 架构风格区别于其他基于网络的架构风格的核心特征是，它强调组件之间要有一个统一的接口。通过在组件接口上应用通用性的软件工程原则，整体的系统架构得到了简化，交互的可见性也得到了改善。实现与它们所提供的服务是解耦的，这促进了独立的可进化性。然而，付出的代价是，统一接口降低了效率，因为信息都使用标准化的形式来转移，而不能使用特定于应用的需求的形式。REST 接口被设计为可以高效地转移大粒度的超媒体数据，并针对 Web 的常见情况做了优化，但是这也导致了该接口对于其他形式的架构交互并不是最优的。
为了获得统一的接口，需要有多个架构约束来指导组件的行为。REST 由四个接口约束来定义：资源的识别(Identification Of Resources)、通过表述对资源执行的操作、自描述的消息(Self-Descriptive Messages)、以及作为应用状态引擎的超媒体。
分层系统（Layered System）
为了进一步改善与 Internet 规模的需求相关的行为，添加了分层的系统约束。分层系统风格通过限制组件的行为，将架构分解为若干等级的层。通过将组件对系统的知识限制在单一层内，为整个系统的复杂性设置了边界，并且提高了底层独立性。我们能够使用层来封装遗留的服务，使新的服务免受遗留客户端的影响，通过将不常用的功能转移到一个共享的中间组件中，从而简化组件的实现。中间组件还能够通过支持跨多个网络和处理器的负载均衡，来改善系统的可伸缩性。
分层系统的主要缺点是：增加了数据处理的开销和延迟，因此降低了用户可觉察的性能。对于一个支持缓存约束的基于网络的系统来说，可以通过在中间层使用共享缓存所获得的好处来弥补这一缺点。在组织领域的边界设置共享缓存能够获得显著的性能提升。
按需代码（Code on Demand）
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
Iyf-1715532331132)]
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
1515
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
