高级系统架构师学习(三)软件架构设计

一、软件架构的概念 什么是架构?【暂无定论】定义:架构设计就是需求分配,即将满足需求的职责分配到组件上。本质:为软件系统提供了一个结构、行为和属性的高级抽象。

一、软件架构的概念

什么是架构?【暂无定论】

  定义:架构设计就是需求分配,即将满足需求的职责分配到组件上。

  本质:为软件系统提供了一个结构、行为和属性的高级抽象。【软件架构 == 软件体系结构】

  作用:

  • 是项目干系人进行交流的手段,明确了对系统实现的约束条件,决定了开发和维护组织的组织结构,制约着系统的质量属性。
  • 使推理和控制的更改更加简单,有助于备序渐进的原型设计,可以作为培训的基础。
  • 可传递和可复用的模型,通过研究软件架构可能预测软件的质量。

架构发展史

“4+1”视图

"4+1"视图【架构】

"4+1"视图【UML】

软件模型分类

  • 结构模型:以架构的构件连接件和其他概念来刻画结构
  • 框架模型:不太侧重描述结构的细节而更侧重于整体的结构
  • 动态模型:描述软件系统中流程和交互的一种模型
  • 过程模型:构建系统的步骤和过程
  • 功能模型:一组功能构件按层次组成,下层向上层提供服务

二、软件架构风格【重点!!!!!】

五大架构风格

  • 数据流风格:批处理、管道过滤器
  • 调用/返回风格:主程序/子程序、面向对象、分层架构
  • 独立构件风格:进程通讯、事件驱动系统(隐式调用)
  • 虚拟机风格:解释器、规则系统
  • 仓库风格【以数据为中心】数据库系统、黑板系统、超文本系统

数据流风格

  优点:

  • 1、高内聚、低耦合
  • 2、良好的重用性/可维护性
  • 3、可扩展性【标准接口适配】
  • 4、良好的隐蔽性
  • 5、支持并行

  缺点:

  • 1、交互性较差
  • 2、复杂性较高
  • 3、性能较差每个过滤器都需要解析与合成数据

  典型应用:传统编译器、网络报文处理等

批处理序列

  定义:构件为一系列固定顺序的计算单元,构件之间只通过数据传递交互。每个处理步骤是一个独立的程序,每一步必须在其前一步结束后才能开始,数据必须是完整的,以整体的方式传递

管道-过滤器

批处理与管道-过滤器的异同【重点!!!!!】

  • 批处理序列:大量整体数据、无需用户交互
  • 管道-过滤器:流式数据、弱用户交互

调用/返回风格

  优点:

  • 1、良好的重用性
  • 2、可维护性好
  • 3、可扩展性好、支持递增设计

  缺点:

  • 1、并不是每个系统都适合分层
  • 2、层次抽象划分比较难
  • 3、耦合度高的系统难以剥离调用关系

  分类:

  • 主程序/子程序:面向过程
  • 面向对象:对象的方法调用
  • 分层:层与层之间的方法调用

主程序/子程序

  构件:主程序和子程序

  连接件:过程调用(也是交互机制)

  单线程控制,把问题划分为若干个处理步骤,子程序通常可合成为模块。调用关系具有层次性,其语义逻辑表现为主程序的正确性取决于它调用的子程序的正确性。

面向对象

  构件:对象

  连接件:对象间交互的方式(通过函数、过程来交互)

  对象是抽象数据类型的实例。在抽象数据类型中,数据的表示和它们的相应操作被封装起来,对象的行为体现在其接受和请求的动作。

层次结构

  构件:具有层次结构的组件

  连接件:上下层交互的协议

  每层为上一层提供服务,使用下一层的服务,只能见到与自己邻接的层。

  通过层次结构可以将大的问题分解为若干个渐进的小问题逐步解决,可以隐藏问题的复杂度。

  修改某一层,最多影响其相邻的两层(通常只能影响上层)

