Day28-28｜7.2.5 体系结构设计：从架构需求形成可实施、可验证的系统方案

本文对应《系统架构设计师教程（第2版）》第7章“系统架构设计基础知识”7.2.5“体系结构设计”。体系结构设计是根据架构需求、架构驱动因素、约束和风险，确定系统边界、主要元素、职责、连接方式、数据组织、部署拓扑和质量机制的过程。它不是简单选择分层、微服务或云平台，而是建立一组有依据的结构性决策，并通过多视图、原型、评审和测试证明这些决策能够支撑业务目标。

一、学习目标与考试定位

完成本节后，应能够说明体系结构设计的输入、输出和一般步骤；能够进行系统上下文、职责分解、架构风格、接口、数据、部署和安全设计；能够根据质量属性进行架构权衡；能够识别单点、循环依赖、共享数据、级联故障和过度复杂等风险；能够在案例题和论文中写出从需求到候选架构、决策、验证和演进的完整答案。

软考高级案例经常要求设计一个综合系统，题目同时包含高并发、数据一致性、可用性、安全、旧系统兼容和快速演进等目标。答题不能只写“采用微服务、分布式数据库、消息队列”，而应说明服务如何划分、数据谁负责、同步和异步如何选择、故障如何隔离、如何验证质量以及如何逐步上线。

二、体系结构设计的输入和输出

输入包括业务愿景、系统边界、功能和质量需求、架构驱动因素、法规和技术约束、既有系统、组织能力、风险和预算。输入不完整时，要记录假设并安排原型或需求澄清，不能把未知当成确定条件。

输出包括系统上下文、架构元素及职责、连接件和接口、数据视图、部署视图、安全边界、架构原则、关键决策、质量场景、风险清单、原型结论、实现规则、测试策略和演进路线。输出要让开发、测试、运维和业务能够据此工作。

三、体系结构设计的一般步骤

1. 确定上下文和边界

明确系统服务对象、外部系统、用户、数据范围、责任和不负责内容。边界决定哪些能力由本系统完成，哪些通过接口或平台获得；也决定数据所有权、故障影响和团队分工。

2. 识别架构驱动因素

从需求中提取性能、可用性、安全、可靠性、可维护性、扩展、兼容和成本等关键驱动因素，转化为质量场景和验收指标，建立优先级和风险。

3. 进行职责分解

按业务能力、领域边界、变化频率、数据所有权和团队职责划分元素，形成高内聚、低耦合和可独立验证的结构。职责分解既要避免大而全，也要避免过度拆分。

4. 选择风格和通信方式

根据场景选择分层、调用/返回、事件驱动、管道、数据中心、微服务或组合风格，确定同步 API、异步消息、事件、文件和批处理的边界。

5. 设计数据和部署

明确数据所有权、模型、事务、一致性、缓存、读模型、存储和生命周期；根据负载、故障域、安全和成本设计节点、网络、容器、数据库、消息、备份和监控。

6. 权衡、验证和决策

比较候选方案的质量、复杂度、成本、风险、团队能力和演进，记录架构决策；用原型、模型、压测、故障注入、安全评审和恢复演练验证。

四、系统上下文与边界设计

上下文视图描述系统与用户、外部系统、设备、组织和数据源之间的关系。要标明接口方向、数据、协议、调用方式、信任关系、责任和故障影响。

边界可以依据业务能力、数据所有权、质量属性、部署、团队和信任域划分。一个边界内的事务和一致性更容易保证；跨边界交互需要接口、消息、幂等、补偿和监控。边界不清会产生职责重复、共享数据库、循环调用和故障扩散。

系统上下文还要说明外部依赖不可用时的行为。支付、身份、地图和消息平台等依赖要有超时、降级、缓存、重试、替代或人工流程，不能假设外部系统永远成功。

五、职责分解与模块边界

职责分解要以业务内聚和变化隔离为主要依据。订单、库存、支付、会员和通知可能是不同业务能力，但是否拆成独立服务还要考虑事务、团队、部署、流量和运维。一个模块应尽量拥有其业务规则和数据，而不是只提供 CRUD 接口。

高内聚表示相关责任变化和协作集中，低耦合表示一个元素的变化不会大面积影响其他元素。共享领域模型、公共表和跨层调用会增加耦合；稳定接口、事件、适配器和数据服务可以隔离变化。

模块边界还要设计异常和质量责任。谁负责幂等，谁负责校验，谁负责重试，谁负责审计，谁负责数据修复，谁负责容量和告警，都应明确。只划分“用户服务”“订单服务”而不明确责任，无法形成可运行架构。

