企业官网建设流程全解析

软件架构设计是系统架构分析与设计中的关键环节，其中包含不同的软件架构设计风格、软件架构开发方法、软件设计中的非功能性需求、软件架构评估以及系统架构的演化等。本文简单整理了这些基本概念以了解。

从系统架构设计师的角度，屡败屡战后在上半年非常侥幸的通过，工作中的考试或许就是一个“一鼓作气再而衰三而竭”的过程，有时候会带有一定的运气成分。以考代学，对架构设计的基本概念也有一定的认识和理解，以下之前整理的相关素材可以作为参考。

1. 架构系列之软件工程基本概念
2. 架构系列之DevOps的核心理念与方法实践
3. 架构系列之Service Mesh服务网格基本概念解析
4. 架构系列之分布式事务常见实现算法基本介绍
5. 架构系列之分布式系统的防重和幂等机制
6. 架构系列之负载均衡相关基本概念
7. 架构系列之微服务架构设计的原则和约束
8. 架构系列之云原生架构中常用架构模式
9. 架构系列之六边形架构介绍

1、软件架构的概念

1.1 软件架构的定义

一个程序和计算系统软件体系结构是指系统的一个或多个结构。结构中包括软件的构件、构件的外部可见属性以及它们之间的相互关系

1.2 软件架构设计与生命周期

1）需求分析阶段：需求分析和软件架构，根据需求模型构建SA模型、保证模型转换的可跟踪性。

• 在需求阶段研究SA，将SA概念贯穿整个软件生命周期

2）设计阶段：SA模型的描述、SA模型的设计与分析方法、SA设计经验的总结与复用

• 经典4+1模型：逻辑视图、进程视图、开发视图、物理视图加上统一场景
• UML统一建模语言：逻辑视图（类与对象）、实现视图（物理代码文件和组件）、进程视图（线程和进程）、部署视图（软件到硬件的映射）加上用例视图（需求分析模型）

3）实现阶段：基于SA的开发过程支持、从SA向实现的过渡路径、基于SA的测试技术

4）构件组装阶段：可复用构建的互联、组装过程中检测并消除体系结构失配的问题。

• 中间件提供构件之间跨平台的交互能力

5）部署阶段：提供高层的体系结构视图来描述部署阶段的软硬件模型、分析部署方案的质量属性

6）后开发阶段：围绕维护、演化、复用等方面

• 动态软件体系结构：软件内部执行所导致的体系结构改变；软件系统外部请求对软件进行的重配置
• 体系结构恢复与重建：从已实现的系统中获取体系结构的过程

1.3 架构描述语言ADL

ADL是在底层语义模型的支持下，为软件系统的概念系统结构建模提供了具体语法和概念框架

• 构件：计算或数据存储单元
• 连接件：构件之间相互建模的体系结构构造块及支配交互的规则
• 架构配置：描述体系结构的构件与连接中的连接图

2、软件架构风格

2.1 数据流风格

2.1.1 批处理

每个处理都是单独的程序，每一步在前一步结束后才开始。数据必须是完整的，以整体的方式传递。

2.1.2 管道过滤器

处理步骤由过滤器实现，数据传输由管道负责

2.2 调用/返回风格

2.2.1 主程序/子程序

单线程控制，构件为主程序和子程序、过程调用充当连接件

2.2.2 面向对象体系

建立在面向对象和数据抽象的基础上，构件是对象或抽象数据类型的实例

2.2.3 层次型体系

每一层为上层提供服务，并作为下层的客户；构件在层上实现了虚拟机

2.2.4 客户端/服务器

两层C/S和三层C/S，三层C/S分为表示层、功能层和数据层

2.3 独立构件风格

2.3.1 进程通信体系结构

构件是独立的过程、连接件是消息传递。消息传递的方式可以是点对点、异步或同步方式以及远程过程调用

2.3.2 事件系统体系结构

基于事件的隐式调用，构件不直接调用一个过程，而是触发或广播一个或多个事件

2.4 虚拟机风格

2.4.1 解释器体系

包含解释工作的解释引擎、被解释代码的存储区、记录解释引擎当前的工作状态、记录源代码被解释执行的进度；含有一个虚拟机，仿真硬件的执行过程和一些关键应用。

2.4.2 规则系统

包括规则集、规则解释器、规则/数据选择器及工作内存

