【系统架构师】12. 软件架构设计


阅读数:   

内容提要

最为重要的章节，主要分为2个部分，基础理论和案例分析

image-20250406220031884

软件架构的概念

概念并不统一，不同的人有不同的角度和结论

image-20250406220314717

类似建筑风格

image-20250406220816732

image-20250406221207878

D 架构是打通需求分析和软件设计之间的鸿沟，并不需要考虑是否满足用户功能性需求（架构应该主要偏向非功能性需求）

架构师关注的是“系统能否长期稳定、高效地支撑功能”，而非功能本身的对错。

image-20250406221536718

了解即可，主要为了引出4+1视图

统一建模语言 UML

image-20250406221629733

4+1视图中的1即是场景，对应用例图

image-20250406221842829

A D C

进程视图也称之为过程视图

软件架构风格-ADL

image-20250406222040300

主要考察点就是三要素

image-20250406222141884

C 组件接口和连接件不是同一回事，另外组件对应的即是构件

基于架构的软件开发方法

image-20250406222321045

所谓视图就是人从不同角度（视角）看会得到不同的事物

架构更多是考察非功能性的东西

image-20250407082102325

0:N, 0:M代表可能存在多轮迭代

架构需求、架构设计、架构实现、架构演化过程见下面内容

image-20250407082115857

image-20250407082709950

image-20250407082841013

体系结构就是架构

BCC

image-20250407083101886

ABSDM：基于架构的软件设计模型

AAC

软件架构风格

论文写作基本都考察到

image-20250407083429375

  1. 数据流风格
    • 特点：数据在系统中按照一定的流程进行处理，从输入到输出，经过一系列的处理步骤。各处理单元（过滤器）对数据进行加工，数据像流水一样在系统中流动，处理过程是顺序的、线性的。
    • 典型架构：管道 - 过滤器架构是数据流风格的典型代表。过滤器是具有输入和输出的独立模块，对输入数据进行特定转换后输出；管道则负责连接过滤器，传递数据。例如在文本处理系统中，一个过滤器可能负责将文本转换为大写，另一个过滤器负责统计单词数量，数据通过管道在这些过滤器间流动。
    • 应用场景：适合处理具有明确数据处理流程、数据处理步骤相对独立的场景，如编译器前端的词法分析、语法分析和语义分析过程，以及信号处理领域。
  2. 调用 / 返回风格
    • 特点：通过函数或过程的调用和返回机制来实现系统功能。程序由多个模块组成，模块之间通过调用其他模块的函数来获取服务，被调用模块执行完后将结果返回给调用者。
    • 典型架构：主程序 - 子程序架构是常见的调用 / 返回风格架构。主程序控制整体流程，调用各个子程序完成具体任务，子程序执行结束后返回结果给主程序。还有分层架构也属于这种风格，上层模块调用下层模块提供的服务。
    • 应用场景：广泛应用于传统的软件开发中，特别是在算法实现、业务逻辑处理等方面，如企业信息管理系统中的业务模块调用。
  3. 独立构件风格
    • 特点：系统由多个独立的构件组成，这些构件可独立运行、部署和升级。构件之间通过消息传递或接口调用进行交互，相互之间耦合度较低。
    • 典型架构：微服务架构是独立构件风格的代表。每个微服务都是一个独立的构件，实现特定的业务功能，如用户管理微服务、订单管理微服务等。它们通过轻量级的通信机制（如 RESTful API）进行通信。
    • 应用场景：适用于大型复杂系统的开发，尤其是业务变化频繁、需要快速迭代和扩展的场景，如互联网电商平台、社交媒体平台等。
  4. 虚拟机风格
    • 特点：通过模拟一个虚拟的运行环境来执行程序。虚拟机提供了一套抽象的指令集和运行机制，使得程序能够在不同的真实环境中以相同的方式运行。
    • 典型架构：常见的有 Java 虚拟机（JVM）、脚本语言解释器等。以 JVM 为例，Java 程序编译成字节码后在 JVM 中运行，JVM 负责字节码的解释执行、内存管理等。
    • 应用场景：适用于需要跨平台运行的程序，以及动态语言的执行环境，如 Python 的解释器使得 Python 程序可以在多种操作系统上运行。
  5. 以数据为中心的风格
    • 特点：数据处于系统的核心位置，系统的主要操作围绕数据的存储、访问和处理展开。其他组件通过对数据的操作来实现系统功能。
    • 典型架构：黑板架构和数据库系统架构属于以数据为中心的风格。黑板架构中，黑板作为共享数据区，多个知识源对其进行读写操作；数据库系统架构中，应用程序通过数据库管理系统对数据库中的数据进行增、删、改、查等操作。
    • 应用场景：适用于数据处理量大、数据共享需求高的场景，如数据挖掘、数据分析系统，以及企业资源规划（ERP）系统中对大量业务数据的管理。

数据流风格

image-20250411082756057

传统编译器（如C语言）：数据流风格

现代集成开发环境：仓库风格

image-20250411200412687

注意区分是否是数据流风格的子风格，子风格之间差异主要在于数据和交互上

调用/返回风格

image-20250411200758636

image-20250411200733067

