软件架构设计学习-基本概念

软件架构定义

软件架构的定义主要分为两大流派，即组成派与决策派，两派从不同视角对软件架构进行了阐释，具体内容如下：

一、组成派​

核心定义​

软件系统的架构，是将系统描述为计算组件以及组件之间的交互，简言之，架构 = 组件 + 交互。​

主要特点​

• 描述对象聚焦软件本身：关注架构实践中的客体 ------ 软件，以软件为核心描述对象，围绕软件自身的构成展开定义。
• 明确软件组成逻辑：指出软件由承担不同计算任务的组件构成，这些组件并非独立存在，而是通过相互交互，共同完成更高层次的计算任务。

软件架构关注分割与交互

如图所示，以 MVC 架构为例:

分割：明确拆分出独立组件

MVC 架构将软件系统分割为 3 个功能独立的组件：

• View（视图）：负责展示界面

• Model（模型）：负责数据存储与业务逻辑

• Controller（控制器）：负责协调视图与模型的交互

交互：组件间的协作逻辑

各组件通过明确的交互行为完成系统功能：

• View → Controller：视图 "创建" 控制器，触发交互的起点

• Controller → Model：控制器 "调用服务"，向模型请求数据或操作

• Model → View：模型通过 "通知" 同步数据变化给视图

• View → Model：视图可直接 "读取" 模型中的数据

二、决策派​

核心定义

该流派的核心定义源于 RUP（Rational Unified Process，统一过程），尽管 RUP 给出的架构定义较为冗长，但其核心思想明确，即软件架构是在一些重要方面所做出的决策的集合。​

架构决策涵盖内容​

软件架构包含的重要决策涉及以下多个维度：​

• 基础组织决策：软件系统的整体组织方式。​

• 元素选择决策：对组成系统的结构元素、元素之间的接口，以及元素相互协作时所体现的行为的选择。​

• 整体组合决策：如何将这些结构元素进行组合，使其逐步合成为更大的子系统。​

• 风格指导决策：用于指导系统组织的架构风格，具体包括结构元素、元素接口、元素协作方式及元素组合方式等方面的指导原则。​

• 非功能权衡决策：除软件本身的结构和行为外，还涉及软件的使用、功能、性能、弹性、重用、可理解性、经济和技术的限制及权衡，以及美学等非功能需求相关的决策。​

主要特点​

• 描述对象聚焦人：关注架构实践中的主体 ------ 人，以人的决策为核心描述对象，强调决策在架构定义中的关键作用。​

• 归纳架构决策类型：清晰指出架构决策并非单一类型，既包括关于软件系统组织、结构元素、子系统、架构风格等与软件本身相关的决策，也涵盖了与软件非功能需求相关的各类决策，全面覆盖架构设计中的关键决策维度。

软件架构是一系列有层次的决策

切分类决策

架构设计是分层级的切分决策过程，从宏观到微观逐步拆解：

• 顶层决策：先对 "系统" 做最外层切分，拆分为 "client（客户端）" 和 "server（服务端）"

• 中层决策：对 "server" 进一步切分，拆分为 "API 层""引擎层""SPI 及服务扩展"

• 底层决策：对中层模块（如 "引擎层"）继续切分，拆解为更细粒度的 "模块"，甚至持续拆分到更小单元

切分类决策的核心：每层决策服务于整体架构

每一层的切分决策都不是孤立的，而是围绕架构目标逐层推进：

• 上层切分（如系统→client/server）为下层决策定调，明确大方向

• 下层切分（如 server→API 层 / 引擎层）承接上层逻辑，细化功能边界

• 所有切分决策共同构成 "从粗到细、层次清晰" 的架构拆分体系

​技术选型类决策

技术选型类决策是分层级的递进过程，从核心架构到具体技术逐步细化：

• 顶层决策：先确定核心架构方向（如选择 "B/S 架构"），这是技术选型的基础框架

• 中层决策：基于 B/S 架构，做编程语言层面的选型决策（如 "弃用 PHP""选用 JSP""不用 ASP"）

• 底层决策：在确定 JSP 后，进一步做配套技术的选型（如 "Framework 选择""开发工具选择"）

技术选型类决策的核心：上层决策指导下层选择