2.5 以数据为中心（仓库）风格

2.5.1 仓库体系风格

存储和维护数据的中心场所：中央数据构件以及对中央数据构件进行操作的独立构件，连接件为仓库与独立构件之间的交互

2.5.2 黑板体系风格

问题求解模型，组织推理步骤、控制状态数据和问题求解领域的知识框架，应用在语音识别、模式识别等

2.6 闭环控制架构

适合嵌入式系统，用于简单闭环控制问题，如空调温控、定速巡航

2.7 C2风格

构件和连接件都有一个顶部和一个底部；构件的顶部要连接到连接件的底部，构件的底部要连接到连接件的顶部

3、层次化架构风格

3.1 C/S架构

3.1.1 两层C/S架构

将应用功能划分为客户端（表示层）和服务器（数据层）端的网络架构模式

3.1.2 三层C/S架构

在两层架构的基础上，将应用功能进一步划分为表示层、功能层和数据层三个部分的网络架构模式

• 表示层：位于客户端，负责与用户进行交互，显示数据和接收用户输入
• 功能层：应用服务器层，负责处理业务逻辑和应用程序的执行。它接收表示层的请求，与数据层进行交互，并将处理结果返回给表示层。
• 数据层：负责数据的存储和管理。它根据功能层的请求进行相应的数据操作，并返回结果。

两层C/S架构相对简单、三层C/S安全性更高

3.2 B/S架构

将系统功能实现的核心部分集中到服务器中，同时简化了系统的开发、维护以及使用。用户通过浏览器即可访问服务器上的应用程序，无需安装其他客户端。

• 缺乏对动态页面的支持能力，没有集成有效的数据库处理能力
• B/S架构的安全性难以控制
• 速度查询等响应速度上低于C/S架构
• 数据提交一般以页面为单位，数据的动态交互性不强

3.2.1 三层B/S

1. MVC风格：Model-处理应用程序中数据逻辑部分、View-处理数据显示部分、Controller-处理用户交互部分。缺点是视图和控制器之间的交互可能过于紧密，导致代码难以维护；Controller承担过多的业务逻辑
2. MVP风格：MVC的变种，实现View和Model之间的解耦。Presenter作为中间层，负责接收用户的输入、调用模型以及更新视图。它充当了视图和模型之间的桥梁，协调它们之间的交互。
3. MVVM风格：ViewModel作为中间层，负责协调视图和模型之间的交互。它封装了业务逻辑和数据转换逻辑，并将模型中的数据转换为视图可以显示的数据格式。

3.3 基于服务的架构SOA

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

• 服务：服务是自包含的、模块化的软件组件，可以被不同的应用程序或业务流程调用。
• 接口：接口是服务之间的通信方式，它采用中立的方式进行定义，独立于实现服务的硬件平台、操作系统和编程语言。
• 松耦合：服务之间松耦合，意味着服务之间是相互独立的，修改一个服务不会影响其他服务。降低了服务之间的依赖性，有利于系统的模块化和维护。

3.3.1 核心功能

• 服务识别与定义：识别业务功能并将其定义为独立的服务。
• 服务抽象：隐藏服务内部实现的细节，只暴露接口。
• 服务目录：创建服务目录或注册中心，以便服务消费者发现可用服务。
• 服务组合：允许通过组合多个服务来构建复杂的业务流程。
• 服务交互：实现服务之间的通信和数据交换。

3.3.2 特点与优势

• 重用性：服务可以在不同的应用程序和业务流程中重复使用，提高了系统的开发效率和维护成本。
• 互操作性：服务遵循标准协议，可以在不同的平台和环境中工作，实现了跨系统的互操作性。
• 标准化：服务接口遵循标准化的协议，如SOAP、REST等，使得服务之间的通信更加规范和可靠。
• 灵活性：SOA架构将系统拆分成独立的服务，可以按需组合和重组这些服务，从而实现系统的快速扩展和灵活部署。
• 可维护性：由于服务之间的松耦合关系，降低了服务之间的依赖性，使得系统的维护更加简单和方便。

3.4 微服务

将单一的应用程序划分为一组小的服务，每个服务之间互相协调、互相配合，每个服务运行在独立的进程中，服务与服务之间采用轻量级的通信机制互相沟通

3.4.1 特性

