架构风格

软件架构风格描述某一特定领域中的系统组织方式和惯用模式，反映了领域中众多系统所共有的结构和语义两个方面的特征。

数据流体系结构风格

所有数据按照流的形式在执行过程中前进，数据经过序列间的数据处理组件进行处理，然后将处理结果向后传送，最后进行输出。

优点是松耦合、良好的重用性、可维护性、可扩展性、良好的隐蔽性、支持并行。 缺点是交互性差，复杂性较高，性能较差（每个过滤器都需要解析与合成数据）

架构风格名称	主要特点	主要优点	主要缺点	适合领域
批处理	一个一个以整体为单位
管道-过滤器	过滤器相对独立。一个接一个，前一个输出是后一个输入	模块可复用、可维护性和可扩展性强、具有并发性、模块独立性高	不适用于交互性强的应用、有关联的数据需要协调	系统划分清晰的模块、模块性对独立、有清晰的模块接口

调用返回体系结构风格

架构风格名称	主要特点	主要优点	主要缺点	适合领域
主程序/子程序	面向过程
面向对象	是将数据表示和基本操作封装在对象中。这种模式的构件是对象，对象维护自身的完整性，对象之间通过消息机制进行通信，对象交互时需要知道彼此的标识，通过对象之间的协作完成计算过程	实现了封装；高度模块性；代码共享灵活；易维护；可扩充性好。	增加了对象之间的依赖关系	多种领域
层次型	构建组织成一个层次结构，连接件通过决定层间如何交互的协议来定义，每层为上一层提供服务，使用下一层的服务，只能见到与自己相邻的层。通过层次结构，可以将大的问题分解为若干个渐进的小问题逐步解决，可以隐藏问题的复杂度。修改某一层，最多影响其相邻的两层（通常只能影响上层）	支持系统设计过程中逐级抽象；可扩展性好；可维护性好；支持软件复用	并不是每个系统分层都方便 不同层次之间耦合度高的系统很难实现 很难找到一个合适的、正确的层次抽象的方法

面向对象

面向对象设计是模型驱动和用例驱动的，整个设计过程将面向对象分析阶段所产生的需求模型作为输入，并生成供构 建阶段使用的设计模型作为输出。

层次型

物联网属于层次型架构，分为：

1. 感知层：负责信息采集和物物之间的信息传输。
2. 网络层：利用无线和有线网络对采集的数据进行编码、认证和传输。
3. 应用层：实现应用。

独立构件

系统由若干子系统构成且称为一个整体；系统有统一的目标；子系统有主从之分；每一个系统有自己的事件手机和处理机制

优点

1. 松耦合
2. 良好的重用性、可修改性、可扩展性

缺点

1. 构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其他构件是否会响应它。而且即使它知道事件注册了哪个构件的过程，它也不能保证这些过程被调用的顺序
2. 数据交换的问题。
3. 既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理就存在问题。

事件驱动系统

事件驱动系统：用户会注册自己的兴趣，然后系统也会把新闻按兴趣分类，如果某个新闻事件发生，可以通过事件来触发推送动作，将新闻推送给对其感兴趣的用户。这是典型的事件驱动系统应用场景。

以数据为中心体系结构风格（仓库风格）

在仓库风格中，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存储上执行

黑板体系结构风格

对于语音识别、知识推理等问题复杂、解空间很大、求解过程不确定的这一类软件系统，通常会采用黑板架构风格，以知识为中心进行分析与推理。

• 语音识别
• 模式识别
• 图像处理
• 知识推理

虚拟机体系结构风格

将业务功能灵活组合形成新的业务功能，属于自定义类型的业务，需要采用虚拟机架构。

规则系统主要适用于专家系统

架构风格名称	主要特点	主要优点	主要缺点	适合领域
解释器架构风格	通常包括一个完成解释工作的解释器引擎、一个包括将解释的代码的存储区、一个记录解释器引擎当前工作状态的数据结构，以及一个记录源代码被解释器执行的进度的数据解结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用，其缺点是执行效率较低。	可以用多种操作解释一个句子。灵活应对自定义场景	适合特定领域 执行效率较低	适用于模式匹配系统与语言编译器
基于规则的架构风格

解释器架构风格