每一层的技术决策都依赖上层的架构方向：

• 顶层架构（B/S）限定了技术选型的范围（需适配浏览器 / 服务器模式）

• 中层语言选型（JSP）决定了底层框架、工具的适配方向

• 所有决策围绕 "B/S 架构" 的核心目标，形成逻辑连贯的技术栈体系

三、两流派核心差异总结

|----------|---------------------------|----------------------------|
| 对比维度 | 组成派 | 决策派 |
| 核心定义 | 架构 = 组件 + 交互 | 架构 = 一组重要决策 |
| 核心描述对象 | 客体（软件本身） | 主体（人的决策） |
| 关注重点 | 软件的组成与组件间交互逻辑 | 架构决策的内容、类型及覆盖范围 |
| 核心思想落地方式 | 通过组件分割实现功能解耦，通过组件交互实现功能整合 | 通过分层决策明确设计优先级，保障架构逻辑连贯、可落地 |

概念架构设计

概念架构的重要性

• 大型系统架构成败关键：概念架构是大型系统架构设计的核心环节，其设计质量直接关系到大型系统架构的成败，而小系统与大系统架构设计的差异，根源在于概念架构的不同。

  • ​两者架构设计走向的根本差异，源于 "确定关键需求" 这一环节。关键需求的不同，导致架构所支撑的核心目标存在差异，进而使概念架构的设计方向、核心选择大不相同，最终让小系统与大系统的架构设计路径彻底分化。

• 直指系统目标的核心设计：概念架构聚焦系统目标，包含支撑目标实现的设计思想与重大选择，是架构设计中体现技术方向与核心价值的关键部分。​

• 多场景展示价值：概念架构广泛应用于《方案建议书》《技术白皮书》、市场彩页等材料中，用于说明产品、项目或方案的技术优势，因此也被称为 "市场架构"。

概念架构的核心设计任务："1 个决定、4 个选型"

设计步骤：

1. 选择架构风格，划分顶级子系统：这两项设计任务是相互影响、相辅相成的。架构风格的选择会限制顶级子系统的划分逻辑，而顶级子系统的划分需求也会反向影响架构风格的适配性，需同步考量、协同确定。

2. 开发技术选型、集成技术选型、二次开发技术选型：这三项任务紧密相关、同时进行。开发技术的选择会影响集成与二次开发技术的兼容性，后两类选型也需基于开发技术框架展开，且需根据实际需求判断是否需要集成支持或二次开发支持。

软件架构决策过程

软件架构的本质是 "一系列有层次的决策"，每一项决策都直接影响系统的质量属性与业务适配性。从模糊的需求概念到清晰的系统架构，整个过程遵循 "黑盒认知 --- 顶层拆解 --- 精细解构" 的递进逻辑，既需要锚定业务核心，又要平衡技术权衡。以下从三个核心阶段，解析架构决策的完整路径。

1. 理解需求：黑盒阶段的决策锚点确立

在系统未被拆分前，它如同一个 "功能黑盒"------ 仅明确对外输出的价值，却未知内部构造。这一阶段的决策核心不是 "如何拆分"，而是 "为何拆分"，需通过需求解析为后续决策埋下锚点。​

需求分层与优先级排序​

架构决策的起点是区分 "关键需求" 与 "次要需求"，这也是小系统与大系统架构区分的核心。实践中需完成两类需求的梳理：​

• 功能性需求：通过用例图、业务流程图明确系统 "能做什么"，例如电商系统的 "订单创建""支付对接" 等核心流程；​

• 非功能性需求：界定系统的质量边界，如金融系统的 "交易响应延迟＜200ms""数据一致性达 99.999%"，或是互联网系统的 "支持百万级并发"。​

界定系统边界与约束条件​

黑盒阶段需明确 "系统与外部世界的交互规则"，这是后续拆分决策的前提：​

• 通过上下文图划定系统边界，例如明确电商系统需对接的第三方服务（支付、物流、短信）；​

• 梳理刚性约束，包括技术栈限制（如必须兼容现有 Java 体系）、成本预算（云服务器资源上限）、合规要求（金融系统需满足等保三级）。​

