不存在统一的定义:
架构风格 Achitecture Style =
如何描述的?重点要看
分类法:
纯粹的体系结构在现实中很难遇到,实际上的系统通常:
作为一个架构师,必须理解“纯”的风格,理解优点和缺点,理解背离这种风格会带来什么结果
数据流系统:
数据控制计算 the availability of data controls the computation
系统结构由数据在处理之间的有序移动决定
the structure of the design is dominated by orderly motion of data from process to process
数据流系统的结构是显而易见的
纯数据流系统中,处理之间除了数据交换,没有其他的别的交互,变化的是:
如何施加控制——数据的控制方式
pull 拉
消费者角度
push 推
从数据源角度
并行的程度
一条数据流,多条数据流
topology
顺序,循环
组件接口是输入端口和输出端口
Interfaces are input ports and output ports
通常是异步的,有缓冲。同步的容易阻塞
任意拓扑结构,函数式编程
主要问题是控制点control怎么在程序或者系统之间移动
数据可能跟着控制走,但是并不起到推动系统运转的作用
关注的核心是计算顺序
eg:冯诺依曼结构
主要问题是数据怎么在运算单元之间流动
数据到了,计算单元便工作
我们关心数据是否可用,转换,延迟
每一个处理步骤是一个独立的程序,每一步在上一步结束后才能开始,数据必须是完整的,以整体的方式传送。
典型应用:
功能:将数据流作为输入,经过处理后输出
进行流到流的转换:
{ 丰富数据 精炼数据 转换数据 \begin{cases}丰富数据\\精炼数据\\转换数据\end{cases} ⎩ ⎨ ⎧丰富数据精炼数据转换数据
数据不再是自包含的
fliter是无状态的计算。没有上下文,状态保存等。
将数据流从一个过滤器传递到另一个过滤器
数据传送引起动作
开环控制 Open loop Control
闭环控制Close Loop Process Control
闭环控制有两种形式:反馈控制和前馈控制
当软件系统的运行受到外部干扰时,需要为软件体系结构考虑一种过程控制范例
任务由数据主导
事先知道数据的流向
数据流动带来性能损坏
经典的例子:
主程序和子程序 main program and subroutines
经典编程范式:函数分解
面向对象的抽象数据类型
信息的隐藏
层次化结构
每一层只和他的近邻通信
其他
客户机-服务器
主程序(子程序) → 函数模块 → A D T → O b j e c t → O O 架构 → C o m p o n e n t 主程序(子程序)\rightarrow 函数模块\rightarrow ADT\rightarrow Object\rightarrow OO架构\rightarrow Component 主程序(子程序)→函数模块→ADT→Object→OO架构→Component
Problem:适用于通过过程定义层次结构适当定义计算的应用程序
Context:命名空间局部性
Solution:
系统模型:调用和定义层次结构,子系统通常模块化定义
组件:过程和显式可见数据
所有数据对外完全可见
连接器:过程调用和显式数据共享
控制结构:单线程
系统模型:局部化状态保持
组件:对象
连接件:过程调用
控制结构:去中心化,通常是单线程
隐藏细节:
隐藏可能改变的细节,接口中公开不太可能改变的假设
对象有状态和操作,但是也有完整性。
对象被外界知道的是他的接口
对象从模板产生
对象架构的元素:
{ 封装:限制信息的访问 交互:过程调用或其他协议 多态:运行时选择具体的操作 继承:对共享的功能保持一致的接口 复用和维护:封装和聚合提高生产力 \begin{cases}封装:限制信息的访问\\交互:过程调用或其他协议\\多态:运行时选择具体的操作\\继承:对共享的功能保持一致的接口\\复用和维护:封装和聚合提高生产力\end{cases} ⎩ ⎨ ⎧封装:限制信息的访问交互:过程调用或其他协议多态:运行时选择具体的操作继承:对共享的功能保持一致的接口复用和维护:封装和聚合提高生产力
管理大量的对象
对象的海洋需要额外结构容纳
管理很多交互
单一的接口能力有限且笨拙(友元)
分散的行为责任
系统的功能难以理解
捕获关联的设计
类和类型通常是不够的,设计模式是发展
包含可以按层次结构安排的不同服务类别
不透明的层次结构
各层次内部的构件,过程的集合
取决于组件的结构;在受限的可见性下,过程调用通常也可能是客户机/服务器
单线程
分类:
{ 两层 C S 结构 三层 C S 结构 B S 结构 \begin{cases}两层CS结构\\三层CS结构\\BS结构\end{cases} ⎩ ⎨ ⎧两层CS结构三层CS结构BS结构
三层CS的特例
客户端使用http浏览器即可,使用http协议,省去了很多麻烦
只能拉,不能推
客户端之间的通信只能通过服务器进行中转
对客户机和其他网络资源的利用受限
客户端资源浪费,服务器压力较大
BS的速度相对于CS慢
这种风格描述了很多系统,共同特点是共享数据
收集、操作、保存大量的数据
定义:以数据为中心的风格架构涉及到一种共享数据源方法来传递信息。
example:
系统耦合程度低
方便添加/删除/生产/消费/操纵数据
单个生产者的错误无影响
同步问题——数据发生改变时,控制反转,数据仓库压力大
配置和管理
ACID特性
早期的数据共享出现在批处理系统
迫切需要数据时即时存取
如今:
应用在各个场景,比如web就是一个巨大的分布式数据库
GitHub
仓库是共享和维护信息中心的场所
组件:
连接件:
控制结构:
典型应用场合:
数据库
如,编译器的符号表:
问题:
问题特征:
多种方法可以解决问题,找不到确定的解决思路
求解的每个步骤都有可能产生多个可能的解,寻求最佳或者可接受的解。
需要多个领域的专门知识协作解决
eg:
如何求解此类问题?——黑板体系结构
知识元:问题分解成几个部分,每个部分独立计算——知识元对黑板进行修改,逐步找到问题的解
黑板数据结构:全局数据库包含解域的全部状态
控制:完全由黑板的状态驱动,黑板的状态的改变决定使用的特定知识
让知识元响应偶然事件
目标:
提供解决问题的知识,分别存放且相互独立
动作:
只修改黑板,知识源之间的通讯交互只通过黑板进行
负责:
知道什么时候能发挥作用:“条件-动作”形式
保存知识源所需要的数据,保存来自解空间的数据
解决问题中的状态数据,以层次的形式组织起来
各个知识源只通过黑板进行交互
时刻监控黑板的状态,对黑板上的当前信息进行判断和评价
满足知识源执行条件时,知识源被控制器触发,并进行计算,结果写在黑板上
这种更新又导致其他的知识源参与计算,直到找到问题的解为止
目标:
让知识源响应偶然事件,了解各个知识源的能力,决策解决问题的步骤
信号处理、模式处理、模式识别
人工智能
应用问题:应用的最佳的执行环境或者语言不能够得到直接的支持。
引入中间层 { 应用不能直接支持 环境不适合 跨平台 引入中间层\begin{cases}应用不能直接支持\\环境不适合\\跨平台\end{cases} 引入中间层⎩ ⎨ ⎧应用不能直接支持环境不适合跨平台
上下文:
桥接需要的机器和语言与执行环境已经支持的机器(虚拟的)和语言
Solution:
系统模型:一个虚拟机
组件:一个状态机和三个存储
{ 状态机:执行的引擎 三个存储: { 执行引擎的当前状态 被解释的程序 被解释的程序目前所处的状态 \begin{cases}状态机:执行的引擎\\ 三个存储:\begin{cases}执行引擎的当前状态\\被解释的程序\\被解释的程序目前所处的状态\end{cases}\end{cases} ⎩ ⎨ ⎧状态机:执行的引擎三个存储:⎩ ⎨ ⎧执行引擎的当前状态被解释的程序被解释的程序目前所处的状态
连接件:数据访问和过程调用
控制结构:通过引擎状态转移,输入确定选择翻译什么
功能性 functionality :可以模拟非本机功能
测试性 testing :可以模拟灾难模式(安全攸关的应用)
灵活性 flexibility :非常通用的工具
效率:比硬件慢,慢两个数量级;比编译器慢
测试:需要测试额外的中间层
VB, JS, HTML, Java字节码
根据当前的状态,基于事实,判断我需要的输出
知识库:要被执行的代码
规则引擎:翻译引擎
规则/数据选择:解释器的状态
工作存储:当前代码的状态
对于一个架构,可以从不同的架构去理解
eg:hearsay
分布式环境,出现多进程多线程,节点之间相互独立。
已经广泛应用的:
eg:网络游戏的例子
通信策略的选择通常由可用操作系统提供的通信支持决定。
确保消息一定收到。
图的拓扑结构、失败模型、性能
显式调用:明确知道消息的接收者
隐式调用:中间层调用
适用于:
上下文:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SxMkxCZK-1660183005456)(https://cdn.jsdelivr.net/gh/Holmes233666/blogImage@main/img/image-20220615132637996.png)]
系统模型:独立交互式进程
组件:在不知道接收方的情况下发送接收消息的进程
连接件:自动调用已对事件感兴趣的进程
控制:分散,单个组件不知道消息的接收方
implicit invocation
适用于:
上下文:
[外链图片转存中…(img-SxMkxCZK-1660183005456)]
系统模型:独立交互式进程
组件:在不知道接收方的情况下发送接收消息的进程
连接件:自动调用已对事件感兴趣的进程
控制:分散,单个组件不知道消息的接收方