Day28-27｜7.2.4 体系结构需求：把业务愿望转化为可决策、可验证的架构约束

本文对应《系统架构设计师教程（第2版）》第7章“系统架构设计基础知识”7.2.4“体系结构需求”。体系结构需求是那些会影响系统整体结构、关键质量属性、主要技术选择、数据边界、部署方式和长期演进的需求。它们可能来自业务目标、用户场景、法规政策、组织约束、质量属性、外部系统和技术风险。架构师的任务不是简单收集“系统要快、要稳、要安全”，而是把这些模糊要求转化为有优先级、有场景、有指标、有责任和有验证证据的架构输入。

一、学习目标与考试定位

完成本节后，应能够解释体系结构需求的含义、来源和特点；能够区分功能需求、质量属性需求、约束、架构驱动因素和架构风险；掌握质量属性场景的组成和写法；能够获取、分析、排序和确认架构需求；能够处理性能、可用性、安全、一致性、可维护性和扩展性之间的冲突；能够在案例题和论文中把架构需求映射到架构机制、测试和验收。

软考高级案例常用模糊需求作为题干：“系统要高性能”“要支持海量用户”“必须安全可靠”“以后要方便扩展”。考生需要指出需求不具备可验证性，并补充负载、环境、响应、阈值、故障、恢复、权限和变化等内容。答案要形成需求—架构—验证闭环。

二、什么是体系结构需求

体系结构需求是对系统整体结构和关键质量具有显著影响的需求。它可能直接描述系统结构，例如“系统必须与既有身份平台集成”，也可能通过质量目标间接驱动结构，例如“单节点故障时核心交易不能中断”。

体系结构需求具有以下特征：影响范围大，通常涉及多个模块、服务或团队；生命周期长，变更会传播到设计、代码、数据、测试和运维；需要权衡，多个目标之间可能冲突；难以仅靠单元测试验证，需要原型、性能测试、故障演练和安全评审；通常包含假设、约束和不确定性。

不是所有需求都必须提升为架构需求。一个局部页面的文案变化可能属于普通功能需求；但“所有用户操作必须可审计”会影响接口、日志、数据、权限和存储，属于架构关注点。判断标准是需求是否改变系统边界、跨模块关系、质量属性、部署、数据和长期成本。

三、体系结构需求的来源

需求来源之间可能互相矛盾。业务希望快速上线，安全要求复杂审批；用户希望低延迟，跨地域一致性要求强；管理层希望低成本，运维要求多副本和灾备。架构师要把冲突显式化，由有权限的责任人确定优先级和可接受取舍。

四、功能需求与质量属性需求

功能需求描述系统要提供的服务和行为，如创建订单、查询库存和生成报表；质量属性需求描述系统在什么条件下、以什么程度提供服务，如响应时间、可用率、恢复时间、安全控制和可维护性。

功能和质量不可完全分离。一个“支付”功能如果需要幂等、审计和恢复，架构需要相应的数据和流程；一个“导出报表”功能如果涉及百万数据和敏感字段，也会影响存储、权限、异步化和资源隔离。

质量属性要结合业务场景，不能用抽象形容词代替。常见属性包括性能、可用性、可靠性、安全性、可修改性、可扩展性、可移植性、易用性、可测试性、可观测性和合规性。对每个关键属性明确优先级、阈值和验证方法。

五、质量属性场景

质量属性场景通常包含六个要素：刺激源、刺激、环境、制品、响应和响应度量。

例如可用性场景：“当某应用实例在生产高峰突然宕机时，负载均衡器应在 30 秒内识别并将请求转移到健康实例；已提交订单不丢失，未完成请求按幂等规则处理，业务恢复时间不超过 1 分钟。”

性能场景：“在工作日高峰、每秒 5000 次查询、数据规模 2 亿条时，订单查询服务应使 95% 请求在 300 毫秒内返回，99% 请求在 1 秒内返回，错误率低于 0.1%。”