这些约束如同决策的 "框架护栏"，直接排除不符合条件的架构方向，减少后续决策的试错成本。

2.首轮决策：顶层切分的架构骨架搭建

当需求锚点确立后，决策进入 "破盒" 阶段 ------ 通过高层切分搭建架构骨架。这一阶段的决策具有 "战略性"，决定系统的整体形态与扩展方向。​

架构风格选型：决定拆分的底层逻辑​

架构风格是首轮决策的核心，它直接定义了系统的组织方式与组件交互模式。常见选型需结合需求特性权衡：​

• 若需快速迭代且业务边界清晰，可选择微服务架构（如 Netflix 将单体拆分为用户、内容等独立服务）；​

• 若强调层级清晰与团队分工，分层架构更适配（如经典三层架构：表现层、业务逻辑层、数据访问层）；​

• 若需处理实时数据流，事件驱动架构（EDA）是优选（如零售企业通过事件总线实现库存与订单的实时同步）。​

选型过程中需直面权衡：例如微服务虽提升扩展性，但会增加分布式事务复杂性；事件驱动架构虽保障响应速度，却可能牺牲数据强一致性。某零售企业为实现实时数据处理，最终选择 EDA 架构，以 "最终一致性" 换取高响应性，正是基于业务优先级的理性决策。​

顶级子系统划分：落实风格的首次拆分​

架构风格确定后，需同步完成顶级子系统的划分，两者相互影响、相辅相成。以 B/S 架构的电商系统为例，首轮切分通常形成三类核心子系统：​

• 前端子系统：负责用户交互，含 PC 端、移动端适配模块；​

• 后端服务子系统：承载核心业务逻辑，按领域拆分为商品、订单、用户三大模块；​

• 数据存储子系统：管理结构化数据（MySQL）与非结构化数据（对象存储）。​

划分需遵循 "高内聚、低耦合" 原则：同一子系统内的功能需紧密关联（如订单模块包含创建、支付、取消等流程），子系统间通过明确接口交互（如订单服务调用支付服务的 API），避免跨子系统的直接依赖。

3. 持续决策：精细解构的模块与技术落地

首轮决策搭建了 "骨架"，而第 3 至 n 步的持续决策则为其填充 "血肉"------ 将子系统拆分为更小单元，并明确技术实现细节。这一阶段的决策具有 "战术性"，需兼顾复用性、可维护性与落地可行性。​

子系统的多层级拆分​

拆分过程遵循 "从粗到细" 的层次逻辑，每一步都需呼应顶层决策：​

• 模块级拆分：将子系统拆分为功能模块，例如 "订单子系统" 可拆分为订单创建、订单查询、订单履约模块，遵循单一职责原则；​

• 组件级拆分：模块内进一步拆分为可复用组件，如订单创建模块包含参数校验、规则引擎、数据持久化组件；​

• 接口级定义：明确组件间的交互契约，如校验组件输出 "合规 / 不合规" 信号，规则引擎接收后执行对应的业务逻辑。​

拆分粒度需动态平衡：过粗会丧失模块化优势，过细则增加通信成本。某银行曾因将核心交易系统拆分为数十个细粒度模块，导致跨模块调用延迟增加 30%，最终通过合并关联模块才恢复性能。​

技术选型的协同决策​

模块拆分与技术选型需同步推进，三类核心选型直接影响落地效果：​

• 开发技术选型：匹配模块功能特性，如高频读写的订单模块选择 Redis 缓存，复杂计算的风控模块采用 Java 并发框架；​

• 集成技术选型：解决跨系统交互问题，如子系统间同步通信用 gRPC，异步通信用 Kafka 消息队列；​

• 二次开发技术选型：预留扩展接口，如通过 SPI 机制支持支付方式的灵活新增（无需修改核心代码）。​

选型需避免 "技术炫技"，例如小型系统若强行采用微服务架构，会徒增运维复杂度。某金融公司在系统现代化改造中，选择 "渐进式集成" 策略 ------ 新增功能用微服务，旧系统逐步迁移，既降低风险又兼容现有技术栈，正是协同决策的典型实践。​

决策的验证与迭代调整​

架构决策不是静态结果，而是动态过程。每一步拆分后需通过两类方式验证：​

