架构风格反映了领域中众多系统所共用的结构和语义特性，并指导如何将各个构件有效地组织成一个完整的系统。架构风格定义了用于描述系统的术语表和一组指导构件系统的规则。
博主博客
一、五大架构风格
| 五大架构风格 | 子风格 |
|---|---|
| 数据流风格 | 批处理序列、管道-过滤器 |
| 调用/返回风格 | 主程序/子程序、面向对象、层次结构 |
| 独立构件风格 | 进程通信、事件驱动系统（隐式调用） |
| 虚拟机风格 | 解释器、基于规则的系统 |
| 仓库风格 | 数据库系统、黑板系统、超文本系统 |
二、数据流风格
批处理序列： 大量整体数据、无需用户交互。
管道-过滤器：流式数据、弱用户交互。
优点
1、松耦合【高内聚-低耦合】；
2、良好的重用性/可维护性；
3、可扩展性【标准接口适配】；
4、良好的隐蔽性；
5、支持并行。
缺点
1、交互性较差；
2、复杂性较高；
3、性能较差（每个过滤器都需要解析与合成数据）。
典型实例
1、传统编译器；
2、网络报文处理。
三、调用/返回风格
主程序/子程序： 面向过程。
面向对象： 对象的方法调用。
分层： 层与层之间的方法调用。
优点
1、良好的重用性，只要接口不变可用在其他处；
2、可维护性好；
3、可扩展性好，支持递增设计。
缺点
1、并不是每个系统都方便分层；
2、很难找到一个合适的、正确的层次抽象方法；
3、不同层次之间耦合度高的系统很难实现。
特点
1、各个层次的组件形成不同功能级别的虚拟机；
2、多层相互协同工作，而且实现透明。
四、独立构件风格
构件之间不直接交互， 松耦合。
优点
1、松耦合；
2、良好的重用性/可修改性/可扩展性。
缺点
1、构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其他构件是否会响应它。而且即使它知道事件注册了哪些构件过程，它也不能保证这些过程被调用的顺序；
2、数据交换的问题；
3、既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理就存在问题。
特点
1、系统由若干子系统构成且成为一个整体；
2、系统有统一的目标；
3、子系统有主从之分；
4、每一子系统有自己的事件收集和处理机制。
五、虚拟机风格
虚拟机风格的基本思想是人为构建一个运行环境，在这个环境之上，可以解析与运行自定义的一些语言，这样来增加架构的灵活性。
优点
可以灵活应对自定义场景。
缺点
复杂度较高。
适合领域
解释器： 适用于需要“自定义规则”的场合。
基于规则的系统： 适用于专家系统。
六、仓库风格（以数据为中心）
优点
黑板系统： 可更改性和可维护性；可重用的知识源；容错性和健壮性。
缺点
黑板系统：测试困难；不能保证有好的解决方案；难以建立好的控制策略；低效；开发困难；缺少并行机制。
特点
数据库系统： 以数据为中心。
黑板系统： 在以数据为中心的基础上， 使用中心数据触发业务逻辑部件。
典型实例
黑板系统：语音识别、模式识别、图像处理、知识推理。
七、层次化系统架构风格
1、两层 C/S 架构风格
表示层、数据层
2、三层 C/S 架构风格
表示层、数据层、功能层
3、B/S 架构风格
- B/S 架构缺乏对动态页面的支持能力，没有集成有效数据的库处理功能；
- B/S 架构的安全性难以控制；
- 采用 B/S 架构的应用系统，在数据查询响应等速度，上要远远低于 C/S 架构 Web 服务器；
- B/S 架构数据的提交一般以页面为单位，数据的动态交互性不强，不利于 OLTP 应用。
4、混合架构
B/S 与 C/S 混合。
八、MVC架构风格
- Module（模型）是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。
- View（视图）是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。
- Controller（控制器）是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。
九、MVP架构风格
MVP的全称为：Model-View-Presenter，Model 提供数据，View 负责显示，Controller/Presenter 负责逻辑的处理。MVP 是从经典的模式 MVC 演变而来，它们的基本思想有相通 的地方：Controller/Presenter 负责逻辑的处理，Model 提供数据，View 负责显示。
- MVP 是 MVC 的变种
- MVP 实现了 V 与 M 之间的解耦（V不直接使用M，修改V不会影响M)
- MVP 更好的支持单元测试业务逻辑在P中，可以脱离V来测试这些逻辑；可以将一P个用于多个V，而不需要改变P的逻辑)
- MVP 中 V 要处理界面事件，业务逻辑在 P 中，MVC 中界面事件由 C 处理
十、MVVM 架构风格
如果说 MVP 是对 MVC 的进一步改进，那么 MVVM 则是思想的完全变革。它是将 数据模型数据双向绑定 的思想作为核心，因此在 View 和 Model 之间没有联系，通过 ViewModel 进行交互，而且 Model 和 ViewModel 之间的交互是双向的，因此视图的数据的变化会同时修改数据源，而数据源数据的变化也会立即反应到 View 上。
十一、富互联网应用架构风格（RIA）
- RIA 结合了 C/S 架构反应速度快、交互强的优点，以及 B/S 架构传播范围广泛以及容易传播的特性
- RIA 简化并改进了 B/S 架构的用户交互
- 数据能够被缓存在客户端，从而可以实现一个比基于 HTML 的响应速度更快且数据往返服务器的次数更少的用户界面。
十二、面向服务的架构（SOA）
- 服务构件粗粒度，传统构件细粒度居多；
- 服务构件的接口是标准化的，主要是 WSDL 接口，传统构件常以具体 API 形式出现；
- 服务构件的实现与语言无关，传统构件绑定某种特定语言；
- 服务构件可以通过构件容器提供 QoS 的服务，传统构件完全由程序代码直接控制。
SOA 的关键技术
| 功能 | 协议 |
|---|---|
| 发现服务 | UDDI、DISCO |
| 描述服务 | WSDL、XML Schema |
| 消息格式层 | SOAP、REST |
| 编码格式层 | XML(DOM,SAX) |
| 传输协议层 | HTTP、TCP/IP、SMTP等 |
WSDL 就是 WebService 接口对应的 WSDL 文件，该文件通过 xm 格式说明如何调用，可以看作 WebService 的接口文档(使用说明)书。
SOA 的实现方法
现方式一：Web Service
将不同的服务打包构建成一个项目系统，进行独立的控制，服务间可以互相调用。
服务提供者在服务注册中心进行发布， 服务请求者在服务注册中心进行查找， 服务请求者与服务提供者进行绑定。
实现方式二：ESD企业服务总线
服务请求者与服务提供者之间解耦。
- 提供位置透明性的消息路由和寻址服务
- 提供服务注册和命名的管理
- 支持多种的消息传递范型
- 支持多种可以广泛使用的传输协议
- 支持多种数据格式及其相互转换
- 提供日志的监控功能
十三、微服务架构风格
微服务顾名思义，就是很小的服务，所以它属于面向服务架构的一种。
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、相互配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制相互沟通（通常是基于HTTP 协议的 RESTful API）。每个服务都围绕着具体业务进行构件，并且能够被独立的部署到生产环境、类生产环境等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。所以总结起来，微服务的核心特点为：
- 小, 且专注于做⼀件事情；
- 轻量级的通信机制；
- 松耦合、独立部署。
微服务优势
- 技术的异构性：不同的服务能够使用不同的技术；
- 弹性：服务在出现异常时候能够快速修复；
- 扩展：服务拆分后更容易扩展；
- 简化部署：服务拆分后部署更容易，减少部署的影响；
- 与组织结构相匹配：开发人员可以根据组织结构进行调配；
- 可组合性；
- 对可替代性的优化：服务微小化，利于服务重构和替换。
微服务面临的挑战
- 分布式系统的复杂度；
- 运维成本；
- 部署自动化；
- DevOps与组织结构；
- 服务间依赖测试；
- 服务间依赖管理。
微服务与SOA架构的差异
| 微服务 | SOA |
|---|---|
| 能拆分的就拆分 | 是整体，服务能放一起的都放一起 |
| 纵向业务划分 | 是水平分多层 |
| 由单一组织负责 | 按层级划分不同部门的组织负责 |
| 细粒度 | 粗粒度 |
| 两句话可以解释明白 | 几百字只相当于SOA的目录 |
| 独立的子公司 | 类似大公司里面划分了一些业务单元(BU) |
| 组件小 | 存在较复杂的组件 |
| 业务逻辑存在于每一个服务中 | 业务逻辑横跨多个业务领域 |
| 使用轻量级的通信方式，如 HTTP | 企业服务总线(ESB)充当了服务之间通信的角色 |
微服务与SOA架构的实现
| 微服务架构实现 | SOA实现 |
|---|---|
| 团队级，自底向上开展实施 | 企业级，自顶向下开展实施 |
| 一个系统被拆分成多个服务，粒度细 | 服务由多个子系统组成，粒度大 |
| 无集中式总线，松散的服务架构 | 企业服务总线，集中式的服务架构 |
| 集成方式简单(HTTP/REST/JSON) | 集成方式复杂(ESB/WS/SOAP) |
| 服务能独立部署 | 单块架构系统，相互依赖，部署复杂 |
十四、扩展架构
闭环控制架构-过程控制
当软件被用来操作一个物理系统时，软件与硬件之间可以粗略地表示为一个反馈循环，这个反馈循环通过接受一定的输入，确定一系列的输出，最终使环境达到一个新的状态。适合于嵌入式系统，用于解决简单闭环控制问题。经典应用：空调控温，定速巡航。空调控温：设定指定的温度，经过控制器、执行器、被控对象执行后，进入反馈（反馈当前室内温度）与比较器中当前设定温度是否一致，不一致则再次循环执行，一致则停止执行。
C2架构风格
- 构件和连接件都有一个顶部和一个底部。
- 构件的顶部要连接到连接件的底部，构件的底部要连接到连接件的顶部，构件之间不允许直连。
- 一个连接件可以和任意数目的其他构件和连接件连接。
- 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。
MDA架构风格-模型驱动
模型驱动的架构的基本思想是系统的功能性是用合适的规约语言以平台无关的模型定义，然后为实际的实现翻译到一个或者多个平台特定模型上（通过规则自动生成项目）
主要目标
- Portability(可移植性)
- Interoperability(互通性)
- Reusability(可重用性)
3种核心模型
- 平台独立模型(PIM)：具有高抽象层次、独立于任何实现技术的模型。
- 平台相关模型(PSM)：为某种特定实现技术量身定做，让你用这种技术中可用的实现构造来描述系统的模型。PIM会被变换成一个或多个PSM。
- 代码Code：用源代码对系统的描述(规约)。每个PSM都将被变换成代码。
ADL架构风格语言
ADL是一种格式化语言，它在底层语义模型的支持下，为软件系统的概念体系结构建模提供了具体语法和概念框架。日常架构工作中并不常用。如：Aesop、MetaH、C2、Rapide、SADL、Unicon等。
ADL的三个基本元素
- 构件：计算或数据存储单元。
- 连接件：用于构件之间交互建模的体系结构构造块及其支配这些交互的规则。
- 架构配置：描述体系结构的构件与连接件的连接图。
特定领域软件结构（DSSA）
特定领域软件架构（Domain Specific Software Architecture，DSSA）是在一个特定应用领域中，为一组应用提供组织结构参考的标准软件体系结构。DSSA的基本活动包括领域分析、领域设计和领域实现。其中领域分析的主要目的是获得，从而描述领域中系统之间共同的需求，即领域需求；领域设计的主要目标是获得，从而描述领域模型中表示。DSSA以一个特定问题领域为对象，形成由领域参考模型、参考需求、参考实现等组成的开发基础架构，支持一个特定领域中多个应用的生成。DSSA的基本活动包括领域分析、领域设计和领域实现，其中：
- 领域分析的主要目的是建立领域模型，从而描述领域中系统之间共同的需求，即领域需求；
- 领域设计的主要目标是获得DSSA，从而描述领域模型中表示需求的解决方案；
- 领域实现的主要目标是开发和组织可复用信息，并实现基础软件架构。
邻域分析机制
DSSA的人员可以划分为4种角色：
- 领域专家：领域专家可能包括该领域中系统的有经验的用户，以及从事该领域中系统需求分析、设计、实现和项目管理的有经验的软件工程师等。
- 领域分析人员：应由具有知识工程背景的有经验的系统分析员来担任，其主要任务包括控制整个领域分析过程进行知识获取，将获取的知识组织到领域模型中。并根据现有系统、标准规范等验证领域模型的准确性和一致性，维护领域模型。
- 领域设计人员：应由有经验的软件设计人员来担任，其主要任务包括控制整个软件设计过程，根据领域模型和现有的系统开发出DSSA。并对DSSA的准确性和一致性进行验证，建立领域的经验，以便于分析领域中的问题及与领域专家进行交互。
- 领域实现人员：应由有经验的程序设计人员来担任，其主要任务包括根据领域模型和DSSA，或者从头开发可重用构件，或者利用再工程技术从现有系统中提取可重用构件。并对可重用构件进行验证，建立DSSA与可重用构件间的联系。