安全场景：“当未授权用户尝试读取其他租户的客户资料时，系统应拒绝请求，记录主体、来源、对象和结果，并在 1 分钟内产生告警。”

可修改性场景：“新增一种支付渠道时，已有渠道不修改，新增代码在 5 个工作日内完成开发、测试和灰度部署。”

场景必须说明测量条件和口径。平均响应时间可能掩盖尾部延迟，可用率要说明统计窗口和计划停机，恢复时间要说明从什么时刻开始计时，数据丢失要说明业务事件而不是只看数据库日志。

六、需求获取方法

1. 访谈和工作坊

访谈不同角色，获取目标、痛点、异常和限制；工作坊让业务、产品、架构、开发、测试、安全和运维共同讨论质量场景和取舍。要避免只记录显性愿望，还要追问“发生什么才算失败”“多快才够”“谁批准例外”。

2. 场景和用例分析

从端到端业务流程识别数据、状态、并发、外部依赖和故障。例如退款流程不仅包括正常退款，还要考虑支付平台超时、重复回调、部分成功、人工审核和对账。

3. 原型和实验

对无法通过讨论确认的技术约束建立时间盒原型，如消息吞吐、数据库分片、缓存命中、设备协议、加密性能和恢复时间。原型结果要写明数据、负载、环境、指标和边界。

4. 现有系统和历史数据

通过监控、日志、事故、工单、慢查询、容量、代码和配置了解现实约束。既有系统文档可能过时，必须通过实际数据和运行人员确认。

5. 逆向需求分析

对已运行系统，可以从架构、部署、指标和故障反推隐含需求。例如用户投诉高峰慢，可能隐含 P99、容量、降级和资源隔离需求；灾备演练失败，说明恢复目标未被明确。

七、需求分析与优先级

需求分析要识别影响范围、依赖、可行性、风险、成本和验证难度。架构需求可以分为必须满足、重要但可权衡、阶段性目标和未来目标；也可以按业务影响、概率、不可逆性和实现成本排序。

优先处理高影响、高风险和高不确定性的需求，尤其是性能、数据一致性、安全、灾备、外部接口和模式演进。对低风险细节可以在后续迭代中细化，但不能把关键架构决策拖到实现末期。

需求还应标注稳定性和变化频率。稳定的核心业务规则适合进入架构和数据约束；变化快的展示和渠道能力适合通过适配器、配置和插件隔离。变化点本身也是架构驱动因素。

八、架构需求之间的权衡

架构需求通常不能全部最大化。强一致可能增加延迟和降低跨地域可用性；高安全可能增加认证、加密和审计成本；高扩展性可能提高复杂度；低成本可能限制冗余和自动化。

权衡要用场景和证据。对于核心余额选择强一致，对推荐选择最终一致；对核心交易设置更高可用性，对后台报表允许降级；对敏感数据增加隔离和审计，并测量性能影响。每项取舍都记录前提、后果、残余风险和复核条件。

九、需求到架构的映射

需求确认后，要把它映射为架构元素、连接件、数据、部署和验证。可以建立如下追踪：

映射不是一对一关系，一个需求可能由多个机制共同满足，一个机制也可能支持多个需求。若找不到对应机制或验证证据，说明需求尚未真正进入架构。

十、需求确认、基线和变更

架构需求要由具有决策权的干系人确认，形成版本和基线。确认内容包括定义、指标、优先级、范围、假设、依赖、验收和责任。需求基线建立后，新增或修改需求要进行影响分析，更新架构、计划、测试、数据和风险。

需求变更不可避免，但不能靠口头通知。变更流程包括提出、登记、影响分析、方案、审批、实施、验证、文档和关闭。紧急变更可以快速处理，但必须保留记录并事后补审。

十一、案例分析：电商平台的“高并发和低成本”冲突

某电商平台提出“支持十倍增长、核心接口 P99 小于 200 毫秒、跨地域强一致、全年可用率 99.99%，同时基础设施成本不能增加”。产品只给出这四句目标，架构团队无法判断可行性。项目经理要求先按微服务和多副本实现，测试阶段再验证。