独立构件风格

  优点:

  • 1、松耦合(构件之间不直接交互)
  • 2、良好的可重用性、可修改性、可扩展性

  缺点:

  • 1、构件放弃了对系统计算的控制。(只负责调用,不一定能成功)
  • 2、数据交换存在问题(松耦合后考虑事务一致等分布式问题)
  • 3、正确性验证比较麻烦(不是顺序调用不好排查问题)

独立构件风格与调用/返回风格的异同

进程通信

  构件:独立的过程

  连接件:消息传递

  构件通常是命名过程,消息传递的方式可以是点对点、异步或同步方式,以及远程过程(方法)调用等。

事件驱动系统(隐式调用)

  构件:独立的组件(匿名的过程)不直接调用一个过程,而是触发或广播一个或多个事件

  连接件:具体工作事件。(隐式调用)

  这种风格中的构件是匿名的过程,它们之间交互的连接件往往是以过程之间的隐式调用来实现的。

虚拟机风格

  优点:

  • 1、灵活应对自定义场景

  缺点:

  • 1、复杂度较高

 

解释器

  组成:

  • 解释引擎【完成解释工作】
  • 代码存储区【需要被解释的代码存放区域】
  • 记录解释引擎当前工作状态的数据结构
  • 记录源代码被解释执行进度的数据结构

  特点:含有一个虚拟机【可以仿真硬件的执行过程和一些关键应用】

  缺点:执行效率比较低

基于规则的系统

  组成:

  • 规则集
  • 规则解释器
  • 规则/数据选择器
  • 工作内存

  应用:人工智能领域DSS【决策支持系统】

仓库风格【以数据为中心的风格】

  分类:

  • 数据库系统
  • 黑板系统:语音识别、知识推理
  • 超文本系统

数据库系统

  构件类型:

  • 中央共享数据源:保存当前系统的数据状态
  • 多个独立处理单元:处理单元对数据元素进行操作

黑板系统

  组成:

  • 知识源【若干独立计算的不同单元,提供解决问题的知识】
  • 黑板【全局数据库,包含问题域解空间的全部状态,是知识源相互作用的唯一媒介】
  • 控制【操作知识源】

超文本系统

  构件以网状链接方式相互连接,用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。超文本是一种非线性的网状信息组织方法,它以结点为基本单位,链作为结点之间的联想式关联。

闭环控制风格【过程控制】

  适用系统:嵌入式系统

  目的:解决简单控制闭环问题

  应用:空调温控定速巡航

C2风格【解耦】

  基本原则:

  • 构件和连接件都有一个顶部和一个底部
  • 构件之间不允许直连
  • 一个连接件可以和任意数目的其它构件和连接件连接
  • 当两个连接件进行直接连接时,必须由其中一个的底部到另一个的顶部

三、典型架构应用【重点!!!!!】

层次架构

   演变过程:

  层次结构演进:MVC -> MVP -> MVVM

MVC结构

  • Model(模型):是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。
  • View(视图):是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。
  • Controller(控制器):是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据,控制用户输入,并向模型发送数据。

MVP结构【MVC的变种】

  优点:

  • 模型与视图完全分离
  • 所有的交互都通过Presenter内部发生
  • 可以将一个Presenter 用于多个视图,而不需要改变Presenter的逻辑
  • Presenter可以单独测试【单元测试】

MVVM结构

  产生背景:由于Controller主要用来处理各种逻辑和数据转化,复杂业务逻辑界面的Controller非常庞大,维护困难。

  思路:把Controller的数据和逻辑处理部分从中抽离出来,用一个专门的对象去管理,这个对象就是ViewModel,是Model和Controller之间的一座桥梁

  好处:Controller中的代码变得非常少,变得易于测试和维护,只需要Controller和ViewModel做数据绑定即可。