• 原型验证：用轻量级原型测试关键模块的交互逻辑，如验证订单与支付模块的对接流程；​

• 评审评估：从性能、安全、成本等维度打分，例如微服务拆分后需评估服务注册中心的承载能力。​

当需求变化或技术演进时，需回溯决策链路：若业务新增 "跨境支付" 功能，可基于现有支付模块扩展接口，而非重构整个子系统，体现架构的弹性适配能力。

从需求到架构整个过程中的关键任务项

阶段 1：高层需求分析（宏观需求定位）

聚焦需求的顶层框架，完成 3 项核心任务：

1. 明确系统目标：确定系统要实现的核心价值方向

2. 划定需求范围：界定系统覆盖的功能与业务边界

3. 梳理Feature（特性）+ 上下文图：明确系统核心功能点，以及系统与外部的交互关系

阶段 2：需求分析（需求细化拆解）

对高层需求做深度拆分，关键任务分为 3 类：

1. 梳理流程：明确业务操作的流转逻辑

2. 定义功能（用例）：拆解具体的用户交互场景与功能模块

3. 明确非功能需求 ：确定性能、安全性、可扩展性等质量要求最终提炼出关键需求，作为架构设计的直接输入

阶段 3：概念架构设计（架构框架搭建）

基于关键需求构建架构的顶层框架，完成 3 项核心任务：

1. 选择架构风格：确定系统的整体架构模式（如 MVC、微服务等）

2. 划分顶级子系统构成：拆分系统的大模块边界（如前端、后端等）

3. 完成3 大选型：确定开发、二次开发、集成相关的技术 / 方案方向

阶段 4：细化架构设计（子系统深度设计）

对每个子系统做精细化架构设计，关键任务是：针对拆分出的前端、后端、API、插件 等子系统，分别用5 视图法（从逻辑、物理等多维度）完成每个子系统的详细架构设计。

整个过程是从 "宏观需求" 到 "具体架构" 的逐层细化链路，每阶段任务都为下阶段提供明确输入，保障需求与架构的精准匹配。

软件架构的多维度设计

软件架构作为 "系统最重要设计决策的集合"，绝非单一维度的技术堆砌。尤其是面对大型系统的复杂性，仅从技术层面设计架构，往往会导致架构与业务目标脱节、不同角色认知偏差等问题。而多维度设计 ------ 通过 "多视角" 满足不同角色需求，以 "多视图" 拆解系统复杂性 ------ 正是破解这一困境的核心方法论，让架构既能对齐业务价值，又能落地技术实践。

多视角设计：对齐不同角色的核心诉求

架构的价值不仅在于技术可行性，更在于能否为项目全链路角色提供支撑。架构师需跳出 "纯技术思维"，从 "上游""下游""周边" 多视角出发，确保架构决策覆盖所有关键角色的核心诉求，这是架构获得认可与落地的前提。​

（一）对 "上游" 角色：锚定业务与用户核心目标​

"上游" 角色直接决定架构的价值方向，包括客户与终端用户，架构师需优先满足其诉求：​

• 面向客户：保障业务目标与约束落地​

客户关注系统能否实现商业价值、符合成本与合规要求。例如，电商平台客户可能要求 "618 大促期间支持千万级并发""成本控制在现有预算 120% 以内"，金融客户则强调 "满足等保四级合规""交易数据零丢失"。架构师需将这些约束转化为技术决策，如通过微服务 + 云原生架构支撑高并发，采用异地多活方案保障数据安全，确保架构与客户的业务目标同频。​

• 面向用户：满足功能与质量属性需求​

终端用户关注 "系统好不好用""稳不稳定"，核心诉求集中在功能完整性与运行期质量属性。例如，社交软件用户需要 "实时消息推送""图片快速加载"，办公系统用户则重视 "操作流程简洁""数据查询高效"。架构师需将这些需求映射为技术方案：用 WebSocket 实现消息实时推送，通过 CDN 加速图片加载，采用索引优化提升查询效率，让架构直接服务于用户体验。​

（二）对 "下游" 角色：降低开发落地难度​

"下游" 角色即负责架构落地的开发人员，架构师需为其提供清晰、可执行的设计方案，减少开发过程中的认知与协作成本：​

