Day28-24｜7.2.1 体系结构的设计方法概述：用架构驱动开发控制复杂系统

本文对应《系统架构设计师教程（第2版）》第7章“系统架构设计基础知识”7.2.1“体系结构的设计方法概述”。体系结构设计方法是把业务需求、质量属性、约束、风险和技术选择转化为系统结构的过程。它不是一套固定的画图步骤，而是一种以架构为核心、以场景和质量为驱动、以迭代和验证为手段的工程方法。系统架构师需要掌握如何识别架构驱动因素、形成候选方案、组织多视图、验证关键风险并把架构落实到开发和运行。

一、学习目标与考试定位

完成本节后，应能够说明体系结构设计方法的目标、原则和一般流程；理解架构驱动因素、场景、质量属性、约束和风险的作用；能够从需求出发形成候选架构并进行权衡；能够采用视图、模型、原型和评审描述与验证架构；能够分析“先选技术后补需求”“只画静态结构”“没有验证质量属性”等设计缺陷；能够在案例题和论文中写出完整的架构设计方法。

软考高级题目往往要求考生面对一个复杂系统提出架构设计过程，而不是直接写一个架构名称。答题要体现：需求与约束识别、质量场景、架构驱动因素、方案设计、决策权衡、原型验证、架构评审、实现约束、测试和持续演化。

二、体系结构设计方法的基本思想

架构设计的目标是用较少但关键的决策建立系统整体结构，使功能能够实现，质量属性能够达到，团队能够协作，系统能够部署、运行和演进。架构设计必须同时处理业务复杂性和技术不确定性。

架构设计不能从技术产品清单开始。正确顺序是先理解目标和约束，识别最重要的质量属性和风险，再提出候选结构和技术实现。技术名词只是方案的一部分，必须说明它解决什么问题、引入什么代价以及如何验证。

体系结构设计方法通常遵循以下原则：以需求和质量为驱动；优先处理高风险和不可逆决策；关注边界、职责和协作；采用多视图描述；通过原型、模型和测试验证；保持决策和假设可追溯；为变化预留合理空间；以最小足够复杂度满足目标。

三、架构驱动因素

架构驱动因素是对系统结构和关键决策影响最大的因素，通常来自业务目标、质量属性、约束、风险和变化点。架构师要从大量需求中识别真正决定架构的少数因素。

驱动因素应被量化为质量场景。例如“系统要高可用”可以转化为“单可用区故障时，核心下单在 60 秒内恢复，已确认订单不丢失，RPO 不超过 5 分钟”。这样才能比较候选方案和安排验证。

四、架构设计的一般流程

1. 明确目标与边界

定义系统愿景、用户、核心能力、上下文、外部系统、数据范围和不负责的内容。边界不清会造成职责重叠、数据共享和需求蔓延。

2. 收集需求和约束

识别功能、质量、法规、预算、时间、平台、团队、接口和部署约束。区分必须满足、期望满足和可协商项，记录假设和风险。

3. 识别架构驱动因素

从需求中优先选择影响结构的因素，形成质量场景、风险清单和决策问题。通常先处理性能、可用性、安全、数据一致性、外部依赖和演进等高影响问题。

4. 提出候选架构

根据驱动因素选择架构风格、分解方式、通信、数据和部署方案，形成多个可比较候选。候选方案要达到可评估的粒度，不必把每个类都设计出来。

5. 权衡和决策

比较质量、成本、进度、复杂度、风险、团队能力和供应商锁定，记录选择理由、代价、假设、替代方案和残余风险。

6. 描述和验证

用多视图、模型、接口、数据字典、原型、压测、故障注入和评审验证架构。验证结果可能促使候选方案调整。

7. 落实与演进

将架构决策转化为开发规则、接口契约、测试计划、部署清单、质量门禁和风险任务；运行反馈进入架构复盘和演进路线。

五、场景驱动设计

场景是描述系统在某种刺激和环境下应如何响应的具体问题。场景可以来自用户用例、故障、峰值、攻击、数据迁移、运维和变化。