• 服务分解：应用程序被分解成一组小型服务，每个服务实现特定的业务功能。
• 独立部署：每个微服务都可以独立部署，不会影响其他服务。
• 技术异构性：允许使用多种编程语言和技术栈来开发不同的微服务。
• 易于维护和理解：每个微服务都是独立的代码库和部署单元，职责清晰。
• 高度解耦：微服务之间通过轻量级通信机制进行通信，如HTTP/REST、消息队列等。

3.4.2 缺陷与挑战

• 部署与运维复杂：需要管理多个服务单元，每个服务单元都需要部署、监控和管理。部署自动化
• 服务间的依赖测试与管理
• 网络延迟和错误：微服务之间通过网络进行通信，可能会受到网络延迟和错误的影响。
• 数据一致性难以保证：每个服务单元都独立运作，需要在服务单元之间保持数据一致性。
• 安全性问题：微服务架构涉及多个服务单元之间的网络通信，存在数据泄露、劫持等安全问题。

3.4.3 微服务与SOA对比

4、软件架构复用

4.1 复用类型

• 机会复用：开发过程中只要发现有可复用的资产既对其复用
• 系统复用：开发之前进行规划，以决定哪些需要复用

4.2 复用原因

• 可以减少开发工作、减少开发时间以及降低开发成本，提高生产力
• 提高产品质量使其具有更好的互操作性
• 产品维护变得简单

4.3 基本过程

• 构造/获取可复用的资产
• 管理可复用资产
• 使用可复用资产

5、基于架构的软件开发ABSD

ABSD的概念与术语：自顶向下、递归细化的方法。强调由业务、质量和功能需求的组合驱动设计

• 视角与视图：用不同的视角观察对架构的描述
• 用例与质量场景：用例捕获功能需求、特定场景捕获质量需求

5.1 ABSD开发模型

5.1.1 架构需求

• 需求获取：定义开发人员必须实现的软件功能以及获得软件质量属性的非功能性需求；
• 标识构件：分为生成类图、对类进行分组、把类打包成构件
• 需求评审：需求是否满足用户需求、类的分组是否合理、构件合并是否合理等

5.1.2 架构设计

• 提出软件体系结构模型：通过体系结构模型，获得关于体系结构属性的理解
• 把已标识的构件映射到软件体系结构中
• 分析构件之间的相互作用
• 产生软件体系结构
• 设计评审

5.1.3 架构文档化

输出体系结构规格说明和测试体系结构需求的质量设计说明书

5.1.4 架构复审

标识潜在的风险，及早发现体系结构设计中的缺陷与错误

5.1.5 架构实现

以复审后的文档化体系结构说明书为基础，经过分析设计、构件实现、构件组装和系统测试阶段

5.1.6 架构演化

需求变动或变化后，相应修改软件架构。包括：需求变化归类、制定架构演练计划、修改删除增加构件、更新构件相互作用、构件组装与测试、最后技术评审

6、特定领域的软件架构DSSA

6.1 基本概念

在一个特定应用领域中为一组应用提供提供组织架构参考的标准软件体系结构

• 垂直域：包含整个系统族内的多个系统
• 水平域：定义多个系统和系统族中功能区域的共有部分

6.1.1 领域分析

获得领域模型，领域模型描述领域中系统之间的共同需求

6.1.2 领域设计

获得DSSA，领域模型中表示需求的解决方案

6.1.3 领域实现

依据领域模型和DSSA开发和组织可重用信息

6.2 DSSA参与人员

领域专家、领域分析人员、领域设计人员和领域实现人员

6.3 DSSA领域建立过程

• 定义领域范围
• 定义领域特定的元素
• 定义领域特定的设计和实现需求设计
• 定义领域模型和体系结构
• 产生、搜集可重用的产品单元

7、软件质量属性

定义：软件系统与明确地或隐含地定义的需求相一致的程度

7.1 性能

性能指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或在某段时间内系统所能处理的事件的个数

7.2 可靠性

软件系统在系统或应用错误面前，在意外或错误使用的情况下维持软件系统功能特性的基本能力

• MTTF（平均失效等待时间）
• MTBF（平均失效间隔时间）
• 容错：错误发生时确保系统正确的行为，并进行内部修复
• 健壮性：在发生意外错误事件时确保应用系统处于预先定义好的状态

7.3 可用性

指系统能够正常运行的时间比例。用两次故障之间的长度或在出现故障时候系统能够恢复正常的速度来表示

