目 录CONTENT

文章目录

架构风格概述

版主
2025-02-11 / 0 评论 / 1 点赞 / 25 阅读 / 0 字 / 正在检测是否收录...

架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。

五大架构风格

子风格

数据流风格【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的三个基本元素

  • 构建:计算或数据存储单元、

  • 连接件:用于构件之间交互建模的体系结构构造块及其支配这些交互的规则。

  • 架构配置:描述体系结构的构件与连接件的连接图。

1
广告 广告

评论区