一个完整质量场景通常包括刺激源、刺激、环境、制品、响应和响应度量。例如：在大促峰值下，外部支付平台响应变慢，订单服务应在 2 秒内返回受理状态，不能重复创建订单，并在恢复后完成支付状态确认。这个场景同时驱动超时、幂等、状态机、消息、监控和补偿设计。

场景驱动方法可以帮助架构师避免抽象口号。对每个关键场景，要识别参与元素、数据流、失败点、质量目标和验证方法。场景还可以作为架构评审和测试设计的共同输入。

六、候选架构和权衡

候选架构不是简单列出三个产品，而是列出不同的结构和行为方案。例如在线交易可以选择单体关系数据库、模块化单体加读副本、服务化加事件或分布式事务；每个方案都要说明边界、通信、数据、一致性、部署和运维。

权衡可以从以下方面进行：是否满足核心质量场景；建设和运维成本；技术成熟度和团队经验；对既有系统和外部接口的影响；数据迁移和回滚难度；供应商锁定；未来变化和扩展；实现和验证时间。

不要追求“所有质量属性都最好”。架构的价值在于显式说明取舍。例如同步调用简单、延迟低，但依赖耦合强；异步消息削峰和解耦较好，但引入延迟和最终一致；强一致事务简化业务，但可能降低跨地域可用性。决策记录应让干系人理解代价。

七、多视图和模型

不同干系人需要不同的架构表达。上下文视图说明系统与外部参与者和系统的关系；逻辑视图说明主要职责和业务结构；开发视图说明模块、组件和依赖；运行视图说明进程、线程、通信和并发；物理视图说明节点、网络、容器和部署；数据视图说明数据流、所有权和存储；安全视图说明信任边界、身份、权限和审计。

视图之间必须一致。例如逻辑视图中的订单服务要能映射到开发模块、运行进程、物理节点、数据存储和安全边界；如果图中服务自治，数据视图却显示多个服务直接写同一表，应在评审中解决矛盾。

模型应有目的和范围，不要为了“完整”画出无法维护的巨型图。文字、表格、接口契约、状态机、数据字典和 ADR 都是架构描述的一部分。

八、原型、实验和架构验证

原型用于验证高风险假设，而不是展示界面。性能原型验证吞吐、延迟、容量和资源；集成原型验证协议、认证、错误和依赖；数据原型验证迁移、查询和一致性；恢复原型验证备份、切换和 RTO/RPO；安全原型验证权限、加密和隔离。

原型要有问题、假设、范围、数据、负载、指标、时间盒和结论。实验结果应记录边界条件和未解决风险，不能把在小数据和单机环境中“跑通”当成生产可行性证明。

架构验证还包括场景走查、代码骨架、契约测试、容量模型、故障注入、威胁建模和架构规则检查。验证应覆盖正常和异常路径，尤其关注超时、重复、乱序、部分失败、扩容和回滚。

九、架构评审与治理

架构评审由具备相关知识的干系人检查目标、结构、质量、风险、实现和运维。评审前准备材料、检查表和场景；评审中记录问题、严重性、责任人和期限；评审后跟踪关闭和复核。

架构治理包括原则、标准、参考架构、评审、例外、度量和决策管理。治理应风险分级，低风险采用自动规则和模板，高风险采用人工评审；例外必须有理由、期限、责任人和退出条件。治理的目标是控制系统性风险，不是增加审批层次。

十、架构设计与敏捷迭代

敏捷项目不等于没有架构。可以采用“刚好足够”的前置架构，先处理高风险驱动因素，再在迭代中逐步细化；用架构跑道、技术故事、探针、Spike、持续集成和质量门禁保证演进。

架构工作要进入产品待办和迭代计划，包括原型、接口、迁移、自动化、性能、安全和技术债务。每个增量都应保持可运行和可验证，避免后期集中集成。架构决策可以演进，但变更要有记录和影响分析。

十一、案例分析：先定中间件后发现业务不适配