• 提供明确的模块边界与接口定义：通过文档明确各模块的功能范围、输入输出参数，避免开发时出现 "边界模糊" 导致的重复开发或功能遗漏。例如，订单模块与支付模块的接口需明确 "订单状态同步规则""支付结果回调格式"，让前后端开发人员无需反复沟通即可并行开发。​

• 适配开发团队的技术能力：架构设计不能脱离团队实际，若团队擅长 Java 技术栈，强行采用 Go 语言构建核心服务会增加学习与调试成本；若团队缺乏分布式架构经验，过度复杂的微服务拆分可能导致服务治理混乱。架构师需在 "技术先进性" 与 "团队适配性" 间平衡，例如选择 "Spring Cloud" 生态而非自研分布式框架，降低开发人员的上手难度。​

（三）对 "周边" 角色：支撑管理与协作效率​

"周边" 角色包括项目管理人员、测试人员等，架构师需为其提供管理与协作的基础，保障项目有序推进：​

• 为管理人员提供分工依据：清晰的架构拆分可直接对应团队分工，例如前端子系统对应前端团队，后端订单模块对应订单开发组，让管理人员能快速划分任务、评估工作量，避免 "职责交叉" 或 "无人负责" 的情况。同时，架构文档中的 "模块依赖关系" 可帮助管理人员识别项目风险点，如 "支付模块依赖第三方接口" 需提前协调对接时间。​

• 为测试人员提供测试重点：架构中的 "非功能需求设计"（如性能、安全性方案）可指导测试方向，例如针对 "高并发设计" 开展压力测试，针对 "数据加密方案" 进行安全渗透测试，让测试工作更具针对性，避免遗漏关键质量点。

多视图设计：以 "分而治之" 拆解大型系统复杂性​

对于大型系统，"一次性设计所有细节" 远超人类认知极限。多视图设计通过 "分而治之" 的思路，从不同维度拆分系统，每个视图聚焦一个特定方面，既降低了设计难度，又便于不同角色理解与使用 ------ 这正是 Philippe Kruchten 在《Rational 统一过程引论》中强调的 "架构视图是简化描述、聚焦特定方面" 的核心价值。​

（一）多视图设计的核心逻辑：聚焦特定维度，省略无关细节​

每个架构视图都有明确的 "关注焦点" 与 "省略内容"，通过 "取舍" 实现对系统某一方面的深度刻画：​

• 不追求 "全维度覆盖"：例如 "逻辑视图" 聚焦 "系统由哪些功能模块组成、模块间如何交互"，无需关注 "模块部署在哪些服务器上"；而 "物理视图" 则专注 "服务器拓扑结构、模块与服务器的映射关系"，无需描述 "模块内部的业务逻辑"。这种 "聚焦" 让每个视图的信息更精炼，避免因 "信息过载" 导致理解困难。​

• 服务于特定实践目标：不同视图对应不同的使用场景，例如 "开发视图" 用于指导开发人员搭建项目结构、选择开发工具，"部署视图" 用于运维人员规划服务器资源、配置部署流程。某大型金融系统曾因缺乏 "部署视图"，导致运维人员不清楚 "核心交易模块需部署在高性能服务器"，误将其部署在普通机器上，引发交易延迟问题 ------ 这正是忽视视图针对性的典型教训。​

（二）常见架构视图的实践应用​

在实际项目中，架构师通常会选择核心视图组合，覆盖设计、开发、部署全流程，以下为四类高频视图的应用场景：​

用例视图：连接需求与架构的桥梁​

• 核心内容：以用例图、场景描述等形式，展示系统的功能范围、用户与系统的交互方式，以及用例与功能模块的对应关系。例如，电商系统的 "用户下单" 用例，需明确 "用户选择商品→加入购物车→提交订单→支付" 的完整场景，同时标注该用例由 "商品模块""购物车模块""订单模块""支付模块" 协同支撑。​

• 使用角色：产品经理、客户、开发人员、测试人员。​