问题分析

需求缺少负载、数据规模、故障范围、统计窗口、业务优先级和成本口径；跨地域强一致、高可用、低延迟和低成本之间存在明显权衡；没有区分核心交易和非核心查询，也没有明确哪些数据可最终一致。先选技术会把冲突推到后期。

改进方案

组织业务、财务、架构、运维和安全工作坊，把目标转化为场景：核心订单、库存和支付分别定义吞吐、P99、RPO、RTO和可用率，推荐和搜索单独定义延迟与一致性；建立容量模型和成本模型，比较单地域、双活、主备、分片、缓存和异步方案；明确强一致范围，其他数据使用事件和投影；对关键技术做原型和故障演练，形成带有代价和残余风险的决策，由责任人确认目标或调整范围。

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

练习一

“系统要高可用”为什么不是合格的架构需求？应如何改写？

参考答案：没有说明故障类型、环境、制品、检测、切换、数据损失和恢复指标，无法设计和验收。可改写为：“生产高峰单个应用实例故障时，系统在 30 秒内完成流量切换，核心请求错误率不超过某阈值，已提交交易不丢失，RTO 不超过 1 分钟、RPO 不超过 5 分钟，并通过故障注入和业务恢复验收。”

练习二

如何处理“低成本”和“高可用”同时被列为最高优先级？

参考答案：两者可能存在冲突，不能同时无条件最大化。应量化可用率、故障损失、RTO/RPO、基础设施、运维和业务成本，识别核心和非核心能力；提出主备、同城多副本、跨地域、分层恢复和降级等候选，比较生命周期成本和风险，由有权限责任人确定优先级、接受取舍并记录残余风险。

练习三

一个架构需求没有对应测试或验收方法，说明什么问题？

参考答案：需求可能过于模糊、不可测量，或架构尚未形成实现机制。应补充场景、环境、响应和度量阈值，明确原型、压测、故障注入、安全测试、恢复演练或运行指标等验证方法；如果暂时无法验证，登记为风险，不应把它作为已完成需求。

十三、论文写作素材

论文中可以这样描述体系结构需求：项目启动后，我通过业务目标、用例、干系人访谈、现有系统、法规、外部接口、运行指标和历史事故识别架构需求，重点关注性能、可用性、可靠性、安全、可维护性、扩展性、数据一致性和恢复。对“高并发”“高可用”等模糊表述，我使用刺激源、刺激、环境、制品、响应和度量把它们转化为可验证质量场景。

我根据业务影响、风险、不可逆性和变化频率确定优先级，建立需求、架构决策、元素、数据、接口、测试和部署的追踪关系；对互相冲突的目标建立容量、成本和风险模型，比较候选方案并记录权衡、后果和残余风险。对新技术、跨地域、数据迁移和灾备通过时间盒原型、压测、故障注入和恢复演练验证。

确认后的架构需求形成基线，变更通过影响分析、评审和版本控制更新架构、计划、测试和风险。架构实现后通过代码规则、配置、权限、监控、质量门禁和运行指标持续验证；未能验证的需求不宣称已完成，而是明确假设、责任人、截止时间和后续行动，保证架构真正服务于业务目标。

十四、今日复盘

体系结构需求是影响系统整体结构和质量属性的关键需求，来源于业务、用户、质量、约束、外部依赖、组织、技术风险和运行反馈。需求获取后要场景化、量化、排序、权衡和确认，再映射到架构元素、连接件、数据、部署和验证。高质量架构需求必须可理解、可决策、可追踪、可实现、可验证和可演进。

记忆主线：

找来源，辨驱动；写场景，定指标；排优先，做权衡；映射架构，安排验证；形成基线，受控变更。

下一篇进入 7.2.5 体系结构设计，学习架构方案形成、分解、风格选择、视图设计、决策和评审。