对于一些系统来说，分层增加了数据传递的效率则不合适（如聊天应用）

另外对于高耦合度的也不适合分层，这个倒是容易理解

独立构件风格

image-20250411201422030

有点类似设计模式中的代理

image-20250411202952078

独立构件风格比较少考缺点，了解即可

image-20250411202923840

即通过事件进行沟通，如JS中的postMessage

虚拟机风格

image-20250411203654773

最出名的就是 Java虚拟机，具有跨平台特性

image-20250411203741693

虚拟机风格的子风格

image-20250411204246050

image-20250411204606201

加强版的解释器，结构和解释器的结构类似（感觉就是一样），主要区别就是知识库部分

仓库风格

image-20250411205314963

以数据为中心的风格

  • 黑板系统：是一种软件架构模式，模仿多个专家系统协作解决问题的场景。由黑板、知识源和控制组件构成，黑板是中心数据结构，存储问题解决过程中的所有信息；知识源是处理部分信息并将结果写回黑板的专家系统；控制组件协调知识源工作顺序。其特点是灵活性高、能处理复杂问题、可并行处理，但控制复杂。常用于人工智能、信号处理、决策支持系统等领域。
  • 超文本系统：是基于超文本和超媒体的信息管理和展示系统，以超文本形式组织和呈现数据，允许文档间通过链接相互关联，支持多种媒体格式。具有多媒体支持能力强、信息组织非线性、可访问性和互动性好等特点。广泛应用于互联网、知识管理系统、电子文档系统等。

image-20250411205335775

image-20250411205723147

操作系统的注册表、剪贴板也是常见的仓库风格

闭环控制架构

image-20250411211646709

差异在于 比较器和反馈

不适用于非常复杂的场景，不属于5大风格，但是会常考到

C2风格

image-20250411212110489

属于层次型的架构风格

构件之间不允许直连

习题讲解1

image-20250411212330001

  • 虚拟机
  • 数据流（关键词：报文解析及后续处理）
  • 隐式调用/事件驱动（关键场景：当xx的时候）
  • 解释器（关键字：自行创建）
  • 过程控制

image-20250411212902061

  • 黑板风格（关键词：语音识别）
  • 解释器（比较有争议，一开始的选择隐式调用，但是其中“定义探测任务和任务之间的时序依赖性”更适合解释器）
  • 事件驱动/隐式调用

习题讲解2

image-20250411213414231

集成开发环境通常会涉及多种架构风格，如仓库风格（数据为中心）、隐式调用（事件调用/UI相关）、数据流（依次处理），解题时注意区分

（1）B 程序源代码作为一个整体，依次在不同模块中进行传递，因此是数据流风格。“作为整体”，是批处理的特点

（2）C 不同工具之间信息交互，故是以数据为中心

（3）A 界面相关

（4）B 设计模式放大一层就是架构，这里选型ABC都是设计模式，因此考察的其实是设计模式。题干提到不匹配去适配，因此是适配器模式，选B

（5）D 跨平台

MDA

image-20250412134836205

image-20250412134824826

平台无关模型 通过变换工具转成了 平台相关模型，再通过变换工具转成 代码

应用场景不大

image-20250412134926204

特定领域软件架构

image-20250412135825388

image-20250412140042713

专家 是 出意见的人，其他都是干活的人

image-20250412142739539

image-20250412142829950

DSSA是思想，具体实现时要有模型

image-20250412142920566

C 分析-设计-实现-专家

C

软件架构评估

image-20250412143050385

为什么要进行架构评估

  1. 保障业务适配：业务需求持续演进，新功能不断涌现。架构评估确保架构能灵活适应业务变化，避免因架构僵化阻碍业务发展，使系统始终紧密贴合业务目标。
  2. 确保质量达标：系统的性能、可靠性、安全性等质量属性至关重要。架构评估提前识别可能影响这些属性的问题，如性能瓶颈、安全漏洞，保证系统交付后能稳定、高效、安全运行。
  3. 控制项目成本：在项目早期进行架构评估，能及时发现架构缺陷并修正，避免后期因架构问题导致大规模返工，节省开发和维护成本，提高资源利用效率。

架构评估评什么

  1. 架构与业务匹配度：考察架构设计对业务功能和流程的支持程度，是否清晰映射业务需求，能否为业务发展提供有力支撑。
  2. 质量属性
    • 性能：评估系统在高并发、大数据量等场景下的响应时间、吞吐量等性能指标，判断是否满足业务需求。
    • 可靠性：分析系统应对故障的容错能力、恢复能力，如是否具备冗余设计、数据备份恢复机制。
    • 安全性：查找架构中的安全隐患，如身份认证、授权机制是否健全，数据传输和存储的加密措施是否到位。
    • 可维护性：判断架构的模块化、分层是否合理，模块间耦合度是否适中，是否便于理解、修改和扩展。
  3. 技术可行性：审查所选用的技术框架、工具、平台等在现有团队技术能力、时间和预算限制下的可行性与成熟度。
  4. 可扩展性：考量架构能否方便地增加新功能模块、扩展处理能力，以适应业务规模的增长。

