导图社区软件架构设计

软件架构设计

"软件架构设计的艺术：从理论到实践的全面指南！本文涵盖软件架构的核心概念（如‘4 1’视图、质量属性）、主流风格（微服务、SOA、REST等）及关键技术（中间件、云原生、边缘计算）通过案例解析大型网站演化路径（从业务拆分布式服务），深入探讨架构评估方法（场景分析、效用树）与复用策略（DSSA、产品线）无论你是学习层次式架构设计，还是研究中台与JWT等前沿趋势，这里都能找到系统化的知识脉络。"

编辑于2025-06-27 14:46:15

软件架构
云计算技术
微服务与SOA

halo

他的近期作品查看更多>>

软件架构设计

社区模板帮助中心，点此进入>>

halo

他的近期作品查看更多>>

相似推荐
大纲

互联网9大思维
- 33.7k
- 900
- 2.4k
- 389
MindMaster
产品立项报告
- 7.8k
- 893
- 334
- 14
江边朝阳
产品经理如何做好项目管理
- 6.9k
- 48
- 209
- 10
issen
经验分享：产品经理必懂的产品思维
- 4.9k
- 399
- 230
- 13
(*^▽^*)
产品诞生过程
- 3.5k
- 215
- 274
- 16
(*^▽^*)
产品周期图
- 4.0k
- 489
- 237
- 6
(*^▽^*)
开门红的思考
- 2.0k
- 2
- 86
- 1
wuyan
招创智搜
- 686
- 0
- 10
- 0
零点
网易星球
- 496
- 1
- 10
- 3
Risky
教学教务系统
- 1.3k
- 8
- 65
- 6
18993898710

软件架构设计

软件架构的概念（软件体系结构）

架构的本质

为软件系统提供了一个结构、行为和属性的高级抽象

软件架构风格是特定应用领域的惯用模式，架构定义一个词汇表和一组约束

架构的作用

项目干系人进行交流的手段

可传递和可复用的模型，通过研究软件架构可能预测软件的质量。

使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础

降低成本、改进质量、按时和按需交付产品的关键因素

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

三个方面的重要影响

利益相关人员之间的交流

系统设计的前期决策

可传递的系统级抽象

架构描述语言（ADL）

本质

一种形式化语言，在底层语义模型的支持下，为软件系统的概念体系结构建模提供了具体语法和概念框架

分类

C2SADL【基于组件和消息的软件架构描述语言】

Wright【分布、并发类型的架构描述语言】

ACME【架构互换语言】

UniCon【基于组件和连接的架构描述语言】

Rapide【基于事件的架构描述语言】

其他【Darwin、MetaH、Aesop、Neaves、SADL、XADL】

基本要素

构件：计算或数据存储单元。

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

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

“4+1”视图（视角与视图）

基于架构的软件开发方法（ABSD）

概念

ABSD方法是架构驱动，即强调由业务【商业】、质量和功能需求的组合驱动架构设计

ABSD方法有三个基础

第一个基础是功能的分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术

第二个基础是通过选择架构风格来实现质量和业务需求；

第三个基础是软件模板的使用

视角与视图：从不同的视角来检查，所以会有不同的视图

用例用来捕获功能需求、特定场景【刺激、环境、响应】用来捕获质量需求

开发过程

ABSD能很好的【支持软件重用】

ABSD方法是一个自顶向下，递归细化的方法。

软件系统的体系结构通过该方法得到细化，直到能产生软件构件和类。

架构文档化

输出内容

架构规格说明

测试架构需求的质量设计说明书

三大注意事项

文档要从使用者的角度进行编写

必须分发给所有与系统有关的开发人员

且必须保证开发者手上的文档是最新的

架构复审【架构评估】

目的

标识潜在的风险，及早发现架构设计中的缺陷和错误

软件架构风格

架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。软件架构风格是指描述特定软件系统组织方式的惯用模式。组织方式描述了系统的组成构件和这些构件的组织方式，惯用模式则反映众多系统共有的结构和语义。

数据流风格

核心思想

通过数据流驱动系统执行，组件是数据处理单元，连接件是数据流通道

子风格

批处理风格（大量整体数据，无需用户交互）

管道-过滤器风格（流式数据、弱用户交互）

优点

松耦合

良好的重用性/可维护性

可扩展性

良好的屏蔽性

支持并行

缺点

交互性较差

复杂性较高

性能较低（每个过滤器都需要处理和合成数据）

实例

传统编译器

网络报文处理

调用/返回风格

核心思想

通过显示调用链控制程序执行流程

子风格

主程序/子程序（面向过程）

面向对象（对象的方法调用）

分层架构（层与层之前的方法调用）

优点

良好的重用性

可维护性好

可扩展性好，支持递增设计

缺点

并不是每个系统都方便分层