某物流企业在项目启动时决定采用微服务、事件总线和分布式数据库，随后才开始收集需求。上线前发现运单状态必须强一致，但事件消费存在延迟；部分查询需要跨多个分片聚合；团队没有分布式运维经验；旧系统接口还要求同步返回完整结果。项目组只增加消费者和节点，问题仍未解决。

问题分析

架构从技术名词出发，缺少架构驱动因素和场景；没有识别强一致状态、同步旧接口、跨片查询和团队能力约束；原型、容量和故障验证缺失；消息、分布式数据库和微服务被当成万能方案。

改进方案

重新梳理运单状态、轨迹事件、查询和旧接口的业务边界，区分必须强一致的当前状态与可异步传播的历史事件；核心状态可以在合适事务边界内维护，事件用于通知和构建查询投影；为旧接口增加同步适配层和超时语义；重新评估分片键和查询模型，必要时采用关系存储或专用读模型；通过时间盒原型验证延迟、容量、跨片查询和恢复，并根据团队能力降低不必要的技术复杂度。

十二、综合知识练习与详细答案

练习一

架构设计为什么要先识别架构驱动因素，而不是先选技术？

参考答案：架构驱动因素决定系统边界、通信、数据、部署和质量目标，先选技术容易把产品能力误当成业务需求，造成不适配、锁定和返工。识别驱动因素后才能形成多个候选方案，比较性能、可用性、安全、成本、风险和团队能力，再选择技术实现并验证。

练习二

原型已经证明单机吞吐达标，能否证明分布式生产架构可行？

参考答案：不能。单机实验无法证明分片、复制、网络延迟、数据倾斜、故障切换、跨节点事务、扩容、恢复和运维可行。应在代表性数据、并发、节点、网络和故障条件下验证关键场景，记录适用边界、指标和残余风险。

练习三

多视图中的逻辑服务图和数据图不一致，应该如何处理？

参考答案：视图不一致说明架构描述或设计本身存在问题。应追踪逻辑元素到开发、运行、物理、数据和安全元素，确认数据所有权、读写权限、接口和故障边界；若逻辑上服务自治而数据图显示共享写表，应调整结构或明确受控共享方案；更新视图、决策、测试和治理规则，保证架构描述可执行。

十三、论文写作素材

论文中可以这样描述体系结构设计方法：我先从业务目标、系统边界、干系人、功能和约束中识别架构驱动因素，将性能、可用性、安全、可靠性和可维护性转化为质量场景，建立风险清单和需求追踪。针对高影响决策形成多个候选架构，比较职责、接口、数据、部署、成本、团队能力和演进代价。

我采用上下文、逻辑、开发、运行、物理、数据和安全视图描述架构，记录元素、连接件、约束、假设和决策；对新技术、容量、外部接口、数据迁移和灾备使用时间盒原型、容量模型、契约测试、故障注入和恢复演练验证。评审中按风险分级检查质量场景、边界、数据一致性、安全和运维，问题有责任人、期限和复核。

架构决策落实到开发规则、接口契约、数据库模型、测试、流水线、部署、监控和回滚；敏捷迭代中保留架构跑道和技术任务，根据运行反馈调整模型和风险。所有变化进入架构决策、配置和变更管理，保证设计不是纸面方案，而是可实施、可验证和可演进的工程体系。

十四、今日复盘

体系结构设计方法以需求和质量为驱动，先识别架构驱动因素和风险，再形成候选方案并进行权衡；通过多视图、场景、原型、模型和评审描述和验证；最后把架构落实到开发、测试、部署、运行和演进。技术选择只是实现手段，不能替代边界、数据、质量和故障设计。

记忆主线：

目标与边界 → 驱动因素与场景 → 候选架构 → 权衡决策 → 多视图描述 → 原型评审验证 → 实施治理与持续演进。

下一篇进入 7.2.2 概念与术语，学习体系结构、架构元素、连接件、配置、视图、模型、模式和架构风格等基本术语。