Java虚拟机是典型的虚拟机体系结构风格。

基于规则的架构风格

基于规则的系统构成：规则集、规则解释器、规则/数据选择及工作内存，一般用在人工智能领域和DSS（决策支持系统中）

MVC架构

MVC强制性地把一个应用的输入、处理、输出流程按照视图、控制、模型的方式进行分离，形成了三个核心模块：控制器、模型、视图

控制器（Controller） 是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。

模型（Model） 是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。模型表示业务数据和业务逻辑

视图（View） 是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。是用户看到并与之交互的界面。视图向用户显示相关的数据，并能接收用户的输入数据，但是它并不进行任何实际的业务处理。

优点：

• MVC分层有助于管理复杂的应用程序，因为您可以在一个时间内专门关注一个方面。例如：您可以在不依赖业务逻辑的情况下专注于视图设计。同时也让应用程序的测试更加容易
• MVC分层同时也简化了分组开发。不同的开发人员可同时开发视图、控制器逻辑和业务逻辑

J2EE四层结构

SOA架构

SOA（Service-OrientedArchitecture），即面向服务的系统架构，是一个组件模型。SOA是一种设计理念，其中包含多个服务，服务之间通过相互依赖最终提供一系列完整的功能。各个服务通常以独立的形式部署运行，服务之间通过网络进行调用。

SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通信，不涉及底层编程接口和通信模型。

在SOA中，服务是一种为了满足某项业务需求的操作、规则等的逻辑组合，它包含一系列有序活动的交互，为实现用户目标提供支持。

SOA并不仅仅是一种开发方法，还具有管理上的优点，管理员可直接管理开发人员所构建的相同服务。多个服务通过企业服务总线提出服务请求，有应用管理来进行管理。

实施SOA的关键目标是实现企业IT资产重用的最大化，在实施SOA过程中要牢记以下特征：可从企业外部访问、随时可用（服务请求能被及时响应）、粗粒度接口（粗粒度提供一项特定的业务功能，而细粒度服务代表了技术构件方法）、服务分级、松散耦合（服务提供者和服务使用者分离）、可重用的服务及服务接口设计管理、标准化的接口（WSDL、SOAP、XML是核心）、支持各种消息模式、精确定义和服务接口。

从基于对象到基于构件再到基于服务，架构越来越松散耦合，粒度越来越粗，接口越来越标准

基于服务的构件与传统构件的区别有四点

服务构件粗粒度，传统构件细粒度居多

服务构件的接口是标准的，主要是WSDL接口，而传统构件常以API形式出现

服务构件的实现与语言无关，而传统构件常绑定某种特定的语言

服务构件可以通过构件容器提供QoS的服务，而传通构件完全由程序代码直接控制。

SCA

服务组件体系结构（Service Component Architecture，SCA）是基于面向服务体系结构（Service Oriented Architecture，SOA）的思想描述服务之间组合和协作的规范。 SCA定义了语言中立的服务组合方式,能够进行跨语言的服务调用；

SCA解决的主要问题是加强组件的接口与传输协议的关联；

SCA实现服务组件和其传输协议的绑定，这种绑定是可扩展的；

SCA主要是为了满足软件集成的需要而创建的架构。

企业服务总线ESB

简单来说是一根管道，用来连接各个服务节点。ESB的存在是为了集成基于不同协议的不同服务，ESB做了消息的转化、解释以及路由的工作，以此来让不同的服务互联互通。

ESB特点：

1. SOA的一种实现方式，ESB在面向服务的架构中起到的是总线作用，将各种服务进行连接与整合
2. 描述服务的元数据和服务注册管理
3. 在服务请求者和提供者之间传递数据，以及对这些数据进行转换的能力，并支持由时间中总结出来的一些模式如同步模式、异步模式等
4. 发现、路由、匹配和选择的能力，以支持服务之间的动态交互，解耦服务请求者和服务者。高级一些的能力，包括对安全的支持、服务质量保证、可管理性和负载平衡等。

ESB主要功能：

1. 服务位置透明性
2. 传输协议转换
3. 消息格式转换
4. 消息路由
5. 消息增强
6. 安全性
7. 监控与管理

C2体系结构风格

C2体系结构风格可以概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络。

C2风格中的系统组织规则如下：