很难找到一个合适的、正确的层次抽象方法

不同层次之间耦合度高的系统很难实现

特点

各个层次的组件形成不同功能级别的虚拟机

多层相互协作且实现透明

独立构件风格

核心思想

通过事件/消息实现组件异步协作

子风格

进程间通信

事件驱动系统（隐式调用）

优点

松耦合

良好的重用性

可修改性

可扩展性

缺点

特点

系统由若干子系统构成且成为一个整体

系统有统一的目标，子系统有主从之分

每一个子系统都有自己的事件收集和处理机制

虚拟机风格

核心思想

通过解释引擎执行自定义逻辑

子风格

解释器（适用于需要自定义规则的场景）

规则系统（在解释器的基础上增加经验规则，适用于专家系统）

优点

可灵活应对自定义场景

缺点

复杂度较高

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

核心思想

以数据存储作为系统核心枢纽

子风格

数据库系统（以数据为中心）

黑板系统

优点

可更改性和可维护性

可重用的知识源

容错性和健壮性

缺点

测试困难

不能保证有好的解决方案

难以建立好的控制策略

低效

开发困难

缺少并行机制

特点

在以数据为中心的基础上，使用中心数据触发业务逻辑部件

实例

语音识别

图像处理

知识处理

超文本系统

闭环控制架构（过程控制）

适用场景

嵌入式系统，用于解决简单闭环控制问题

经典应用

空调温控、定速巡航

C2风格

基本规则

构件和连接件都有一个顶部和一个底部

构件的顶部要连接到连接件的底部，构件的底部要连接到连接件的顶部，构件之间不允许直连。

一个连接件可以和任意数目的其他构件和连接件连接。

当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。

模型驱动架构（MDA）

概念

使用模型完成软件的分析、设计、构建、部署、维护等各开发活动

主要目标

Portability(可移植性)

Interoperability（互通性)

Reusability(可重用性)

核心模型

计算无关模型(CM)

对某具体行业内一个项目的业务需求及其系统功能需求进行分析

平台独立模型(PM)

具有高抽象层次、独立于任何实现技术的模型。

平台相关模型(PSM)

为某种特定实现技术量身定做，让你用这种技术中可用的实现构造来描述系统的模型。PIM会被变换成一个或多个PSM。

代码Code

用源代码对系统的描述（规约）。每个PSM都将被变换成代码。

软件架构复用

概念

【软件复用】是一种系统化的软件开发过程，通过识别、分析、分类、获取和修改软件实体，以便在不同软件开发过程中重复使用

软件开发过程中重复使用相同或相似【软件元素】的过程

历史发展路线

复用的纬度

水平（横向）复用

不分行业领域，通用

垂直（纵向）复用

分行业领域，专用

复用类型

机会复用

开发过程中，只要发现有可复用资产，就对其进行复用

系统复用

开发之前，要进行规划，以决定哪些需要复用

可复用的资产范围

需求、架构设计、元素、建模与分析、测试、项目规划、过程、方法和工具、人员、样本系统、缺陷消除。

特定领域软件机构（DSSA）

基本概念

定义

特定领域软件架构以一个特定问题领域为对象，形成由领域参考模型、参考需求、参考架构等组成的开发基础架构，支持一个特定领域中多个应用的生成。

类型

垂直域：相同领域，深入

水平域：不同领域，平移

基本活动及产出物

参与人员

领域专家

有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等

域专家的主要任务包括提供关于领域中系统的需求规约和实现的知识

领域分析人员

领域分析人员应由具有知识工程背景的有经验的系统分析员来担任

领域设计人员

领域设计人员应由有经验的软件设计人员来担任

领域实现人员

领域实现人员应由有经验的程序设计人员来担任

三层次模型

软件产品线

软件架构评估

质量属性

性能

定义

性能是指软件系统及时提供相应服务的能力，如速度、吞吐量和容量等的要求；性能(performance)是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。

示例

同时支持1000并发

响应时间小于1s;

显示分辨率达到4K。

性能战术

资源需求

提高计算效率

减少计算开销

管理事件率

控制采样频率

资源管理

引入并发

维持多个副本

增加可用资源

资源仲裁

资源调度策略

先进/先出（队列）

固定优先级

动态优先级

静态调用

可用性

定义

系统在一定时间内正常工作时间所占的比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示可用性会受到系统错误，恶意攻击，高负载等问题的影响。

示例

主服务器故障，1分钟内切换至备用服务

系统故障，1小时内修复；

系统支持7×24小时工作。

可用性战术

错误监测

命令/响应（ping/echo）

心跳

异常

错误恢复

表决

冗余【主动/被动】

备件

错误预防

进程监视器

事务

从服务器删除

安全性

定义

指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力安全性(security)是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性【信息不泄露给未授权的用户】、完整性【防止信息被篡改】、不可否认性【不可抵赖】及可控性【对信息的传播及内容具有控制的能力】等特性。