7.4 安全性

指系统向合法用户提供服务的同时能够阻止非授权用户的使用企图和拒绝服务能力

7.5 可修改性

对系统进行变更的能力

• 可维护性：错误发生后可修复软件系统
• 可扩展性：使用新特性扩展系统，使用改进版本替换构件
• 结构重组：重新组织软件系统构件及构件间的关系
• 可移植性：软件系统适用于多种硬件平台、操作系统、编程语言或编译器等

7.6 功能性

系统完成所期望工作的能力

7.7 可变性

架构经扩充或变更成为新架构的能力

7.8 互操作性

为外部可视的功能特性和数据结构提供精心设计的软件入口

7.9 质量属性场景

7.9.1 质量效应树

质量属性效用树从根节点到叶节点包含四个固定层级，其顺序和含义如下：

• 树根：代表系统的整体目标，例如“电商平台核心系统”。
• 质量属性：一级分支，即系统关注的核心质量维度，如性能、安全性、可用性、可维护性等。
• 属性分类：二级分支，对质量属性进行细化。例如，将“性能”细化为“延迟”和“吞吐量”，或将“安全性”拆解为“机密性”、“完整性”等。
• 质量属性场景：叶节点，是具体、可测量的需求描述。例如，“99.9%事务的响应时间小于1秒”。

7.10 质量属性场景描述

• 刺激源：生成该刺激的实体
• 刺激：当刺激到达系统时需要考虑的条件
• 环境：该刺激在某些条件内发生
• 制品：某个制品被刺激
• 响应：激励在到达后所采取的行动
• 响应度量：响应发生时能够以某种方式进行度量，以对需求进行测试

8、软件架构评估

系统架构的评估方法：基于调查问卷或检查表、基于场景、基于度量

8.1 敏感点和权衡点

• 敏感点是一个或多个构件的特性
• 权衡点是影响多个质量属性的特性，是多个质量属性的敏感点
• 风险点是指架构设计中潜在的、存在问题的架构决策所带来的影响
• 非风险点指不会带来隐患的分析与描述

8.2 系统架构评估方法

8.2.1 SAAM软件架构分析法

关注可修改性主要质量属性。过程：场景开发、架构描述、单个场景评估、场景交互和总体评估

8.2.2 ATAM架构权衡分析法

系统的可修改性、安全性、性能和可用性。过程：场景和需求收集、架构视图和场景实现、属性模型的构造和分析、折中

8.2.3 CBAM成本效益分析法

质量属性为项目干系人带来收益。

步骤：整理场景、对场景进行求精、确定场景的优先级、分配效用、架构策略涉及哪些质量属性及响应级别、确定期望的质量属性级别、计算各策略架构的总收益、根据受成本影响的ROI选择架构策略

8.3 ATAM方法评估实践

8.3.1 演示

1. 介绍ATAM
2. 介绍业务驱动因素
3. 介绍要评估的体系结构

8.3.2 调查和分析

1. 确定架构方法
2. 生成质量属性效用树：根节点-效用->质量属性->场景->场景实现
3. 分析体系结构方法：确定风险、无风险、敏感点和权衡点

8.3.3 测试

1. 头脑风暴和优先场景
2. 分析架构方法

8.3.4 报告ATAM

评估期间收集的所有信息，包括效用树、生成的场景、分析问题、确定的风险和非风险、确定的架构方法

9、软件可靠性

9.1 定义

软件产品在规定条件和规定时间完成规定功能的能力

9.2 可靠性定量描述

• MTTF（Mean Time To Failure）：系统正常运行到发生故障时间
• MTTR（Mean Time To Recovery）：出现故障到恢复的时间
• MTBF（Mean Time Between Failure）：平均故障间隔时间
• MTBF=MTTF+MTTR，MTTR越短越好

9.3 可靠性目标

可靠度、故障强度和平均时效时间等描述

9.4 可靠性管理

9.4.1 需求分析阶段

确定软件可靠性目标、制定可靠性管理框架等

9.4.2 概要设计阶段

可靠性度量、可靠性设计等

9.4.3 详细设计阶段

可靠性设计、可靠性预测等

9.4.4 编码阶段

可靠性测试、收集可靠性数据等

9.4.5 测试阶段

可靠性测试、可靠性建模和评价等

9.4.6 实施阶段

可靠性测试、可靠性评价等