1. 系统中的构件和连接件都有一个顶部和一个底部；
2. 构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的；
3. 一个连接件可以和任意数目的其它构件和连接件连接；
4. 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。

云原生架构模式

1. 服务化架构模式：典型代表【微服务】，服务拆分使维护压力大增
2. Mesh化架构模式：把中间件框架（RPC、缓存、异步消息）从业务进程中分离，由Mesh进程完成
3. Sercerless模式：非常适合事件驱动的数据计算任务
4. 存储计算分离模式：各类暂态数据（如session）用云服务保存
5. 分布式事务模式：解决微服务模式中多数据源事务问题
6. 可观察架构：包括Logging、Tracing、Metrics三个方面
7. 事件驱动架构：本质上是一种应用/组件间的集成架构模式

边缘计算

缓存技术的横向对比

常用架构风格对比

架构风格名称	主要特点	主要优点	主要缺点	适合领域
管道-过滤器	过滤器性对独立	模块可复用、可维护性和可扩展性强、具有并发性、模块独立性高	不适用于交互性强的应用、有关联的数据需要协调	系统划分清晰的模块、模块性对独立、有清晰的模块接口
面向对象	是将数据表示和基本操作封装在对象中。这种模式的构件是对象，对象维护自身的完整性，对象之间通过消息机制进行通信，对象交互时需要知道彼此的标识，通过对象之间的协作完成计算过程	实现了封装；高度模块性；代码共享灵活；易维护；可扩充性好。	增加了对象之间的依赖关系	多种领域
事件驱动	构件不直接调用一个过程，而是触发或广播一个或多个事件。构件中的过程注册在一个或多个事件中，当某个事件被触发时，系统自动调用这个事件注册的所有过程。一个事件的触发就导致了另一个模块中的过程调用。这种风格中的构件是匿名的过程，它们之间交互的连接件往往是以过程之间隐式调用来实现的。	为软件复用提供了强大支撑，为构建的维护和演化带来了方便	削弱了对系统计算的控制能力；各个对象的逻辑关系复杂	一个系统对外部的表现可以从它对时间的处理表征出来
层次型	构建组织成一个层次结构，连接件通过决定层间如何交互的协议来定义，每层为上一层提供服务，使用下一层的服务，只能见到与自己相邻的层。通过层次结构，可以将大的问题分解为若干个渐进的小问题逐步解决，可以隐藏问题的复杂度。修改某一层，最多影响其相邻的两层（通常只能影响上层）	支持系统设计过程中逐级抽象；可扩展性号；支持软件复用	不同层次之间耦合度高的系统很难实现
以数据为中心的体系结构风格	主要分为2类，一类是传统的数据库；另一类是黑板。数据库是由输入流中的事件来驱动信息处理，把执行结构存储到中央数据单元。黑板则由中央数据单元的当前状态来驱动系统运行，来解决状态冲突并处理可能存在的不确定知识源。	数据中心风格容错性和健壮性好。便于多客户共享大量数据，不必关心数据的产生、由谁提供和如何提供；便于将构件作为知识源添加到系统中来；解决问题的多方法性；具有可修改性和可维护性；有可重用的知识源	不支持并行、执行效率低；需要同步机制、加锁机制来保障数据的完整性和一致性，增大了系统设计的复杂度；测试困难；开发成本高	黑板常用来信号处理，如语音识别、模式识别、机器翻译、句法分析等。
解释器风格	通常包括一个完成解释工作的解释器引擎、一个包括将解释的代码的存储区、一个记录解释器引擎当前工作状态的数据结构，以及一个记录源代码被解释器执行的进度的数据解结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用，其缺点是执行效率较低。	可以用多种操作解释一个句子。灵活应对自定义场景	适合特定领域 执行效率较低	适用于模式匹配系统与语言编译器
控制环路	控制环路架构风格是将过程输出的指定属性维护在一个特定的参考值（设定点）。控制环路风格包括过程变量、被控变量、输入变量、操纵变量和设定点构件，通过收集实际和理想的过程状态信息，并能调整过程变量使得实际状态趋于理性状态	将控制理论引入到计算机软件体系结构中	适合特定领域	该系统中一定存在有目标的作用、信息处理闭环控制过程。