• 实践价值：对客户与产品经理而言，可通过用例视图确认 "系统功能是否覆盖业务场景"，避免需求遗漏（如电商系统需补充 "订单取消""退款" 等用例，确保业务闭环）；对开发人员而言，能清晰知晓 "每个模块需支撑哪些用例"，避免开发偏离需求；对测试人员而言，可依据用例场景设计测试用例（如模拟 "用户下单时库存不足" 的异常场景），确保测试覆盖核心业务流程。某教育平台曾因缺失 "学生退课" 用例视图，导致开发阶段未设计退课相关功能，上线后紧急返工，正是用例视图缺失的典型问题。

逻辑视图：定义功能模块与交互​

• 核心内容：系统的功能模块划分、模块间的接口与依赖关系、业务逻辑流程。​

• 使用角色：开发人员、产品经理。​

• 实践价值：产品经理可通过逻辑视图确认 "功能是否完整覆盖需求"，开发人员可依据视图开展模块开发与接口联调。例如，电商系统的逻辑视图会明确 "商品模块""订单模块""支付模块" 的功能边界，以及 "下单时订单模块调用商品库存接口" 的交互逻辑。​

物理视图：规划硬件与部署方案​

• 核心内容：服务器拓扑结构（如 Web 服务器、应用服务器、数据库服务器的数量与配置）、模块与服务器的映射关系、网络架构（如防火墙配置、负载均衡策略）。​

• 使用角色：运维人员、项目经理。​

• 实践价值：运维人员可根据物理视图采购服务器、配置部署脚本，例如 "核心交易模块部署在 2 台 8 核 16G 应用服务器上，通过 Nginx 负载均衡"；项目经理可依据视图评估硬件成本，避免 "资源浪费" 或 "资源不足"。​

开发视图：指导开发环境与代码组织​

• 核心内容：项目目录结构、技术栈选型（如编程语言、框架、中间件）、代码规范、版本控制策略。​

• 使用角色：开发人员、技术负责人。​

• 实践价值：新入职开发人员可通过开发视图快速搭建本地环境，遵循统一的目录结构（如 "src/main/java" 存放业务代码，"src/test" 存放测试代码），避免因 "代码风格混乱" 导致的协作问题。​

运行视图：保障系统运行期质量​

• 核心内容：性能优化方案（如缓存策略、异步处理）、容错机制（如服务降级、熔断）、监控告警配置（如关键指标监控、异常告警阈值）。​

• 使用角色：开发人员、运维人员。​

• 实践价值：开发人员可依据视图实现 "Redis 缓存商品信息""MQ 异步处理订单日志"，运维人员可配置 "CPU 使用率超过 80% 告警""接口响应延迟超过 500ms 告警"，共同保障系统稳定运行。

多视角与多视图的协同：构建完整的架构解决方案​

多视角与多视图并非独立存在，而是相互协同、相互支撑的关系 ------ 多视角决定 "架构要为谁设计、满足什么需求"，多视图则提供 "如何设计、如何落地" 的具体方法，两者结合才能构建出 "有价值、可落地" 的架构。​

（一）以多视角指导多视图设计方向​

多视图的选择与内容需围绕多视角的诉求展开：若客户关注 "系统可用性"，则需在 "运行视图" 中重点设计 "异地多活""故障自动恢复" 方案；若开发团队技术能力有限，则 "开发视图" 需选择简单易用的技术栈，避免复杂框架；若管理人员需要清晰分工，则 "逻辑视图" 的模块拆分需与团队结构匹配。例如，某政务系统中，客户要求 "数据安全合规"，因此 "物理视图" 需规划 "数据加密服务器""审计日志服务器"，"运行视图" 需设计 "敏感数据脱敏方案"，确保视图设计直接响应视角诉求。​

（二）以多视图支撑多视角需求落地​

多视图是多视角诉求的 "技术载体"，只有通过具体视图，抽象的需求才能转化为可执行的方案：用户 "实时消息" 需求，需通过 "逻辑视图" 定义 "消息模块" 与 "推送接口"，"运行视图" 设计 "WebSocket 连接池" 来落地；管理人员 "分工管理" 需求，需通过 "逻辑视图" 的模块拆分对应团队任务，"开发视图" 的目录结构明确开发范围来支撑。没有视图的落地，视角诉求只能停留在 "口号层面"，无法真正转化为系统能力。

参考文献

《软件架构设计：程序员向架构师转型必备》