富互联网应用【RIA】

  特点:

  • RIA简化并改进了B/S架构的用户交互
  • 数据能够被缓存在客户端,从而可以实现一个比基于HTML的响应速度更快且据往返于服务器的次数更少的用户界面。

  优点:反应速度快、易于传播、交互性强。

物联网分层结构

大数据分层结构

基于服务的架构(SOA)【服务治理】

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

  SOA层次(包含关系):服务【构件(对象)】

  特点:

  • 服务是标准化程度更高的构件
  • 服务构件粗粒度,传统构件细粒度居多。
  • 服务构件的接口是标准的,主要是WSDL(网络服务描述)接口,传统构件常以具体API形式出现(标准化结构)。
    • PS:WSDL就是WebService接口对应的WSDL文件,该文件通过xml格式说明如何调用,可以看作WebService的接口文档(使用说明书)
  • 服务构件的实现与语言无关,传统构件绑定某种特定语言。
  • 服务构件可以通过构件容器提供QoS(服务质量)的服务,传统构件完全由程序代码直接控制 (松耦合)。

  关键技术:

REST

  REST【表述性状态转移】:一种只使用HTTP和XML进行基于Web通信的技术,可以降低开发的复杂性,提高系统的可伸缩性。

  REST的5个原则:

  • 网络上的所有事物都被抽象为资源
  • 每个资源对应一个唯一的资源标识
  • 通过通用的连接件接口对资源进行操作
  • 对资源的各种操作不会改变资源标识
  • 所有的操作都是无状态的

服务请求者与服务提供者之间解耦的方式

  • 提供位置透明性的消息路由和寻址服务
  • 提供服务注册和命名的管理功能
  • 支持多种的消息传递范型
  • 支持多种可以广泛使用的传输协议
  • 支特多种数据格式及其相互转换
  • 提供日志和监控功能

微服务-混合风格

  定义:是很小的服务,属于面向服务架构的一种

  优势:

  • 复杂应用解耦:小服务(专注于做一件事情),化整为零,易于小团队开发
  • 独立:独立开发、独立测试及独立部署(简单部署)、独立运行(每个服务运行在其独立进程中)
  • 技术选型灵活:支持异构(如:每个服务使用不同数据库)
  • 容错:故障被隔离在单个服务中,通过重试、平稳退化等机制实现应用层容错
  • 松耦合、易扩展:可根据需求独立扩展

  面临的挑战:

  • 分布式环境下的数据一致性【更复杂】
  • 测试的复杂性【服务间依赖测试】
  • 运维的复杂性

  设计约束:

  • 1、微服务个体约束【每个微服务都是独立的,修改一个微服务不能影响另一个微服务】
  • 2、微服务与微服务之间的横向关系【通过第三方服务注册中心来满足服务的可发现性】
  • 3、微服务与数据层之间的纵向约束【数据是微服务的“私产”,访问时需要通过微服务】
  • 4、全局视角下的微服务分布式约束的角【高效运维整个系统】

云原生架构风格

  基本概念:云计算是集合了大量计算设备和资源,对用户屏蔽底层差异的分布式处理架构,其用户与提供实际服务的计算资源是相分离的

  优点:超大规模、虚拟化、高可靠性、高可伸缩性、按需服务、成本低【前期投入低、综合使用成本也低】。

  分类:

  云计算架构:

  • 管理层:提供对所有层次云计算服务的管理功能
  • 用户访问层:方便用户使用云计算服务所需的各种支撑服务,针对每个层次的云计算服务都需要提供相应的访问接口。
  • 应用层:提供软件服务,如: 财务管理,客户关系管理,商业智能。
  • 平台层:为用户提供对资源层服务的封装,使用户可以构建自己的应用。
  • 资源层:提供虚拟化的资源,从而隐藏物理资源的复杂性。如: 服务器,存储。

边缘计算

  定义:指在靠近物或数据源头的一侧,采用网络、计算、存储、应用核心能力为一体的开放平台,就近提供最近端服务

  本质:计算处理职能的本地化