六、架构风格选择

1. 分层架构

分层按照职责组织表示、业务、数据和基础设施，依赖方向清晰，易理解和维护。风险是跨层调用、性能损耗和业务逻辑泄露；要定义层职责、允许依赖和例外。

2. 微服务或服务化

服务化按业务能力拆分，支持独立部署、扩展和团队自治。代价是网络、分布式事务、监控、测试、版本和运维复杂度。服务边界和数据所有权必须先于服务数量。

3. 事件驱动

事件驱动通过事件生产和消费降低时间耦合，适合异步处理、削峰和构建投影。要设计消息持久化、投递语义、重复、乱序、积压、死信、幂等、重放和最终一致。

4. 组合风格

真实系统常组合多种风格：边缘接入使用客户端/服务器，核心业务分层，跨模块用事件，报表使用数据管道和分析存储。组合时要明确风格边界、数据转换和一致性，不要让不同风格的假设互相冲突。

七、接口和连接件设计

接口要明确功能、数据、协议、版本、错误、超时、重试、幂等、安全、限流和监控。同步接口适合需要即时反馈和较短处理的场景，但要设置超时、熔断和降级；异步接口适合长任务、削峰和解耦，但要向调用方提供受理、状态查询和最终结果。

连接件的质量属性很重要。网络错误后如何处理，消息重复后如何处理，接口版本变化如何兼容，外部服务部分成功如何补偿，都应作为架构设计内容。不能只描述“服务 A 调用服务 B”。

API 网关、适配器、消息总线、事件总线和数据服务可以承担路由、认证、限流、转换和解耦，但它们也可能成为单点、瓶颈和集中故障源，需要冗余、扩展和监控。

八、数据架构设计

数据设计要明确权威数据源、所有权、生命周期、模型、一致性和访问。服务自治通常意味着服务拥有自己的数据，其他服务通过 API、事件和读模型获得信息；共享数据库虽然集成简单，却造成模式和事务耦合。

事务边界围绕业务不变量划分。订单和明细可以在本地事务中完成，支付渠道调用不宜占用长事务；库存预占、支付确认和订单完成通过状态机、事件、幂等和补偿协同。强一致只用于必须强一致的范围，其他查询可以接受可解释的最终一致。

缓存、搜索、报表和读模型都是派生数据，要记录权威来源、同步延迟、失败补偿、重建和对账。数据迁移、归档、备份、恢复、权限和审计要在架构阶段纳入。

九、运行视图与物理部署

运行视图描述进程、线程、服务、通信、并发和故障；物理视图描述节点、网络、容器、可用区、数据库、消息和外部设施。部署要结合负载、故障域、隔离、扩展、成本和运维。

无状态服务可以水平扩展，状态需要放入受控存储或分布式会话；数据库和消息要考虑副本、分片、日志、备份和切换；静态资源和缓存要考虑失效、回源和降级。生产部署必须包含配置、密钥、监控、日志、追踪、告警、备份和回滚。

物理设计不是把所有组件都部署成多副本。关键是识别单点和故障边界，定义故障时的业务行为和恢复顺序。更多节点会增加成本、同步和运维，需通过容量和故障演练验证。

十、安全架构设计

安全架构从身份、信任边界、资产、威胁和控制出发。设计认证、授权、租户隔离、网络分区、传输和存储加密、密钥管理、审计、脱敏、漏洞和供应链。

安全机制要与业务数据和操作匹配。权限不仅是登录，还包括资源、行列、租户、字段和操作级控制；敏感数据要控制读取、导出、日志、备份和测试复制；审计要记录主体、时间、来源、对象、操作和结果。

十一、质量属性权衡与验证

架构设计要把质量属性转化为方案和证据。性能用负载和 P95/P99 验证，可用性用故障注入和切换验证，可靠性用重复、超时和恢复验证，安全用威胁建模和测试验证，可维护性用变更周期、依赖规则和发布验证。

权衡要记录候选方案、假设、优先级、代价和残余风险。例如异步化降低时间耦合但增加延迟和一致性复杂度；缓存降低数据库压力但需要失效策略；分片提高容量但增加跨片查询和迁移成本。

十二、架构评审与演进

架构评审检查目标、边界、元素、连接、数据、部署、安全、质量和运维。评审结果要形成问题、责任人、期限和验证，不是会议结束就算通过。

