简介系统架构设计是决定软件系统长期演化的核心活动其本质是在性能、可用性、可修改性等质量属性之间做出权衡。架构风格如分层、事件驱动、微服务提供了约束性拓扑而质量属性场景将抽象需求转化为可度量的指标为架构决策提供依据。ATAM等评估方法通过效用树识别风险与权衡点帮助团队在早期发现架构隐患。在工程实践中缓存一致性、消息队列选型、分布式事务如Saga和微服务拆分是架构师高频面对的技术场景直接关系到系统的高可用与扩展性。本文基于2021年系统架构设计师考试知识点梳理从理论到实战的完整知识框架为工程师建立可复用的架构决策骨架提供参考。1. 2021 系统架构设计师知识点集锦不是背题是建立架构决策的骨架系统架构设计师考试最容易被低估的地方是它把“架构”从一个口头名词拆成了一组可训练的技能单元。2021 年的知识点集锦类文档之所以还值得翻是因为考试大纲里那些考点——架构风格、质量属性、架构评估、中间件、微服务、分布式事务——恰恰是日常评审别人设计时最容易被追问的几块。对五年以上经验的工程师来说备考的真正价值不是拿证而是把零散的架构经验压成一套能复用的决策框架拿到需求先识别质量属性再选风格再落到视图与评估。这篇博文按“理论—选型—实现—评估—应试”的顺序把该掌握的知识点串成一条线并给出可以直接抄用的表格、命令和检查清单。2. 架构设计的理论地基风格、质量属性与视图2.1 架构风格是约束不是模板系统架构设计师考点里的“架构风格”核心在于理解每一种风格都锁定了某种拓扑关系与通信方式从而提前决定了系统的可演化边界。常见分类包括数据流风格批处理、管道-过滤器。过滤器之间只通过标准数据接口连接适合数据转换链清晰的场景但全局状态管理弱。调用返回风格主程序-子程序、面向对象、层次结构。层次结构约束依赖方向适合业务稳定、层级清晰的企业应用。独立构件风格进程通信、事件驱动。事件驱动让生产者与消费者解耦但调试时调用链不直观事务回滚也难做。虚拟机风格解释器、规则引擎。把业务规则外置适合频繁变更多变的场景代价是性能损耗和规则调试成本。仓库风格数据库中心、黑板。黑板适合解决无法提前确定求解路径的问题比如语音识别与知识推理。选型时常见的错误是“用事件驱动解决所有异步需求”。事件驱动只是解耦了时间仍然需要约定事件格式、幂等键、重试策略和顺序保障。面向对象适合模块内设计但跨进程、跨团队的边界如果只靠对象接口会因为序列化、版本兼容、失败模式不同而失控。所以架构风格选型要看的是约束的匹配度不是风格的先进程度。2.2 质量属性要写成可度量的场景考纲里反复出现可用性、性能、安全性、可修改性、易用性这几个质量属性。死记定义没有用真正能在案例题中得分的是把质量属性写成“六要素场景”刺激源、刺激、环境、工件、响应、响应度量。例如“可用性”如果只写“系统要高可用”架构评审时谁都无法判断是否符合要求。改成可度量的版本刺激源用户业务请求刺激某个实例发生断电环境正常负载系统运行中工件订单服务进程响应请求在 30 秒内由剩余节点接管返回成功或明确失败无挂起响应度量月度可用性≥99.95%单次故障恢复时间≤30 秒这样写出来之后才能判断是否需要引入负载均衡、健康检查、自动故障转移以及分布式会话。考场上的案例题和实际评审一样都靠这种“可验证的指标”拉开分差。2.3 视图是架构的投影不是架构本身2021 年知识点集锦对视图的考查通常落在 41 视图模型以及基于 ADL 的架构描述。逻辑视图面向最终用户的功能需求进程视图关注并发与同步开发视图面向程序员关注模块与包的组织物理视图描述部署节点与网络场景视图把这些串起来。实践中团队最容易缺的是进程视图。微服务架构中逻辑视图可以画对但进程视图里每个服务的实例数、线程池大小、队列长度、连接池上限都没有描述导致容量评估无从下手。这里推荐在架构文档中为每个关键进程补一张进程资源描述表包含实例数、线程池、队列容量、依赖的外部资源并把超限后的行为写清楚。ADL如 Darwin、Wright的价值在于用形式化语法描述构件与连接子让架构文档可以被工具解析和一致性校验。日常项目中不必强行引入 ADL但可以借用 ADL 的表达习惯构件声明接口与行为连接子声明交互协议架构配置描述实例之间如何装配。这样即使文档用 Markdown 写整个结构也比画几张孤立的图更完整。架构文档应包含的六个部分架构目标与约束关键质量属性和约束来源候选架构与决策理由对比过哪几种方案为什么选当前方案逻辑视图模块划分、依赖方向、核心接口进程视图进程、线程、队列、连接池与调度策略物理视图节点、网络分区、容灾边界架构评估与风险已知风险、权衡点、非风险架构建模工具可选的不少但选择标准是“能不能和代码评审流程打通”。如果工具只用来画图不维护依赖关系三个月后文档就与现实脱节。更务实的做法是让架构文档直接引用主干代码中的接口定义减少人工同步。3. 从理论到评审ATAM 评估与架构权衡3.1 ATAM 不是评审会是风险识别流程系统架构设计师考试中架构评估是案例题的重头戏。ATAMArchitecture Tradeoff Analysis Method的核心不是给架构打分而是通过“效用树—敏感点—权衡点—风险主题”的路径把架构决策与业务目标对齐。ATAM 的执行步骤可以压缩成以下工作流呈现业务驱动因素让干系人说出系统最重要的三到五个业务目标。呈现架构由架构师介绍视图与关键决策。识别架构方法逐条列出与质量属性相关的模式策略例如主从复制、消息队列、限流熔断。生成效用树从可用的性能/可用性/安全/可修改性四个高层属性出发逐步细化为可测量的场景并按“重要性×难度”排序。分析架构方法对每个场景追问当前架构如何支撑这个场景成本是什么识别敏感点与权衡点一个决策可能同时影响多个质量属性。例如增加副本提高可用性但引入数据一致性延迟这是权衡点。生成风险主题把相关风险归纳成几类写进风险登记册。实际操作中的常见问题是在第 4 步就已经分裂。业务方提“速度要快”架构师提“并发要准”两边谈的不是同一个场景。ATAM 的效用树就是用来强迫双方把话落到“哪个用户在什么条件下拿到什么结果”的粒度。3.2 权衡点怎么记录ADR 模板即使没有完整走 ATAM每个关键架构决策都应该有一份 ADRArchitecture Decision Record。ADR 用于记录“当时为什么选了这个方案”和对立方案被否定的原因。2021 年前后的架构师文档里ADR 已经成为团队事实上的标准实践。一个精简的 ADR 模板包含五部分标题、背景、决策、后果、替代方案。技术选型对比表示例决策维度方案 A方案 B关键差异数据一致性强一致性能成本高最终一致业务需容忍偏差取决于业务是否可补偿运维复杂度需独立组件团队要专项维护语言内建升级随应用发布要评估团队长期负载故障隔离独立进程隔离故障面小共享进程一个异常可能影响全局高可用要求下优先独立进程迁移成本已有部分实例需灰度新项目无存量可直接采用不能只看架构还要看存量表格的价值不是比较哪列打勾而是把比较的维度显性化。考案例题和做技术汇报一样评审人想看到的是你为什么认为这个维度比另一个维度更重要。一份 ADR 的 Markdown 示例# ADR-002 订单服务使用事件发布保证跨服务状态同步 ## 背景 订单创建后需要同步触发库存扣减与积分累计。直接调用接口在 库存服务故障时会出现订单与库存不一致。 ## 决策 订单服务在本地事务中写入订单表并同时写入 outbox 表 后台任务把 outbox 记录发布到消息队列下游消费后更新自身状态。 ## 后果 - 正面订单主链路不依赖下游可用性消息可重放具备最终一致性基础。 - 负面库存扣减可能重复执行消费端必须幂等查询实时性下降。 ## 替代方案 - 分布式事务协调器复杂度高且对非 XA 资源支持不理想。 - 直接 Feign 调用实现简单但长链路失败回滚代价高。这段模板的要点是把“决策”写成一个可执行的方案而不是一句“采用异步化”。如果不写后果和替代方案三个月后再看 ADR 只能看到结论看不到判断过程这份记录就失去了一半价值。4. 知识点落地的三类高频实现缓存、消息队列与微服务4.1 缓存一致性先定边界再定策略系统架构设计师知识点里缓存相关题目几乎年年出现。真正容易被忽略的不是 Redis 怎么用而是缓存与数据库的一致性边界。先给出一份简单可靠的缓存读写策略读先查缓存命中直接返回未命中查数据库回填缓存设置过期时间。写先更新数据库再删除缓存删除失败时通过重试或订阅 binlog 补偿。为什么更新数据库后不直接更新缓存而要删除因为并发写多时更新缓存容易产生中间态覆盖问题。删除缓存虽然会造成下一次读的缓存穿透但配合过期时间最终会收敛到一致。缓存删除事件的延迟重试伪代码def update_order(order_id, payload): db.update(order_id, payload) cache.delete(forder:{order_id}) # 若 delete 失败发送失败事件到补偿队列 if not cache.delete_succeed: mq.send(cache_evict_failed, order_id)补偿消费端收到事件后再次删除缓存。为了避免多实例并发删除造成的不一致可以在删除操作中携带业务版本号只有版本号匹配时才删除。代码后面要强调的是缓存一致性不是靠“删除命令”保证的而是靠“谁先写、谁删、失败后如何补偿”这三件事共同保证。4.2 消息队列选型与积压排查考试中的消息队列考点通常围绕可靠投递与消费语义展开。选型层面2021 年前后国内项目最常对比的是 RocketMQ、Kafka、RabbitMQ 三类选型时关注的维度可以浓缩成一张表维度KafkaRocketMQRabbitMQ顺序性分区内有序队列内有序需配置单一消费者积压处理吞吐高扩容消费组即可支持重试队列吞吐中等积压后劣势明显事务消息不支持支持半消息机制需自行实现运维成本依赖 ZooKeeper/KRaft需维护 NameServer轻量易运维排查消息积压时不要一上来就增加消费者。先做三步检查消费耗时对每条消息打印处理耗时看是否有慢 SQL 或外部调用超时。查看重复消费确认消费逻辑是否幂等避免重投放大了下游压力。看消费线程配置单线程消费消费速度上限是单条耗时的倒数确认线程数和分区数的分配关系。4.3 微服务拆分与分布式事务的边界微服务架构是系统架构设计师考试的基础高频点。拆分本身不是目的拆完之后的数据一致性、依赖治理和部署复杂度才是关键。拆分的常见依据有以下几类按业务能力拆订单、库存、支付、用户各自独立成服务。按子域拆在 DDD 中先画限界上下文再确定服务边界。按变更频率拆把高频变更的模块与低频稳定模块分开降低回归测试范围。按团队组织拆康威定律作用下服务边界尽量匹配团队责任边界。分布式事务方面2021 年考试和工作中最常出现的模式仍是补偿事务Saga和本地消息表。两阶段提交协议适合严格一致性场景但协调者本身成为单点和性能瓶颈互联网业务中很少作为默认选项。Saga 的核心是每一笔本地事务都对应一个补偿动作当链路中某一环失败时向前逐级调用补偿操作。Saga 执行状态机的简化流程订单创建 - 扣库存 - 扣余额 - 完成 失败 失败 失败 触发 触发 触发 释放订单 回补库存 回补余额注意Saga 只保证最终一致不提供隔离性。若两个 Saga 并发操作同一资源可能出现“丢失更新”之类的问题。因此架构文档中必须明确每个 Saga 事务涉及的资源列表并为关键资源加上版本号或状态机约束。这一条常被忽略也是案例题里区分深度的重要得分点。4.4 架构师必须掌握的全局部署与容灾视角系统架构设计师考试中的部署层面考点包括负载均衡、会话保持、主从复制、多活架构。一个系统的可用性算法是各组件可用性的乘积所以任何单点都会拉低整体可用性。常规做法是在业务前端部署负载均衡器后端服务做多实例部署数据库做主从复制并启用自动故障切换缓存集群也采用分片和副本机制。容灾部署方面常见的是同城双活与异地多活。同城双活主要解决机房级别的单点故障数据同步采用同步复制两边的业务都可以承接读写流量。异地多活的难点在于数据冲突解决如果没有严格的分片路由规则跨地域延迟和脑裂风险会给业务带来很大负担。架构师在选型时应优先判断业务是否真的需要跨地域容灾而不是为了架构完整性引入过高的成本。5. 应试与实战通用的检查清单用知识点集锦压缩复习成本系统架构设计师考试的特点是“上午题考广度下午案例题考取舍论文题考完整叙事”。知识点的集锦文档可以帮你快速过完全部范围但真正提分的是下面这张检查清单考前和实际做架构方案时都适用。架构决策前按顺序问自己四个问题质量属性是否已经写成可度量场景如果答案里只有“保证高性能”而没有具体指标这个方案没有可评审性。是否明确权衡点选择中间件或拆分方案时必须能说清“换来什么、放弃什么”。例如选择了消息队列提高可用性就要接受查询的实时性下降。是否有补偿路径任何涉及分布式的设计都必须回答“失败后怎么恢复”否则架构评审会直接被打回。是否记录了替代方案有对比才有说服力。即使最后选择的技术一目了然也要把被否掉的方案和原因写进文档。论文写作时推荐按“背景—约束—架构设计—关键决策—评估验证”的结构展开。不要罗列一堆技术名词而是要围绕一个核心质量属性展开。比如以“性能”为主线就要把容量估算、限流设计、缓存策略、压力测试结果前后贯穿起来。每一个技术点都要回应最初提出的性能指标。最后的落地技巧是把知识点集锦变成你自己的一句话笔记。看到“可用性”就条件反射出“故障转移恢复时间目标幂等重试”看到“性能”就想到“响应时间-吞吐量-资源利用率”三个维度看到“可修改性”就列出“模块独立-接口稳定-配置外置”。考试和评审唯一的区别是考试有时间限制而评审要把这些判断过程讲给别人听。把这句话记住无论题目怎么变你都有应对的骨架。本文还有配套的精品资源点击获取