示例

可抵御SQL注入攻击；

对计算机的操作都有完整记录；

用户信息数据库授权必须保证99.9%可用。

安全性战术

抵抗攻击

身份验证

用户授权

数据加密

数据完整性

限制暴露

限制访问

检测攻击

入侵检测

从攻击中恢复

识别：审计追踪

恢复：冗余【与可用性重叠】

可修改性

定义

指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性

包含四个方面

可维护性

可扩展性

结构重组

可移植性

示例

更改系统报表模块，必须在2人周内完成；

对Wb界面风格进行修改，修改必须在4人月内完成。

可修改性战术

局部化修改

维持语义一致性

预期期望的变更

泛化模块

限制可能的选择

抽象通用服务

防止连锁反应

隐藏信息

维持现有的接口

限制通信路径

使用仲裁者

推迟绑定时间

运行时注册

配置文件

多态

组件更换

遵守已定义的协议

易用性

定义

易用性关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持的种类

示例

界面友好；

新用户学习使用系统时间不超过2小时。

可测试性

定义

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

示例

提供远程调试接口，支持远程调试。

开发期质量属性

易理解性

指设计被开发人员理解的难易程度

可重用性

指重用软件系统或某一部分的难易程度

可测试性

对软件测试以证明其满足需求规范的难易程度

可维护性

修改缺陷、增加功能、提高质量属性时，识别修改点并修改的难易程度

可扩展性

软件因适应新需求或需求变化而增加新功能的能力，也称为灵活性

可移植性

将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度

运行期质量属性

性能

安全性

可伸缩性

用户数和数据量增加时，软件系统维持高服务质量的能力。例如，通过增加服务器来提高能力

互操作性

指本软件系统与其他系统交换数据和相互调用服务的难易程度

可靠性

软件系统一定时间内持续无故障运行的能力

可用性

鲁棒性

软件系统在非正常情况（非法操作、软硬件故障等)下仍能够正常运行的能力，也称健壮性或容错性

敏感点

敏感点是一个或多个构件（和/或构件之间的关系）的特性，它能影响系统的某个质量属性。

权衡点

权衡点是影响多个质量属性的特性，是多个质量属性的敏感点

风险点

风险点是指架构设计中潜在的、存在问题的架构决策所带来的隐患。

非风险点

非风险点是指不会带来隐患，一般以“XXX要求是可以实现（或接受）的”方式表达。

架构评估方法

评估方法

基于调查问卷（检查表）的方式

基于度量的方式

基于场景的方式

质量属性场景

定义

从风险承担者的角度与系统交互的简短描述，它通常作为描述质量属性的手段

实例

6个构成部分

刺激源(Source)

某个生成该刺激的实体（人、计算机系统或者任何其他刺激器)

刺激(Stimulus)

该刺激是当刺激到达系统时需要考虑的条件

制品(Artifact)

某个制品被激励。这可能是整个系统（或系统的一部分）

环境(Environment)

该刺激在某些条件内发生。当激励发生时，系统可能处于过载、运行或者其他情况

响应(Response)

该响应是在激励到达后所采取的行动

响应度量(Measurement)

当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试

可用性质量属性场景描述

可修改性质量属性场景描述

性能质量属性场景描述

可测试性质量属性场景描述

易用性质量属性场景描述

安全性质量属性场景描述

基于场景的评估方法

软件架构分析法(SAAM)

定义

最初关注可修改性，后扩充到可移植性、可扩充性等

最早形成文档并得到广泛使用的软件架构分析方法。

架构权衡分析法ATAM

定义

由SAAM发展而来，主要针对：性能、实用性（可用性）、安全性、可修改性。

成本效益分析法(CBAM)

定义

在ATAM基础上建立的，软件的“经济”模型

质量效用树

构建与中间件技术

构件

构件的定义

软件构件是一种组装单元，它具有规范的接口规约和显式的语境依赖。软件构件可以被独立地部署并由第三方任意地组装

构件是某系统中有价值的、几乎独立的并可替换的一个部分，它在良好定义的体系结构语境内满足某清晰的功能

构件是一个独立发布的功能部分，可以通过其接口访问它的服务

构件的复用步骤

1.检索与提取构件

基于关键字的检索

特点

树形或有向无回路图结构

刻面检索法

特点

利用Faceti描述构件执行的功能、被操作的数据、构件应用的语境或任意其他特征

超文本检索法

特点

按照人类的联想思维方式任意跳转到包含相关概念或构件的文档

2.理解与评价构件

要复用构件，准确地理解构件至关重要。特别是对构件修改使用时。

为达到目的，必须要求构件的开发过程遵循公共标准。

一般构件库的文档中全面而准确地说明以下内容：

构件的功能与行为