架构演进要根据需求、运行反馈、故障、成本和技术变化进行。采用适配器、旁路、双读、双写、事件同步、灰度和分阶段迁移降低风险；保留架构决策、技术债务、指标和演进路线。任何例外要有期限和退出条件。

十三、案例分析：智慧物流平台的整体架构设计

某物流平台需要支持司机端、客户端、仓库端和管理端，日均运单千万级，高峰请求增长十倍；要求订单和库存不能出现严重不一致，轨迹查询要低延迟，外部地图和支付服务偶尔不可用，客户数据需要按租户隔离并可审计。平台还要逐步替换旧订单系统。

设计思路

以订单、库存、支付、运力、轨迹和租户为主要业务能力，明确数据所有权和服务边界；订单和库存核心状态在合理本地事务内维护，跨能力通过事件、状态机、幂等和补偿协同；司机和客户端通过网关接入，外部地图和支付使用适配器、超时、熔断、降级和状态查询。

轨迹数据按设备和时间设计高吞吐存储，查询通过缓存和读模型提供低延迟；报表和分析与在线交易隔离。租户通过路由、权限和数据分区实现隔离，敏感操作统一审计。部署采用无状态服务、消息集群、数据库副本、分片和跨可用区，配置、密钥、日志、指标、追踪、备份和恢复纳入平台。

旧系统替换采用绞杀者模式：先用适配层承接新接口，建立事件和数据同步，按业务或租户灰度切换，执行源目标对账和回滚；通过容量压测、故障注入、安全测试、迁移演练和恢复演练验证关键质量属性。

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

练习一

请给出一个从架构需求到体系结构方案的简要流程。

参考答案：明确业务目标和系统边界；收集功能、质量、约束、外部依赖和风险；识别架构驱动因素并写成质量场景；进行职责和数据所有权分解；选择架构风格、通信、数据和部署候选；比较质量、成本、复杂度、团队和演进；记录架构决策；通过原型、评审、压测、故障和安全测试验证；将结果落实到实现、测试、部署和演进计划。

练习二

为什么微服务架构设计必须先明确数据所有权？

参考答案：没有数据所有权，多个服务会直接写同一表或重复维护事实，模式变更、事务和一致性会跨服务传播，服务无法自治。明确所有权后，服务通过 API、事件和读模型获取数据，跨服务一致性使用幂等、状态机、补偿和对账；暂时共享要明确权限和过渡路线。

练习三

外部地图服务不可用时，物流平台应如何设计？

参考答案：设置连接和执行超时、熔断、限流和降级；缓存近期路线或采用备用地图；将非核心路径计算异步化，向用户返回受理或近似结果；记录失败并重试可恢复请求，禁止无界重试；恢复后补算和校正；监控错误率、延迟、熔断和补偿，明确人工处理和审计。

十五、论文写作素材

论文中可以这样描述体系结构设计：我从业务目标、系统上下文、质量属性、约束和风险出发识别架构驱动因素，将性能、可用性、安全、可靠性、可维护性和扩展性转化为质量场景；根据业务能力、数据所有权、变化频率和团队职责划分架构元素，明确职责、接口、数据、部署和故障边界。

我比较分层、服务化、事件驱动和组合架构，依据同步反馈、异步削峰、数据一致性、跨地域、成本和团队能力做出决策；对订单、库存和支付划分事务，对跨服务流程采用事件、幂等、状态机、补偿和对账；对外部依赖采用适配、超时、熔断、降级和状态查询；对读写和分析负载采用缓存、读模型和隔离存储。

在运行和物理视图中设计无状态服务、消息和数据库副本、分片、网络与安全边界，落实配置、密钥、日志、指标、追踪、备份、恢复和回滚。通过原型、容量压测、故障注入、安全测试、迁移对账和灾备演练验证；系统演进采用适配器、绞杀者、灰度和分阶段迁移，所有决策、风险和质量证据纳入架构治理和配置管理。

十六、今日复盘

体系结构设计是从需求和驱动因素形成整体方案的过程。先定上下文和边界，再做职责、数据、接口和部署设计；根据质量属性选择风格和连接方式；通过候选方案和权衡形成决策；用多视图、原型、评审、压测、故障和安全测试验证；最后落实到实现、发布、运维和演进。

记忆主线：

定边界、分职责、明数据、选风格、定接口、做部署；质量要量化，权衡要记录，风险要验证，架构要可演进。

下一篇进入 7.2.6 体系结构文档化，学习架构文档的内容、视图、记录方式、维护和评审要求。