架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。
| 五大架构风格 | 子风格 |
|---|---|
| 数据流风格【Data Flow】 | 批处理【Batch Sequential】、管道-过滤器【Pipes And Filters】 |
| 调用/返回风格【Call Return】 | 主程序/子程序【Main Program And Subroutine】、面向对象【Object orienred】、分层架构【Layered System】 |
| 独立构建风格【Independent Components】 | 进程通信【Communicating Processes】、事件驱动系统（隐式调用）【Event System】 |
| 虚拟机风格【Virtual Machine】 | 解释器【Interpreter】、规则系统【Rule Base System】 |
| 以数据中心风格【Data Centered】 | 数据库系统【Database System】、黑板系统【Blackboard System】、超文本系统【Hypertext System】 |
数据流风格
优点
- 松耦合【高内聚-低耦合】
- 良好的重用性/可维护性
- 可扩展性【标准接口适配】
- 良好的隐蔽性
- 支持并行
缺点
- 交互性差
- 复杂性高
- 性能较差（每个过滤器都需要解析与合成数据）
典型实例
- 传统编译器
- 网络报文处理
数据流风格两大分类
批处理序列：大量整体数据、无需用户交互
管道-过滤器：流式数据、弱用户交互
返回/调用风格
返回/调用风格主要分为三类
- 主程序/子程序：面向过程
- 面向对象：对象的方法调用
- 分层：层与层之间的方法调用
常用的为分层架构风格，详见搬砖方法论：分层策略
优点
- 良好的重用性，只要接口不变可用在其它地方
- 可维护性好
- 可扩展性好，支持递增设计
缺点
- 并不是每个系统都方便分层
- 很难招到一个合适的、正确的层次抽象方法
- 不同层次之间耦合度高的系统很难实现
特点
- 各个层次的组件形成不同功能级别的虚拟机
- 多层相互协同工作，而且实现透明
独立构建风格
优点
- 松耦合
- 良好的重用性、可修改性、可扩展性
缺点
- 构建放弃了对系统计算的控制。一个构建触发一个事件时，不能确定其他构建是否会响应它。而且即使它知道事件注册了哪些构建的过程，它也不能保证这些过程被调用的顺序。
- 数据交换的问题
- 既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理就存在问题。
特点
- 系统由若干子系统构成且称为一个整体
- 系统有统一的目标
- 子系统有主从之分
- 每一子系统有自己的事件收集和处理机制
虚拟机风格
| 子分类 | 优点 | 缺点 | 特点 | 适合领域 |
|---|---|---|---|---|
| 解释器 | 可以灵活应对自定义场景 | 复杂度较高 | 适用于需要“自定义规则”的场合 | |
| 规则为中心 | 可以灵活应对自定义场景 | 复杂度较高 | 在解释器的基础上增加经验规则 | 适用于专家系统 |
以数据为中心风格
| 子分类 | 优点 | 缺点 | 特点 | 适合领域 |
|---|---|---|---|---|
| 数据库系统 | 以数据为中心 | |||
| 黑办系统 | 可更改性和可维护性；可重用的知识源；容错性和健壮性 | 测试困难；不能保证有好的解决方案；难以建立好的控制策略；低效；开发困难；缺少并行机制 | 在以数据为中心的基础上，使用中心数据触发业务逻辑部件 | 语音识别、模式识别、图形处理、知识推理 |
闭环控制架构风格（过程控制）
- 适合于嵌入式系统，用于解决简单闭环控制问题。
- 经典应用：空调温控，定速巡航。
C2风格
基本规则
- 构建和连接件都有一个顶部和一个底部。
- 构建的顶部要连接到连接件的底部，构建的底部要连接到连接件的顶部，构建之间不允许直接连接
- 一个连接件可以和任意数目的其他构件和连接件连接。
- 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。
层次架构风格
MVC架构风格
- Model 是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。
- View 是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。
- Controller 是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。
MVP架构风格
- MVP是MVC的变种
- MVP实现了V与M之间的解耦（V不直接使用M，修改V不会影响M）
- MVP更好的支持单元测试（业务逻辑在P中，可以脱离V来测试这些逻辑，可以将一个P用于多个V，而不需要改变P的逻辑）
- MVP中V要处理界面事件，业务逻辑在P中，MVC中界面事件由C处理
MVVM架构风格
RIA架构风格
- 反应速度快
- 易于传播
- 交互性强
基于服务的架构（SOA）
服务是一种为了满足某项业务需求的操作、规则等的逻辑组合，它包含一系列有序活动的交互，为实现用户目标提供支持。
- 服务构件粗粒度，传统构件细粒度居多
- 服务构件的接口是标准的，主要是WSDL接口，传统构件常以具体API形式出现
- 服务构件的实现与语言无关，传统构件绑定某种特定语言
- 服务构件可以通过构件容器提供QoS的服务，传统构件完全由程序代码直接控制
SOA的实现方式——WebService
- 底层传输层
- 服务通信协议层
- 服务描述层
- 服务层
- 业务流程层
- 服务注册层
SOA的实现方式——ESB
服务请求者与服务提供者之间解耦
- 提供位置透明性的消息路由和寻址服务
- 提供服务注册和命名的管理功能
- 支持多种的消息传递范型
- 支持多种可以广泛使用的传出协议
- 支持多种数据格式及其相互转换
- 提供日志和监控功能
关键技术
| 功能 | 协议 |
|---|---|
| 发现服务 | UDDI、DISCO |
| 描述服务 | WSDL、XML Schema |
| 消息格式层 | SOAP、REST |
| 编码格式层 | XML（DOM，SAX） |
| 传输协议层 | HTTP、TCP/IP、SMTP等 |
微服务架构风格
优点
- 小服务【专注于一件事】
- 轻量级的通讯机制
- 松耦合
- 独立测试
- 独立部署【简单部署】
- 独立运行【每个服务独立在独立进程中】
- 支持异构【例如每个服务使用不同数据库】
- 更好的可用性与弹性
- 化整为零，易于小团队开发
缺点
- 分布式环境下的数据一致性【更复杂】
- 测试的复杂性【服务间依赖测试】
- 运行的复杂性
微服务与SOA对比
| 微服务 | SOA |
|---|---|
| 能拆分的就拆分 | 是整体的，服务能放在一起都放在一起 |
| 纵向业务划分 | 是水平分多层 |
| 由单一组织负责 | 按层级划分不同部门的组织负责 |
| 细粒度 | 粗粒度 |
| 两句话可以解释明白 | 几百字只相当于SOA的目录 |
| 独立的子公司 | 类似于大公司里面划分了一些业务单元（BU） |
| 组件小 | 存在较复杂的组件 |
| 业务逻辑存在于每一个服务中 | 业务逻辑横跨多个业务领域 |
| 使用轻量级的通讯方式，如HTTP | 企业服务产总线（ESB）充当了服务之间通讯的角色 |
云原生架构风格
【云原生】是基于分布部署和统一运管的分布式云，以容器、微服务、DevOps等技术为基础建立的一套云技术产品体系。
云原生架构设计原则
- 服务化原则
- 弹性原则
- 可观测原则
- 韧性原则
- 自动化原则
MDA架构风格
MDA的3种核心模型
- 平台独立模型（PIM）：具有高抽象层次、独立于任何实现技术的模型。
- 平台相关模型（PSM）：为某种特定实现技术量身定做，让你用这种技术中可用的实现构造来描述系统的模型。PIM会被变换成一个或多个PSM。
- 代码Code：用源代码对系统的描述（规约）。每个PSM都将被变换成代码。
ADL架构风格
ADL是这样一种形式化语言，它在底层语义模型的支持下，为软件系统的概念体系结构建模提供了具体语法和概念框架。如：Aesop、MetaH、C2、Rapide、SADL、Unicon等。
ADL的三个基本元素
- 构建：计算或数据存储单元、
- 连接件：用于构件之间交互建模的体系结构构造块及其支配这些交互的规则。
- 架构配置：描述体系结构的构件与连接件的连接图。