9.5 可靠性设计

9.5.1 设计原则

• 容错技术设计
• 降低复杂度
• 检错技术

9.5.2 N版本程序设计

• 增加了三个阶段：相异成分规范评审、相异性确认、背对背测试
• N版本程序的同步、程序之间的通信、表决算法、一致比较问题、数据相异性

9.5.3 恢复块方法

• 保证主块和后备块之间的独立性，主块和备块之间的共性程度降到最低
• 必须保证验证测试程序的正确性

9.5.4 系统配置技术

双机热备、服务器集群技术

9.6 可靠性测试

• 可靠性目标的确定：保证软件的可靠性达到要求
• 运行剖面的开发：软件的使用行为建模、开发使用模型
• 测试用例的设计：针对特定的功能或组合功能设计测试方案，并编写成文档
• 测试实施
• 测试结果分析

9.7 可靠性评价

• 选择可靠性模型
• 收集可靠性数据
• 可靠性评估和预测

10、软件架构的演化

• 单体架构
• 垂直架构
• 使用缓存
  • 缓存与数据库的数据一致性问题
  • 缓存技术对比
  • Redis分布式存储方案
  • Redis数据分片的方式
  • Redis数据淘汰算法
  • Redis持久化
  • Redis缓存雪崩
  • Redis缓存穿透
  • 缓存预热、缓存更新与缓存降级
• 使用服务集群
• 数据库读写分离
• 使用反向代理和CDN
• 使用分布式文件系统和分布式数据库
• 使用搜索引擎和NoSQL
• 业务拆分
• 分布式服务

11、软件与中间件

11.1 构件

• 构件是一组组装单元，具有规范的接口规约和显示的语境依赖
• 独立部署单元
• 作为第三方组装单元
• 没有外部可见状态
• 构件是一组需要同时部署的原子构件，构件和原子构件的区别是大部分原子构件不会被单独部署
• 原子构件是一个模块和一组资源

11.2 中间件

中间件是一类构件，也是一类系统软件

• 面向需求：设计师集中精力于业务逻辑本身
• 业务的分隔和包容性：按照不同的业务进行功能划分，体现为不同的接口或交互模式
• 设计与实现隔离：通过接口实现，不必关心内部实现
• 隔离复杂的系统资源：将系统资源与应用构件隔离
• 符合标准的交互模型：实现了架构模型，实现了标准的协议
• 软件复用：提供了构件封装、交互规则、与环境的隔离，为软件复用提供了解决方案
• 提供对应用构件的管理：构件可以通过标识机制进行划分，方便管理

11.3 构件的复用

水平复用：部分行业领域，通用；垂直复用：分行业领域，专用

11.3.1 检索与提取构件

• 基于关键字检索：树形或有向无回图结构
• 刻面检索法：利用Facet描述构件执行的功能、被操作的数据、构件应用的语境等
• 超文本检索法：按照人类的联想思维方式任意跳转到包含相关概念或构件的文档

11.3.2 理解与评价构件

构件的开发过程遵循公共标准

11.3.3 修改构件

构件的功能、行为和接口设计更为抽象化、通用化和参数化

11.3.4 组装构件

1）组装的三种方式

• 基于功能的组装：基于子程序调用和参数传递的方式将构件组装起来
• 基于数据的组装：面向数据的设计方法
• 面向对象的组装：以基类为父类，生成相应的子类

2）构件组装失配的问题

• 由构件引起的失配
• 由连接子引起的失配
• 由于系统成分对全局体系结构的假设存在冲突引起的失配

11.4 构件的标准

COBRA、COM、EJB

12、Web架构设计

• 单体应用到数据库与Web服务器分离
• 应用服务器集群
• 负载均衡的引入
  • 应用层负载均衡和传输层负载均衡
  • 负载均衡算法
• 有状态和无状态服务
• 持久化技术ORM
  • ORM为对象与关系数据之间的映射
• 数据库读写分离
• 用缓存缓解读库的压力
  • Redis特性
• 内容分发网络CDN
  • 尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输得更快、更稳定
• 响应式Web设计
  • 页面设计布局，智能的根据用户行为以及使用的设备环境进行相对应的布局
• 业务中台和数据中台
• Web系统分层

参考资料

1. 架构系列之软件工程基本概念
2. 系统架构设计师第二版教程
3. 软件架构实践