架构评估怎么评

  1. 基于场景的评估
    • 确定关键场景：与利益相关者沟通，梳理系统典型的使用场景，如电商系统的 “高并发下单”“大促活动商品展示” 等场景。
    • 场景分析：针对每个场景，评估架构设计能否满足其性能、可靠性等要求，通过模拟场景进行分析。
  2. 检查表评估
    • 制定检查表：依据架构设计原则、最佳实践以及过往项目经验，整理涵盖架构各方面的检查表，如架构分层是否合理、安全机制是否完备等检查项。
    • 逐一检查：对照检查表对架构进行详细审查，标记不符合项，深入分析并提出改进建议。
  3. 专家评审
    • 邀请专家：邀请架构领域专家、有类似项目经验的技术人员等组成评审小组。
    • 评审会议：由架构设计师详细介绍架构设计，专家提问、讨论，从不同视角评估架构的合理性、优缺点，形成评审意见。
  4. 模型评估
    • 建立模型：使用架构建模工具创建架构的抽象模型，如 UML 模型，直观展示架构的结构、组件关系。
    • 模型分析：借助模型分析工具，对架构的性能、可靠性等属性进行量化分析和预测，为架构优化提供数据支持。

质量属性

image-20250412143446783

不同标准对质量属性的划分不同，以讲义内容为准学习即可

性能

image-20250412143846393

性能：系统的响应能力

提升性能（的战术）有3个维度，资源需求、资源管理、资源仲裁

可用性

image-20250412144511021

可用性：正常运行的时间比例

服务器删除：将有问题的程序从服务器删除

安全性

image-20250412144908732

安全性：能拒绝向非授权用户提供服务

可修改性

image-20250412145532920

可修改性：快速对系统进行变更的能力

隐藏信息相当于类中的private，将变量通过方法（get/set）去隐藏

易用性和可测试性

image-20250412150317790

易用性：系统被使用的容易程度

可测试性：通过测试揭示软件缺陷的容易程度

习题讲解

image-20250412150640119

A 限制访问倾向于安全性，运行时注册和接口实现分离倾向于可修改性

D 分层结构（高内聚低耦合）、事务机制（数据库的事务机制）对性能影响不太明显。主动冗余-可用性。

A 其他相关性都极低

image-20250412151623756

BAACCA

第2空中BC都是可以提高性能的，因此需要结合题干分析，题干中提到“优先级管理”，因此更适合选C资源仲裁

最后一空中，A和D都是安全性的战术，答案比较有争议，这里我们选A。因为一般权限控制适合对于普通的用户进行限制。检测攻击才能用最底层的进行防范。

敏感点、权衡点、风险点、非风险点

image-20250412154041730

（1）敏感点（设计策略对结果的影响）

（2）非风险点（固定表述）

（3）风险点（突出风险）

（4）权衡点（安全与性能）

image-20250412154950132

+：正相关

-：负相关

架构评估方法

image-20250412155123366

image-20250412155216275

image-20250412155653154

实用性 即 可用性

SAAM

软件架构分析法

image-20250412155915990

ATAM

架构权衡分析法

image-20250412160254554

在 SAAM 的基础上发展而来，特点是增加了对质量属性进行评价和折中，并且分阶段，每个阶段都有对应的任务

习题讲解

image-20250412160550336

D（性能和安全）

B（固定搭配） 即使有 性能 这个选项也不能选，因为这里不是提要求，而是摆现实

image-20250412160852698

A - ATAM是一种架构评估方法，还没有代码产生

B - 主要看系统的实现是否可以满足需求，而不需要考虑需求的准确性

C - 还没有到系统测试环境

D - 故选它，架构评估本身就是没办法精确

image-20250412161217602

C 见前面ATAM的介绍，记忆即可

C 架构描述又称之于体系结构描述

质量效用树

image-20250412161507649

软件产品线

image-20250412161710556

DSSA： 特定领域架构

通俗来说，软件产品线相当于给多家公司做的产品共性部分

image-20250412162203808

领域工程：共性的领域处理（核心组，做共性部分的维护）

应用工程：具体的应用实现（应用组，完成个性化的要求）

image-20250412162343890

有个前提是在某个领域做了多年的积累

image-20250412162634987

构件与中间件技术

概念

image-20250412164017107

image-20250412170154140

image-20250412170215854

中间件：tomcat、nginx这类软件，为应用软件服务的。

image-20250412170719863

中间件

image-20250412170901932

构建的标准

image-20250412171308143

image-20250412171603071

image-20250412173332005

A 概念题

复用

image-20250412162829111

复用的维度：

水平复用：不分行业领域，通用

垂直复用：分行业领域，专用

image-20250412163135269

image-20250412163551326

功能，数据，对象

image-20250412163727602

B 水平是不同领域的（通用），垂直才是同一领域（特殊）

image-20250412163821164

C 按照前面提到的概念，构建组装技术有基于 功能、数据、对象 的，就是么有基于实现的

本文作者： ionluo
本文链接： http://www.ionluo.cn/blog/posts/2106b4a6.html
版权声明： 本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。转载请注明出处！
知识共享许可协议

扫一扫，分享到微信

微信分享二维码

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true