架构师考点汇总 架构风格
概念
概述:软件架构所指的就是说相应的系列性的抽象模式，可以为设计大型软件系统的各个方面提供相应的指导。
从本质上来看，软件架构是属于一种系统草图。在软件架构所描述的对象就是直接的进行系统抽象组件构成。
连接系统的各个组件之间就是做到把组件之间所存在的通讯比较明确与相对细致的实施描述。处于相应的系统
实现环节，那么就会使得细化这些抽象组件成为现实的组件，比如可以是具体的某个类或者是对象。从面向对象
领域进行分析，那么各个组件之前实施的连接实现往往是接口。
软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用、指导构件集成的模
式以及这些模式的约束组成。软件架构不仅显示了软件需求和软件结构之间的对应关系，而且指定了整个软件系统的
组织和拓扑结构，提供了一些设计决策的基本原理
表现形式
实施视图:包含这实施模型及其从模块到包、层的组织形式实施的概览；而且在这一过程中，还存在着把相应的逻辑视图中的包与类往实施视图中的包与分配模块的状况实施描述。
逻辑视图:是最为关键的设计类、从这些设计类到包与子系统的组织形式，另外还有的就是这些包与子系统到层的组织形式。
配置视图:描述最为典型的配置平台的各种物理节点，还有的就是往物理节点分配来自于进程视图的任务的情况，往往这一视图仅仅只是在分布式系统。
用例视图:场景与用例
进程视图:描述进程与线程的涉及的任务，这些任务的配置与交互，还有的就是把设计分配对象与类向任务，往往这一视图仅仅只是出于系统存在着特别高程度并行过中才使用
系统架构
系统架构是将系统整体分解为更小的子系统和组件，从而形成不同的逻辑层或服务，然后进一步确定各层的接口，层与层相互之间的关系。
对整个系统的分解，既需要进行“纵向”分解，也需要对同一逻辑层进行“横向”分解，系统的分解可参考“架构模式”进行。系统的选型主要取决于系统架构。
构件（组件）是一个功能相对独立的具有可重用价值的软件单元。在面向对象方法中，一个构件由一组对象构成，包含了一些协作的类的集合，它们共同工作来提供一种系统功能。
可重用性是指系统和（或）其组成部分能在其他系统中重复使用的程度。软件开发的全生命周期都有可重用的价值，包括项目的组织、软件需求、设计、文档、实现、测试方法和测试用例，都是可以被重复利用和借鉴的有效资源。可重用性体现在软件的各个层次，通用的、可复用性高的软件模块往往已经由操作系统或开发工具提供，如通用库、标准组件和标准模板库等，它们并不需要程序员重新开发。
IEEE对于软件系统架构的定义：
Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. [IEEE 1471]
organization 是组织的意思，这里理解为组织结构。
直译：架构是一个系统在其组件层面的基本组织结构表现，包括系统内部组件之间的关系、组件与外部的关系以及决定其设计和演进的原则。
《系统架构-复杂系统的产品设计与开发》一书中用最简单的话来描述架构：
“对系统中的实体及实体之间的关系所进行的抽象描述。”
（第九页，出自Edward Crawley等人专著论文《The Influence of Architecture in Engeering Systems》）
架构风格
架构设计的一个和兴问题是能否达到架构级的软件复用
架构风格反应了领域中总舵系统所共有的结构和语义特性,并指导如何将各个构建有效的组织成一个完成的系统
架构风格定义了用于描述系统的术语表和一组指导构建系统的规则
分类
数据流风格:批处理序列,管道-过滤器 Pipe&filter
调用/返回风格:主程序/子程序,面对对象,层次结构 Main program & subroutine
独立构件风格:进程通信,事件驱动系统(隐式调用)
虚拟机风格:解释器,基于规则的系统
仓库风格:数据库系统,超文本系统,黑白系统
2015年论文1：
系统架构风格（System Architecture Style）是描述某一特定应用领域中系统组织方式的惯用模式.架构风格定义了一个词汇表和一组约束，词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。软件系统架构风格反映了领域中众多软件系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。软件系统架构风格的共有部分可以使得不同系统共享同一个实现代码，系统能够按照常用的、规范化的方式来组织，便于不同设计者很容易地理解系统架构。
软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。它反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。按这种方式理解，软件体系结构风格定义了用于描述系统的术语表和一组指导构件系统的规则。
架构模式是在给定上下文的软件架构中，针对常发生问题的一种通用、复用的解决方案。架构模式类似于软件设计模式，但是范畴更广。
分类描述
数据流风格
批处理序列:构件为一系列固定顺序的计算单元,构件之间只通过数据传递交互,每个处理步骤是一个独立的程序,每一步必须在前一步结束后才能开始,数据必须是完整的,以整体的方式传递
管道-过滤器:每个构件都有一组输入和输出,构件读输入的数据流,经过内部处理,然后产生输出数据流,这个过程通常是通过对输入
数据流的变换或计算来完成的,包括通过计算和增加信息以丰富数据,通过浓缩和删除以精简数据,通过改变记录方式以转化数据和递增的转化数据等,这里的
构件称为过滤器,连接件就是数据流传输的管道,将一个过滤器的输出传到另一个过滤器的输入
两者区别:批处理序列初级必须是完整的,上一步结束才能下一步,而管道-过滤器是流式处理,单个结束就可以进行下一个,不用等整批
调用/返回风格
主程序/子程序:单线程控制,吧问题划分为若干个处理步骤,构件即为主程序和子程序,子程序通常可合成为模块,过程调用作为交互机制,即充当连接件的角色
调用关系是具有层次性的,其语义逻辑表现为主程序的正确性取决于她调用的子程序的正确性
面向对象
显式调用,构件是对象,独享是抽象数据类型的实例,在抽象数据类型中,数据的标识和他们的响应操作封装起来,对象
的行为体系西安在其接受和请求的动作,连接件即是对象间交互的方式,对象时通过函数和过程的调用来交互的
层次结构:构件组织成一个层次结构,连接件通过决定层间如何交互的协议来定义,每层为上一次提供服务,使用下一层的服务,只能见到和自己的邻接的层,通过
层次结构,可以将大的问题分解为诺干个渐进的下问题逐步解决,可以隐藏问题的复杂度,修改某一层,最多印象其相邻的两层
层次结构的缺点是层数多了,效率就变低了
独立构件风格
进程通信:独立构件,构件是独立的过程,连接件是消息传递,构件通常是命名过程,消息传递的方式可以使点对点,异步或同步方式以及远程过程调用等
时间驱动系统:隐式调用,构件不直接调用一个过程,二十触发或广播一个或多个时间,构件中过程在一个或多个时间中注册,当某个时间被触发时,系统
自动调用在这个事件中注册的所有过程,一个事件的触发就导致了另一个模块的过程调用,这种风格中的构件是匿名的过程,他们
之间调户的连接件往往是以过程之间的隐式调用来实现的,主要优点是为软件复用提供了强大的支持,为构件的维护和演化带来了方便,其缺点是构件放弃了对系统计算的控制
虚拟机风格
解释器:解释器通常包括一个完成解释工作的解释引擎,一个包含将被解释的代码的存储区,一个记录解释引擎当前工作状态的数据结构
以及一个记录源代码被解释执行的进度的数据结构,具有解释器风格的软件汇总含有一个虚拟机,可以仿真硬件的执行过程和一些关键应用,缺点是执行效率低
基于规则的系统:基于规则的系统包括规则集,规则解释器,规则/数据选择器和工作内存,一般用在人工智能领域和DSS中
仓库风格
数据库系统:数据共享,构件主要有两大类,一类是中央共享数据元,保存当前系统的数据状态,另一类是多个独立处理单元,处理单元对数据元素进行操作
黑板系统:包括知识源.黑板和控制三部分,知识源包括若干独立计算的不同单元,提供解决问题的只是,知识源响应黑板的变化,也只修改黑板,黑板是一个
全局数据库,包括问题域解空间的全部状态,是知识源相互作用的唯一媒介,知识源响应是通过黑板状态的变化来控制的,黑板系统通常应用
在对于解决问题没有确定性算法的软件中(信号处理,问题规划,编译器优化等)
超文本系统:构件以网状链接方式相互连接,用户可以在构件之间进行按照人类的联想思维任意跳转到相关构件,超文本是一种非线性的网状信息组织方法
它以结点为基础单位,链作为结点之间的联想式关联,超文本系统通常因公在互联网领域
数据库系统和黑板系统的区别:数据库系统以数据为核心,黑板系统以知识源为核心
分层模式
该模式用于构建可分解为多组子任务的程序，每个子任务都在某个抽象层，每个层对上一个更高层提供服务。一般信息系统中最常见的4层体系如下。
表示层（也叫 UI 层）
应用层（也叫服务层）
业务逻辑层（也叫领域层）
数据访问层（也叫持久层）
应用场景
一般桌面程序
电子商务网页程序
客户端-服务器模式
该模式由两部分构成：单个服务器端和多个客户端。服务器组件对多个客户端组件提供服务。客户端向服务器端请求服务，服务端提供对应服务给这些客户端。此外，服务器端继续监听客户端请求。
应用场景
在线应用，比如电子邮件、文档分享和银行业务
主从模式
该模式由两部分构成：主节点和多个从节点。主节点组件向多个独立的从节点组件分派任务，并根据从节点返回结果计算出最终结果。
应用场景
数据库复制，主数据库被视为权威来源并同步到从数据库
连接到计算系统的外围设备（主从驱动）
管道-过滤器模式
该模式用于构建生产和处理数据流的系统。每个处理步骤封装在一个过滤器组件中。待处理的数据被传送到管道之中，这些管道可用于缓冲或者同步。
应用场景
编译器，接连的过滤器执行词义分析，语法分析，语义分析和代码生成
生物资料学科的工作流
代理模式
该模式用于构建组件解耦的分布式系统。这些组件通过远程调用彼此交互。代理组件负责多个组件的通信协调，服务器向代理公开他们的能力（服务和特性）；客户端从代理中获取服务，然后代理重定向客户端到注册服务库中一个合适的服务。
应用场景
消息队列软件，比如 Apache ActiveMQ、Apache Kafka、RabbitMQ 和 JBoss Messaging
点对点模式
该模式中，各独立组件都叫对等点。对等点既可以作为客户端从其他对等点获取服务，也可作为服务端向其他对等点提供服务。对等点可作为客户端、或者服务端、或者两者，并且在不时间动态切换角色。
应用场景
文件分享网络，比如 Gnutella 和 G2
多媒体协议，比如 P2PTV 和 PDTP
私媒体程序，比如 Spotify
事件总线模式
该模式主要处理事件，有4个主要组件：事件源，事件监听器，频道和事件总线。事件源发布消息到事件总线上的某个频道，监听器订阅某个频道，并得知在已订阅频道中发布的消息。
应用场景
Android 开发
通知服务
模型-视图-控制器模式
该模式也叫 MVC 模式，划分交互程序为3个部分：模型——包含核心功能和数据，视图——显示信息给用户（多个视图可被定义），控制器——处理用户输入。它通过分割用户信息的内部陈述和呈现、接受方式来实现，解耦组件并允许高效的代码复用。
应用场景
主流编程语言的万维网程序架构
网页框架，比如 Django 和 Rails
黑板模式
该模式对没有确定性方案策略的问题很有用。黑板模式由三个主要组件组成，黑板——包含解空间对象的结构化全局内存，知识源——有自拥表示的专门模块，控制组件——选择、配置和执行模块。所有组件都可访问黑板，可生成新的数据对象并添加到黑板中。在黑板中，可根据已有知识源的匹配规则，寻找某些类型的数据。
应用场景
语音识别
车辆识别和跟踪
蛋白质结构鉴定
声呐信号解释
解释器模式
该模式用于设计解释特定语言编写的程序的组件。该组件主要指定怎么去评估程序代码行，也就是所谓的用某种语言写的语句或者表达式，基本点在于给语言符号分类。
应用场景
数据库查询语言，比如 SQL
用于描述通信协议的语言
其它
基于服务的架构(SOA)
概念:服务是一种为了满足某项业务需求的操作,规则等的逻辑组合,他包含一系列有序活动的交互,为实现用户目标提供支持
服务构件粗粒度,传统构件细粒度居多
服务构件的接口是标准的,主要是WSDL接口,传统固件通常以具体的api形式出现
服务构件的实现和语言无关,传统构件绑定某种特定语言
服务构件可以通过构件容器提佛那个Qos的服务,传统构件完全由程序代码直接控制
实现方式
web service:服务请求者通过服务注册中心(服务描述)查找服务提供者,并请求得到服务,也可以直接绑定服务提供者,直接发起请求
一个SOA系统要具有以下六大关键要素——基础设施、已有资源、企业服务、流程模型、服务展现和系统工具（包括开发、测试和管理工具等）。在基础设施和已有资源都已具备的基础上，开发和构建一个SOA系统要包括以下几方面的工作：
一，首先需要设计开发出符合标准的服务，这是整个SOA系统最核心的要素。
二，基于标准服务，借助流程编排工具和建模工具，组织构造流程，生成流程模型，更好地满足业务需求。
三，实际构建和开发SOA系统，具体包括服务和应用程序的开发，数据的访问、处理和管理，及对服务各种形式的展现等。
SOA架构中有三种角色：
服务提供者：服务提供者注册自己的服务，注册信息包含系统信息，服务名称，服务的ip和端口号，服务请求的url, 服务的权重等
服务注册中心：注册中心提供注册服务的中心存储，和向服务消费者push服务变更通知
服务请求者：服务消费者在启动时获取所需服务注册信息（根据系统名称+服务名称），将服务注册信息缓存在本地，监听服务信息的变更，更新本地的缓存。服务消费者根据本地缓存的服务提供者信息负载，来转发请求。对服务提供方提供心跳检测。
五大特性
服务自治：服务自治原则要求单个服务在底层逻辑控制方面要尽可能是独立和自包含的，服务不依赖于访问它的客户端或其他服务。服务可以独立的进行部署以及实施版本策略和安全策略。
依赖开放的标准：SOA的一个目标是让不同厂商开发的服务能够进行互相操作，这样就需要依赖于一个开放的被不同厂商普遍接受的标准。SOA采用基于消息的通讯方式，从消息交换的角度来想就是要求消息自身标准化，在此方法SOAP（简单对象访问协议）消息的采用对消息承载的内容提供了一致性的表示。另外SOA真正的被用于企业级应用时，还需要考虑一下额外因素，比如消息安全、可靠传输、事务的支持等。要实现真正意义上的跨平台操作，实现这些特性的互操作方式同样需要一种开放的标准定下来。在这方面一些主流的IT厂商比如：微软、IBM和BEA等联合一些国际组织如：W3C、OASIS、WS-1等，对标准和规范的指定做出了极大的贡献，这些标准和规范定义在Web Service规范中。
支持跨平台：能够让不同平台进行通讯是SOA产生的最主要动机。正因为SOA采用的开放的标准，才使跨平台得以实现。跨平台最大的好处就是促进了异质系统的集成，使Java应用能够调用.NET平台暴露出来的服务接口。此外使用标准的服务兑现有逻辑的封装，实现了对历史遗留应用的重用，也给企业提供了一种节约成本的捷径。
组合和复用：按照提供功能大小的差异，不同的服务具有不同的粒度。我们可以把提供具有最小粒度功能实现的服务成为原子服务，多个原子服务可以通过合理的组合，编排成一个新的聚合型服务。功能的复用是我软件设计思想不变的主题，SOA鼓励创建具有高复用的服务。服务的组合性另一方面也促进了服务的重用。为了提高服务的复用程度，SOA甚至强调了创建与场景无关的服务，这样同样的服务就在不同场景的解决方案中使用了。
松耦合：SOA通过契约实现客户端对服务的调用，双方只需要采用能够匹配的契约就能保证正常的交往。基于契约的服务交往，又进一步促进了服务的自治，只要契约不发生改变，服务本身的实现就可以自由的变化，因此这样的耦合度是极低的。
架构风格 架构模式
架构风格是最高抽象级别的应用设计； An Architectural Style is the application design at the highest level of abstraction;
架构模式是实现架构风格的一种方式； An Architectural Pattern is a way to implement an Architectural Style;
设计模式是解决局部问题的方法。 A Design Pattern is a way to solve a localised problem.
An architectural pattern is a general, reusable solution to a commonly occurring problem in software architecture within a given context
架构模式是一个通用的、可重用的解决方案，用以解决特定上下文内的某个常见的架构问题！
Roy Thomas Fielding博士，在他的REST论文中，对架构风格做出了定义：
An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style.
软件体系架构风格是描述某一特定应用领域中系统组织方式的惯用模式，它定义一个系统家族，即一个体系结构定义一个词汇表（构件与连接件类型）和一组约束（指出系统是如何将这些构建和连接件组合起来的）。
结合定义：架构模式=解决方案，架构风格=系统家族（惯用模式），可以明显看出：
- 架构风格是在更高级的层面上，逻辑级别的架构复用
- 架构模式是在某具体应用上下文上，实战级别的架构复用
风格大一些，模式小一些。如分层构架是风格，有2层、3层、N层，属于模式（具体）。风格不解决问题，模式解决问题，风格是概念，模式是实例应用。
风格：
Component-based
Monolithic application
Layered
Pipes and filters
Event-driven
Publish-subscribe
Plug-ins
Client-server
Service-oriented
模式：
Three-tier
Microkernel
Model-View-Controller
Model-View-ViewModel
