性能

• 缓存：减少数据库访问，降低响应时间。
• 异步：缩短主链路，提升吞吐量。
• 读写分离：分散数据库压力。
• 负载均衡：分摊请求，支持横向扩展。

可用性

• 冗余部署：避免单点故障。
• 健康检查：及时发现异常实例。
• 熔断降级：防止故障扩散。
• 备份恢复：降低数据丢失和停机影响。

可靠性

• 事务：保证关键数据一致。
• 幂等：避免重复请求造成重复处理。
• 补偿：处理跨系统最终一致性。
• 审计日志：便于追踪和修复。

安全性

• 认证：确认是谁。
• 授权：控制能做什么。
• 加密：保护传输和存储数据。
• 审计：记录关键操作。
• 输入校验：防止注入和非法数据。

可维护性

• 分层：职责清晰。
• 模块化：影响范围可控。
• 接口抽象：隔离变化。
• 自动化测试：降低回归风险。
• 日志监控：提高定位效率。

必做

• 通读 案例分析专题，背质量属性与 ATAM 框架。
• 通读 论文模板专题，确定一个万能项目背景。
• 把万能项目写成 300-500 字素材。

当天产出

• 1 份项目背景。
• 1 张质量属性速记表。
• 1 个论文摘要模板。

晚上自测

看到下面词语能否立刻说出 3 个措施：

• 高可用
• 高并发
• 可扩展
• 安全性
• 可维护性

必做

• 练 1-2 道案例题，重点练“材料定位”。
• 每题按这个格式写：

问题：
材料线索：
涉及质量属性：
架构措施：
为什么有效：
可能代价：

高频题型

• 给系统选架构风格。
• 给质量属性场景补刺激源、环境、响应。
• 判断设计方案优缺点。
• 针对性能/可靠性/安全性提出改进。
• 解释缓存、消息队列、微服务、数据库设计的作用。

必做

• 选一个最稳主题完整写一篇。
• 建议主题：论软件系统架构设计及其应用 或 论质量属性在架构设计中的应用。
• 严格控制结构：

摘要：300 字左右
正文：
  1. 项目背景与本人职责
  2. 主题理论说明
  3. 具体架构实践 1
  4. 具体架构实践 2
  5. 具体架构实践 3
  6. 效果、问题与改进

检查点

• 有没有明确“我作为系统架构设计师”？
• 有没有项目规模、技术栈、业务约束？
• 有没有 3 个具体措施？
• 有没有效果数据或可验证结果？

必做

把同一个项目改写到 4 个主题：

• 架构评估
• 微服务架构
• 信息安全架构
• 高可用/可靠性架构

训练方式

每个主题不必完整写 2500 字，但必须写：

• 摘要
• 3 个正文小标题
• 每个小标题下 5-8 句核心内容

上午/下午

• 做 1 次案例限时训练，最多 90 分钟。
• 复盘时只看两类问题：
  • 是否漏答材料关键词。
  • 是否只写概念，没有写措施和效果。

晚上

• 背论文项目背景。
• 背 4 个主题的开头、三段措施、结尾。
• 整理第二天证件、准考证、文具。

案例分析

• 先看问题，再读材料。
• 每问先写关键词，再补解释。
• 不会的题也写“质量属性 + 架构措施 + 原因”。

论文

• 前 10 分钟列提纲，不直接开写。
• 摘要先写“项目 + 问题 + 方法 + 效果”。
• 正文必须反复扣题，不要写成项目流水账。
• 最后 10 分钟补标题、改错字、检查字数。

0.1 案例题常见得分点

案例分析不是让你自由发挥，通常按关键词给分。答题时优先写：

• 质量属性：性能、可用性、可靠性、安全性、可维护性、可扩展性、可修改性、可测试性、易用性。
• 架构机制：分层、微服务、缓存、消息队列、负载均衡、限流、熔断、降级、复制、分片、读写分离。
• 权衡关系：一致性 vs 可用性、性能 vs 安全、解耦 vs 复杂度、扩展性 vs 运维成本。
• 场景描述：刺激源、刺激、环境、制品、响应、响应度量。
• 风险与敏感点：单点故障、数据一致性、接口耦合、性能瓶颈、安全暴露、运维复杂度。

0.2 万能答题结构

遇到“分析、说明、设计、改进、评价”类题目，按下面顺序写：

1. 先判断问题类型：质量属性 / 架构风格 / 设计机制 / 风险改进。
2. 再指出现状问题：瓶颈、单点、耦合、一致性、安全、扩展性。
3. 给出架构措施：模式 + 技术机制 + 部署/数据方案。
4. 说明满足的质量属性：性能、可用性、可维护性等。
5. 补一句权衡：带来复杂度、成本、延迟或一致性问题。

0.3 高频句式

• “该方案通过 解耦调用双方，降低模块间依赖，提高系统的可修改性和可扩展性。”
• “引入缓存可以降低数据库压力、缩短响应时间，但会带来缓存一致性和失效策略设计问题。”
• “消息队列适合削峰填谷和异步解耦，但会引入消息丢失、重复消费、顺序性和最终一致性问题。”
• “微服务提升了独立部署和弹性扩展能力，但增加了服务治理、分布式事务、链路追踪和运维复杂度。”
• “该质量属性场景应包含刺激源、刺激、环境、制品、响应和响应度量，不能只写抽象目标。”

1.1 ATAM 必背

ATAM：Architecture Tradeoff Analysis Method，架构权衡分析方法。

核心目的：

• 识别架构方案对质量属性的满足程度。
• 发现 风险点、非风险点、敏感点、权衡点。
• 帮助干系人理解不同质量属性之间的取舍。

常见步骤：

提出业务驱动因素
→ 描述候选架构
→ 识别架构方法
→ 生成质量属性效用树
→ 分析架构方法
→ 识别风险点、敏感点、权衡点
→ 形成评估结果

1.2 四个关键词

• 风险点：可能导致质量属性目标无法达成的架构决策。
• 非风险点：已被证明不会影响目标达成的架构决策。
• 敏感点：某个设计决策对一个质量属性影响很大。
• 权衡点：某个设计决策同时影响多个质量属性，且有利有弊。

示例：

• 使用同步远程调用是性能和可用性的敏感点。
• 使用强一致分布式事务是性能、可用性和一致性的权衡点。
• 数据库单实例是可用性风险点。

1.3 质量属性场景模板

考题让你“补充质量属性场景”时，必须写六要素：

刺激源：谁发起？
刺激：发生了什么？
环境：正常 / 高峰 / 故障 / 攻击 / 维护期间？
制品：影响哪个系统、服务、模块、数据或接口？
响应：系统如何处理？
响应度量：多久、多少、比例、次数、恢复时间等可量化指标。

可直接套用：

在业务高峰期，普通用户提交订单请求，订单服务应在 2 秒内返回处理结果；
当库存服务暂时不可用时，系统应进行降级处理并记录待补偿任务，
保证核心下单流程可用。

1.4 质量属性与常用策略

• 性能：缓存、异步、并发、负载均衡、读写分离、索引、批处理、连接池。
• 可用性：冗余部署、故障检测、自动切换、限流、熔断、降级、隔离。
• 可靠性：事务、重试、幂等、补偿、日志、校验、备份恢复。
• 安全性：认证、授权、加密、审计、输入校验、最小权限、防重放。
• 可维护性：分层、模块化、接口隔离、配置化、日志监控、自动化测试。
• 可扩展性：无状态服务、水平扩展、分库分表、服务拆分、插件化。
• 可修改性：低耦合、高内聚、依赖倒置、适配器、配置驱动。

2.1 分层架构

适用：

• 管理信息系统、业务系统、后台系统。
• 业务逻辑较稳定，强调可维护性和职责清晰。

常见层次：

表示层 → 应用层 / 服务层 → 领域层 / 业务逻辑层 → 数据访问层 → 数据层

答题关键词：

• 职责分离、降低耦合、提高可维护性。
• 上层依赖下层，禁止跨层访问。
• 可能带来性能开销，不适合极低延迟场景。

2.2 MVC / MVP / MVVM

• MVC：模型、视图、控制器分离，适合 Web 应用。
• MVP：Presenter 负责表现逻辑，便于测试。
• MVVM：ViewModel 与 View 数据绑定，适合前端和客户端界面。

答题句式：

该模式将界面展示、用户交互和业务数据分离，
降低 UI 与业务逻辑耦合，提高可维护性和可测试性。

2.3 管道-过滤器

适用：

• 数据处理流水线、编译器、日志处理、ETL、图像处理。

关键词：

• 每个过滤器独立处理数据。
• 管道负责传递数据。
• 易复用、易扩展、支持并行。
• 不适合大量交互和共享状态场景。

2.4 事件驱动架构

适用：

• 异步通知、订单状态流转、物联网、消息分发、日志采集。

关键词：

• 发布订阅、异步解耦、削峰填谷。
• 提高可扩展性和可用性。
• 注意事件丢失、重复消费、顺序性和最终一致性。

2.5 微服务架构

适用：

• 大型复杂系统、多团队协作、不同服务负载差异大、需要独立部署。

核心收益：

• 服务自治、独立部署、独立扩展、技术异构、故障隔离。

主要代价：

• 分布式事务、服务治理、网络延迟、接口版本、链路追踪、配置管理、运维复杂。

常见配套：

• 服务注册发现、API 网关、配置中心、限流熔断、链路追踪、集中日志、监控告警。

3.1 常见权衡关系

• 一致性 vs 可用性：强一致通常降低可用性和性能。
• 性能 vs 安全性：加密、认证、审计会增加处理开销。
• 性能 vs 可维护性：过度优化可能增加复杂度。
• 扩展性 vs 简单性：分布式架构提升扩展性，但开发运维更复杂。
• 解耦 vs 实时性：异步消息降低耦合，但结果可能不是实时一致。
• 复用性 vs 可理解性：抽象过多会提高理解成本。

3.2 答题模板

该设计提高了【质量属性 A】，因为【机制】能够【效果】；
但同时会影响【质量属性 B】，主要体现在【代价】。
因此需要结合业务优先级，在【场景】下选择【折中方案】。

示例：

使用消息队列提高了系统可用性和可扩展性，因为它可以异步解耦并削峰填谷；
但会影响数据一致性和实时性，订单状态可能需要通过补偿任务保证最终一致。

4.1 映射方法

看到需求，先分两类：

• 功能需求：系统要做什么。
• 质量需求：系统做得多快、多稳、多安全、多容易改。

再映射到架构：

需求 → 质量属性 → 架构策略 → 具体机制 → 风险与权衡

4.2 常见映射表

• 高并发访问 → 性能、可扩展性 → 负载均衡、缓存、异步、水平扩展。
• 7x24 小时服务 → 可用性 → 冗余部署、故障转移、健康检查、熔断降级。
• 敏感数据保护 → 安全性 → 身份认证、权限控制、传输加密、存储加密、审计。
• 业务规则频繁变化 → 可修改性 → 规则引擎、配置化、插件化、策略模式。
• 多端接入 → 可维护性、复用性 → API 网关、统一认证、接口标准化。
• 跨系统集成 → 互操作性 → 标准协议、适配器、消息总线、开放接口。

4.3 需求分析题答法

题目问“如何根据需求设计架构”：

1. 提取关键业务场景和质量属性目标。
2. 识别架构驱动因素，如高并发、高可用、安全合规、快速迭代。
3. 选择合适架构风格，如分层、微服务、事件驱动。
4. 设计关键机制，如缓存、消息、数据库拆分、网关、安全控制。
5. 分析风险和权衡，并给出监控、测试和演进措施。

5.1 “指出问题并改进”

优先找这些问题：

• 单点故障：单数据库、单应用、单缓存、单网关。
• 性能瓶颈：同步串行调用、数据库压力大、缺少缓存、无索引。
• 强耦合：模块直接互调、接口不稳定、业务逻辑散落。
• 数据问题：一致性无法保证、无事务/补偿、无备份、无幂等。
• 安全问题：明文传输、弱认证、权限粗放、无审计。
• 运维问题：无监控、无日志、无法灰度、不可回滚。

改进句式：

针对【问题】，可采用【机制】进行改进。
这样可以【收益】，但需要注意【代价/风险】。

5.2 “选择架构风格”

答题步骤：

1. 说明业务特点。
2. 选择架构风格。
3. 解释为什么匹配。
4. 指出可能不足。
5. 给出配套机制。

可背模板：

该系统业务模块边界清晰、不同模块负载差异较大，且需要独立部署和扩展，
因此适合采用微服务架构。各服务围绕业务能力拆分，通过轻量级接口通信，
并配合服务注册发现、API 网关、配置中心、熔断限流和集中监控。
需要注意分布式事务、服务治理和运维复杂度。

5.3 “补充架构图元素”

常见缺失：

• API 网关
• 认证授权服务
• 缓存
• 消息队列
• 数据库主从 / 分库分表
• 配置中心
• 注册中心
• 日志监控告警
• 文件/对象存储
• 备份恢复

6.1 性能优化

关键词：

• 建立合适索引，避免全表扫描。
• SQL 优化，减少复杂关联和大事务。
• 读写分离，主库写、从库读。
• 分库分表，降低单库单表压力。
• 连接池，减少连接创建开销。
• 缓存热点数据，减少数据库访问。

答题句式：

对于读多写少的场景，可采用读写分离和缓存机制。
主库负责写操作，从库承担查询压力；热点数据放入缓存，
从而降低数据库负载并提升响应速度。

6.2 可靠性与一致性

关键词：

• 事务 ACID、日志、备份、主从复制、故障切换。
• 本地事务适合同库强一致。
• 跨服务事务优先考虑最终一致、补偿事务、Saga、可靠消息。
• 幂等设计防止重复提交和重复消费。

常见踩坑：

• 只写“加数据库集群”，不说明主从、复制、切换和一致性。
• 分库分表后忘记跨库事务、全局唯一 ID、跨分片查询。
• 缓存更新不考虑一致性。

7.1 适用场景

• 热点数据读取频繁。
• 数据变化不太频繁。
• 允许短时间不一致。
• 查询代价高或数据库压力大。

7.2 常见问题与答案

• 缓存穿透：查询不存在的数据。可用空值缓存、布隆过滤器、参数校验。
• 缓存击穿：热点 Key 过期导致大量请求打到数据库。可用互斥锁、逻辑过期、热点不过期。
• 缓存雪崩：大量 Key 同时失效或缓存集群故障。可用随机过期时间、限流降级、多级缓存。
• 缓存一致性：更新数据库后删除缓存，或采用延迟双删、消息通知、过期时间兜底。

可背模板：

缓存用于提升读性能并降低数据库压力，但必须设计失效策略和一致性策略。
对于热点数据，可设置合理过期时间并避免集中失效；
对于更新操作，可先更新数据库再删除缓存，并通过消息或定时任务兜底修复。

8.1 主要作用

• 异步处理：缩短主流程响应时间。
• 解耦系统：生产者和消费者不直接依赖。
• 削峰填谷：缓冲突发流量。
• 广播通知：一个事件触发多个订阅者。

8.2 必写风险

• 消息丢失：持久化、确认机制、重试。
• 重复消费：幂等键、唯一约束、状态判断。
• 顺序问题：同一业务键进入同一队列或分区。
• 积压问题：扩容消费者、限流、降级、死信队列。
• 一致性问题：可靠消息、事务消息、补偿机制。

答题句式：

下单后发送订单创建事件，由库存、积分、通知等服务异步消费。
这样可以降低下单链路耗时并解耦服务，但消费者必须保证幂等，
并通过确认、重试和死信队列处理失败消息。

9.1 拆分原则

• 按业务能力拆分，而不是按技术层拆分。
• 服务边界清晰，数据尽量自治。
• 高频变化模块独立出来。
• 高负载模块可独立扩展。
• 避免过细拆分导致调用链过长。

9.2 常见治理机制

• API 网关：统一入口、路由、鉴权、限流。
• 注册中心：服务发现。
• 配置中心：集中管理配置。
• 熔断限流：防止故障扩散。
• 链路追踪：定位跨服务调用问题。
• 集中日志和监控：支撑运维。
• 灰度发布：降低上线风险。

9.3 分布式事务答法

优先写：

• 避免大范围强一致事务。
• 根据业务选择最终一致。
• 采用 Saga、TCC、可靠消息、补偿机制。
• 每个操作要支持幂等和可重试。

可背模板：

微服务场景下不宜直接依赖传统单库事务。
对于跨服务业务流程，可将长事务拆分为多个本地事务，
通过可靠消息或 Saga 编排实现最终一致；
失败时执行补偿操作，并通过幂等机制避免重复处理。

10.1 安全控制点

• 认证：确认用户是谁，如账号密码、短信、OAuth2、单点登录。
• 授权：确认用户能做什么，如 RBAC、ABAC、最小权限。
• 传输安全：HTTPS、TLS、防止窃听和篡改。
• 存储安全：敏感字段加密、密码哈希加盐。
• 输入校验：防 SQL 注入、XSS、命令注入、越权参数。
• 审计追踪：记录关键操作、登录、权限变更、数据导出。
• 接口防护：签名、时间戳、Nonce、防重放、限流。

10.2 答题模板

系统应在网关层进行统一认证、限流和基础安全校验；
在服务层进行细粒度授权和业务规则校验；
在数据层对敏感字段加密存储，并记录关键操作审计日志。
对于外部接口，应使用签名、时间戳和随机数防止请求被篡改或重放。

常见踩坑：

• 把认证和授权混为一谈。
• 只写 HTTPS，不写权限控制和审计。
• 只写“加密”，不区分传输加密、存储加密、密码哈希。

11.1 高可用机制

• 冗余部署：多实例、多节点、多机房。
• 健康检查：及时发现故障节点。
• 自动故障转移：主备切换、流量切换。
• 负载均衡：分摊请求压力。
• 限流：保护系统不被流量打垮。
• 熔断：下游故障时快速失败。
• 降级：保核心功能，舍弃非核心功能。
• 隔离：线程池、连接池、服务隔离，避免故障扩散。

11.2 可靠性机制

• 超时控制：避免无限等待。
• 重试机制：处理临时故障，但要控制次数和退避。
• 幂等设计：支持重复请求不产生副作用。
• 补偿机制：失败后恢复业务一致性。
• 备份恢复：应对数据损坏或误操作。
• 日志审计：支持追踪和恢复。

可背模板：

为提升系统高可用性，应避免单点故障，对核心服务进行多实例部署，
通过负载均衡分发请求，并结合健康检查和自动故障转移。
当下游服务异常时，应设置超时、熔断和降级策略，
保证核心业务链路不被非核心功能拖垮。

12.1 电商下单

重点：

• 高并发、库存一致性、支付可靠性、消息异步、幂等。

答案关键词：

• 缓存商品信息和库存展示。
• 下单主流程尽量短。
• 库存扣减使用事务或预扣库存。
• 支付回调用幂等。
• 订单事件通过消息队列通知库存、物流、积分。
• 失败后补偿或取消订单。

12.2 在线考试 / 报名系统

重点：

• 高峰访问、数据安全、提交可靠、断点恢复。

答案关键词：

• CDN / 静态资源缓存。
• 负载均衡和水平扩展。
• 限流排队，防止瞬时流量冲垮系统。
• 答案定时保存。
• 关键数据加密和审计。
• 数据库主从、备份和容灾。

12.3 物联网平台

重点：

• 海量设备接入、异步处理、实时监控、可靠传输。

答案关键词：

• MQTT / 消息队列。
• 设备接入层与业务处理层解耦。
• 流式处理或批处理。
• 时序数据库。
• 设备认证、数据加密。
• 异常告警和监控。

12.4 政务 / 金融系统

重点：

• 安全、审计、可靠性、数据一致性、合规。

答案关键词：

• 身份认证、权限控制、最小权限。
• 敏感数据加密。
• 操作审计和日志留存。
• 主备容灾和备份恢复。
• 关键交易强一致或可追溯补偿。

13.1 每天必背关键词

• ATAM：风险点、非风险点、敏感点、权衡点、效用树。
• 质量属性场景：刺激源、刺激、环境、制品、响应、响应度量。
• 高可用：冗余、负载均衡、健康检查、故障转移、限流、熔断、降级。
• 高性能：缓存、异步、并发、索引、读写分离、分片、连接池。
• 微服务：网关、注册中心、配置中心、链路追踪、集中日志、服务治理。
• 消息队列：异步、解耦、削峰、幂等、重试、死信、最终一致。
• 安全：认证、授权、加密、审计、输入校验、防重放、最小权限。

13.2 考场避坑

• 不要只写技术名词，要写“解决什么问题”。
• 不要只写优点，至少补一句代价或风险。
• 不要把性能、可用性、可靠性混用。
• 不要写“数据库集群”这种空话，要说明主从、复制、切换、备份。
• 不要把微服务当万能答案，小系统优先分层架构更合理。
• 不要忽略量化指标，质量属性场景必须有响应度量。

13.3 一页万能模板

【问题识别】
该系统主要面临高并发访问、核心服务可用性、数据一致性和安全控制问题。

【架构方案】
整体可采用分层 / 微服务 / 事件驱动架构。
入口层通过 API 网关统一路由、认证、限流；
业务层按领域能力拆分服务；
数据层采用缓存、读写分离、主从复制和备份恢复；
异步场景使用消息队列解耦并削峰填谷。

【质量属性】
缓存、异步和负载均衡提升性能；
多实例部署、健康检查、熔断降级提升可用性；
事务、幂等、补偿和可靠消息提升可靠性；
认证、授权、加密和审计提升安全性。

【风险权衡】
该方案提高扩展性和可维护性，但会增加分布式事务、
服务治理、监控运维和数据一致性处理复杂度。

万能分段比例

• 摘要：250-350 字
• 项目背景：400-600 字
• 正文第一段：600-800 字，写总体架构与核心思路
• 正文第二段：600-800 字，写关键技术措施
• 正文第三段：500-700 字，写治理、评估、效果
• 结尾：200-300 字

万能项目设定

如果没有真实项目，可统一使用下面这个项目。不同主题只替换技术重点。

我参与建设的是某省级政务服务综合管理平台，系统面向政务大厅、
业务主管部门、第三方服务机构和社会公众，支撑事项申报、材料流转、
审批协同、电子证照、统一支付、消息通知、统计分析等业务。

系统采用 B/S 架构，服务端基于 Java 技术栈建设，前端采用 Vue，
后端采用 Spring Boot / Spring Cloud，数据库采用 MySQL 和 Redis，
通过消息队列实现异步解耦，通过统一身份认证和 API 网关对外提供服务。

我在项目中担任系统架构设计师，主要负责需求分析、架构设计、
技术选型、核心模块划分、质量属性设计、关键风险识别和架构评审工作。

通用摘要模板

本文以我参与的【项目名称】为例，论述了【论文主题】在软件系统架构
设计中的应用。该项目面向【用户群体】，主要实现【核心业务功能】，
具有业务流程复杂、并发访问量较大、系统集成接口多、可靠性和安全性
要求高等特点。

我在项目中担任系统架构设计师，负责总体架构设计、关键技术选型、
核心模块划分以及质量属性保障方案设计。针对项目中存在的【主要问题1】、
【主要问题2】和【主要问题3】，我从【措施1】、【措施2】和【措施3】
三个方面进行了架构设计与落地实施。

通过上述设计，系统在可用性、可扩展性、可维护性和安全性方面得到了
明显提升，满足了业务上线和持续演进的需要。实践表明，合理运用
【论文主题】能够有效降低系统复杂度，提高系统质量，并为后续业务扩展
提供稳定支撑。

可直接替换的摘要句式

• “本文结合我主持/参与的某某系统建设实践，重点论述了……”
• “该系统具有业务流程长、参与角色多、外部接口复杂、质量要求高等特点。”
• “我作为系统架构设计师，主要承担总体架构设计、技术选型和质量属性保障工作。”
• “针对上述问题，我从架构分层、服务拆分、数据治理和安全控制等方面进行了设计。”
• “系统上线后运行稳定，能够支撑业务高峰访问，并具备良好的扩展能力。”

背景写法

项目背景要回答四个问题：

1. 这是一个什么系统？
2. 给谁用？
3. 做哪些核心业务？
4. 为什么需要架构设计？

通用模板

随着【行业背景】的发展，原有系统在业务支撑能力、数据共享能力和系统
扩展能力方面逐渐暴露出不足。为提升【业务目标】，单位启动了【项目名称】
建设工作。

该系统主要面向【用户角色1】、【用户角色2】和【用户角色3】，实现
【功能1】、【功能2】、【功能3】、【功能4】等业务功能。系统需要与
【外部系统1】、【外部系统2】、【外部系统3】进行数据交换，并要求支持
高并发访问、统一身份认证、全过程日志审计和业务流程灵活配置。

在项目初期，我们识别出三类主要挑战：一是业务流程复杂，不同部门之间
协同关系多；二是系统需要长期演进，必须具备良好的可扩展性和可维护性；
三是平台涉及用户身份、业务数据和接口调用，安全性与可靠性要求较高。

我在项目中担任系统架构设计师，负责组织需求分析、设计总体架构、
确定技术路线、划分系统模块，并推动架构方案评审和关键技术验证。

背景常用素材

• 政务项目：事项申报、审批流转、电子证照、统一身份认证、数据共享。
• 金融项目：账户管理、交易处理、风控规则、清算对账、审计追踪。
• 医疗项目：预约挂号、电子病历、检查检验、医保结算、数据互联互通。
• 教育项目：课程管理、考试报名、在线学习、成绩分析、统一门户。
• 企业项目：订单管理、库存管理、客户管理、供应链协同、经营分析。

第一段：总体架构与主题落点

在总体架构设计阶段，我首先根据业务边界和质量属性要求确定了系统的
整体架构。系统采用【分层架构/微服务架构/事件驱动架构】作为主体，
按照表现层、业务服务层、领域能力层、数据访问层和基础设施层进行划分。

其中，表现层负责用户交互和权限控制，业务服务层负责编排业务流程，
领域能力层封装核心业务规则，数据访问层负责持久化操作，基础设施层
提供缓存、消息、日志、监控和配置管理等通用能力。

这样的设计使系统职责更加清晰，降低了模块之间的耦合度，也为后续
围绕【论文主题】开展专项设计奠定了基础。

第二段：关键技术措施

针对项目中的关键问题，我重点采取了三项措施。

首先，在【措施1】方面，我通过【具体做法】解决了【对应问题】。
例如，在核心业务流程中，我们将【模块】与【模块】解耦，避免业务
规则散落在不同服务中，提高了系统的可维护性。

其次，在【措施2】方面，我引入【技术/机制】，对【关键资源】进行
统一管理。通过这种方式，系统能够在访问高峰、接口异常或业务变化时
保持稳定运行。

最后，在【措施3】方面，我建立了【治理/评估/监控】机制，对系统运行
状态、接口调用、异常日志和性能指标进行持续跟踪，确保架构设计能够
真正落地。

第三段：效果、评估与改进

系统上线后，我们从功能正确性、性能、可用性、安全性和可维护性等方面
进行了验证。通过压力测试、故障演练、代码评审、接口联调和用户试运行，
确认系统能够满足业务要求。

在性能方面，系统通过缓存、异步处理和数据库优化提升了响应速度；
在可靠性方面，通过限流、熔断、重试和监控告警降低了故障影响范围；
在安全性方面，通过统一认证、权限控制、数据加密和日志审计保障了
业务数据安全。

当然，项目也存在一些不足。例如，部分历史数据质量不高，跨部门接口
标准不完全统一，早期监控指标还不够细。后续我们计划继续完善数据治理、
自动化测试和架构度量体系，以支持系统持续演进。

通用结尾

综上所述，在【项目名称】建设过程中，我围绕【论文主题】进行了系统性
架构设计。通过合理的架构分层、清晰的模块划分、有效的质量属性保障
措施以及持续的架构评估，系统较好地满足了业务发展和稳定运行的要求。

通过本项目实践，我认识到架构设计不仅是技术选型，更是对业务目标、
质量属性、团队能力和长期演进成本的综合权衡。后续工作中，我将继续
完善架构治理、自动化测试、监控告警和数据治理机制，使系统具备更强
的可持续演进能力。

高分结尾句式

• “架构设计的核心不是追求技术先进，而是让技术选择服务于业务目标。”
• “质量属性需要在架构早期被识别，并通过具体设计措施落实到系统中。”
• “架构评估不是一次性活动，而应贯穿需求、设计、开发、测试和运维全过程。”
• “通过本项目实践，我进一步认识到，优秀架构需要在复杂度、成本和收益之间取得平衡。”

6.1 软件架构风格

可写重点：

• 分层架构：职责清晰，适合管理系统。
• 微服务架构：服务自治，适合复杂业务和独立部署。
• 事件驱动架构：异步解耦，适合流程长、峰值高的场景。
• 管道过滤器：适合数据处理、日志分析、报表加工。

可背诵句式：

我没有简单追求某一种架构风格，而是根据业务复杂度、团队能力和质量
属性要求进行组合设计。系统整体采用分层架构保证结构清晰，在关键业务
能力上采用微服务思想进行边界划分，在跨系统通知和状态同步场景中采用
事件驱动方式降低耦合。

6.2 质量属性

常见质量属性：

• 可用性：集群部署、故障转移、监控告警。
• 性能：缓存、异步、索引优化、读写分离。
• 安全性：认证、授权、加密、审计。
• 可维护性：分层、模块化、统一规范、自动化测试。
• 可扩展性：接口标准化、服务拆分、配置化。

可背诵句式：

在架构设计中，我将质量属性作为重要约束，而不是在编码完成后再补救。
项目初期，我通过质量属性场景描述方法，明确了系统在性能、可用性、
安全性和可维护性方面的具体目标，并将这些目标分解到架构设计、开发
规范和测试验证中。

6.3 架构评估

可写重点：

• 识别利益相关者：业务方、开发方、运维方、安全方。
• 明确质量属性场景：刺激源、刺激、环境、制品、响应、度量。
• 分析风险点、敏感点、权衡点。
• 输出改进措施。

可背诵句式：

在架构评估中，我重点关注风险点、敏感点和权衡点。风险点是可能导致
系统失败的设计决策，敏感点是对质量属性影响较大的架构参数，权衡点
则是多个质量属性之间需要取舍的地方。例如，提高安全控制强度可能增加
响应时间，因此需要在安全性和性能之间进行平衡。

6.4 微服务

可写重点：

• 按业务能力拆分服务，而不是按技术层拆分。
• API 网关统一入口。
• 注册发现、配置中心、限流熔断、链路追踪。
• 数据库按服务边界管理，避免共享数据库导致强耦合。

可背诵句式：

微服务拆分的关键不是服务数量越多越好，而是边界是否清晰、数据是否
自治、团队是否具备治理能力。项目中我以业务能力为依据划分服务，
通过 API 网关统一接入，通过注册中心和配置中心支持服务治理，并通过
链路追踪、限流熔断和监控告警降低分布式系统复杂度。

6.5 DDD 领域驱动设计

可写重点：

• 统一语言：业务和技术共用概念。
• 限界上下文：划分业务边界。
• 聚合根：保证业务一致性。
• 领域服务：封装跨实体业务规则。

可背诵句式：

在复杂业务系统中，如果只按照数据库表或页面功能进行设计，容易导致
业务规则分散和模型失真。因此我引入 DDD 思想，通过统一语言减少沟通
偏差，通过限界上下文划分业务边界，通过聚合根维护一致性边界，使核心
业务规则集中表达并便于演进。

6.6 云原生

可写重点：

• 容器化部署：镜像一致、环境隔离。
• Kubernetes 编排：弹性伸缩、滚动发布、自愈。
• DevOps：持续集成、持续交付。
• 可观测性：日志、指标、链路追踪。

可背诵句式：

云原生架构的价值在于提高系统交付效率和运行弹性。项目中我将应用进行
容器化改造，通过 Kubernetes 实现统一部署、弹性伸缩和故障自愈，通过
CI/CD 流水线减少人工发布风险，并通过日志、指标和链路追踪建立可观测
能力，从而支撑系统快速迭代和稳定运行。

6.7 信息安全

可写重点：

• 身份认证：统一登录、Token、单点登录。
• 访问控制：RBAC、最小权限。
• 数据安全：传输加密、存储加密、脱敏。
• 安全审计：操作日志、登录日志、接口调用日志。

可背诵句式：

信息安全设计应贯穿系统全生命周期，而不是上线前的补充措施。项目中我
从身份认证、访问控制、数据保护和安全审计四个方面进行设计，通过统一
认证解决身份可信问题，通过 RBAC 和最小权限原则控制访问范围，通过
加密和脱敏保护敏感数据，通过审计日志满足追踪和合规要求。

6.8 可靠性

可写重点：

• 冗余部署：多实例、负载均衡。
• 故障隔离：服务拆分、舱壁模式。
• 容错机制：超时、重试、熔断、降级。
• 运维保障：监控、告警、应急预案。

可背诵句式：

可靠性设计的重点是承认故障一定会发生，并通过架构手段限制故障影响。
项目中我采用多实例部署和负载均衡避免单点故障，通过超时、重试、熔断
和降级机制提升容错能力，通过监控告警和应急预案缩短故障发现与恢复
时间，确保核心业务在异常情况下仍能提供基本服务。

6.9 数据架构

可写重点：

• 数据分层：业务库、主题库、分析库。
• 主数据管理：统一编码、统一口径。
• 数据质量：完整性、准确性、一致性、及时性。
• 数据安全：分级分类、脱敏、权限控制。

可背诵句式：

数据架构设计的目标是让数据可管理、可共享、可信任。项目中我从数据
模型、数据流转、数据质量和数据安全四个方面进行设计，通过统一数据
标准解决口径不一致问题，通过主数据管理减少重复建设，通过数据校验
和质量监控提升数据可信度，通过分级分类和权限控制保障数据安全。

6.10 系统集成

可写重点：

• 集成方式：API、消息队列、文件交换、数据同步。
• 接口标准：统一协议、统一编码、统一错误码。
• 解耦设计：异步消息、适配器、防腐层。
• 稳定性：幂等、重试、补偿、监控。

可背诵句式：

系统集成的难点不在于接口调用本身，而在于接口标准、异常处理和业务
一致性。项目中我制定统一接口规范，通过 API 网关管理外部访问，通过
消息队列处理非实时业务，通过适配器屏蔽外部系统差异，并通过幂等、
重试、补偿和监控机制提升集成可靠性。

开头句

• “随着业务规模扩大，原有系统在扩展性、可靠性和数据共享方面逐渐暴露出不足。”
• “该系统并不是单一功能系统，而是一个涉及多角色、多流程、多接口的综合业务平台。”
• “在项目初期，我首先组织识别业务目标和关键质量属性，避免架构设计脱离实际需求。”

承接句

• “基于上述分析，我将问题归纳为三个方面。”
• “针对这一问题，我没有简单通过增加硬件解决，而是从架构层面进行优化。”
• “为了降低模块耦合，我将稳定的领域能力与易变化的业务流程进行分离。”
• “为了保证设计可落地，我将架构措施进一步细化到开发规范、测试方案和运维监控中。”

效果句

• “通过上述设计，系统职责更加清晰，模块耦合度明显降低。”
• “系统上线后运行稳定，能够支撑业务高峰期间的访问压力。”
• “相关措施提高了问题定位效率，也降低了后续需求变更的影响范围。”
• “该方案在满足当前业务需求的同时，也为后续功能扩展预留了空间。”

反思句

• “项目实践表明，架构设计需要在先进性、复杂度、成本和团队能力之间取得平衡。”
• “如果忽视质量属性，系统即使功能完整，也难以在真实环境中长期稳定运行。”
• “架构不是一次性文档，而是需要随着业务变化持续治理和演进。”

写作前检查

• 是否明确写出“我”的角色和职责？
• 是否有具体项目背景，而不是空谈理论？
• 是否围绕题目关键词展开？
• 是否准备了 3 个核心措施？
• 是否每个措施都有“问题、做法、效果”？

写作中检查

• 不要把论文写成技术名词堆砌。
• 不要只写概念定义，要结合项目场景。
• 不要全文没有业务功能，必须让阅卷人知道系统做什么。
• 不要只写开发实现，要突出“架构设计师”的决策和权衡。
• 不要只写优点，要适当写风险、评估和改进。
• 不要出现明显不合理规模，例如小系统强行上复杂微服务。
• 不要把所有主题都写一遍，要紧扣题目重点选择材料。

写作后检查

• 摘要是否覆盖项目、角色、主题、措施和效果？
• 正文是否至少出现 3 次题目关键词或同义表达？
• 是否写出了架构图思维，如分层、模块、接口、数据流？
• 是否写出了质量属性，如性能、可靠性、安全性、可维护性？
• 是否有测试、评估、上线效果或运维监控内容？
• 结尾是否有总结和后续改进？

最稳妥的三项措施组合

如果题目很陌生，可以使用下面这个组合：

1. 架构分层与模块划分：解决复杂度和可维护性。
2. 质量属性保障机制：解决性能、可靠性、安全性。
3. 架构评估与持续治理：解决落地和演进问题。

一句话记忆

先写项目和角色，再写问题和目标；
正文三段讲措施，每段都要有效果；
最后总结有反思，风险改进不能少。

1.1 性能

定义：系统在规定资源和负载下，完成请求的响应时间、吞吐量、并发能力和资源利用率。

案例怎么答：

• 先看瓶颈：CPU、内存、磁盘 IO、网络 IO、数据库、锁竞争、外部接口。
• 常用措施：缓存、异步化、批处理、连接池、索引优化、读写分离、水平扩展、负载均衡。
• 指标表达：响应时间、TPS/QPS、并发用户数、资源利用率、P95/P99 延迟。

论文怎么写：

• “针对高并发访问场景，我从缓存、异步解耦、数据库优化和弹性扩展四个层面提升性能。”
• “通过引入本地缓存和分布式缓存，减少热点数据对数据库的直接访问。”
• “对非实时任务采用消息队列异步处理，使核心交易链路保持短路径。”

1.2 可用性

定义：系统在指定时间内能够正常提供服务的能力，通常关注故障恢复和持续服务。

案例怎么答：

• 常用措施：冗余部署、故障转移、健康检查、限流降级、熔断、超时重试、灰度发布。
• 指标表达：可用性百分比、MTBF、MTTR、故障恢复时间、RTO、RPO。
• 注意：重试要有退避和幂等，否则可能放大故障。

论文怎么写：

• “为了保障核心业务连续性，我采用多实例部署和负载均衡实现服务冗余。”
• “对外部依赖设置超时、熔断和降级策略，避免局部故障扩散为系统性故障。”
• “结合监控告警和自动恢复机制，缩短平均故障恢复时间。”

1.3 可靠性

定义：系统在规定条件和时间内无故障完成规定功能的能力。

案例怎么答：

• 常用措施：事务控制、幂等设计、数据校验、补偿机制、重试机制、日志审计、容错设计。
• 区分可用性：可用性强调“能不能服务”，可靠性强调“结果是否正确可信”。

论文怎么写：

• “我通过状态机约束业务状态流转，避免非法状态导致数据不一致。”
• “对于跨系统操作，采用本地事务加消息确认和补偿机制保证最终一致性。”
• “关键操作均记录审计日志，便于故障追踪和数据修复。”

1.4 可扩展性

定义：系统在需求、用户规模或数据规模增长时，通过较小代价扩充能力的特性。

案例怎么答：

• 功能扩展：模块化、插件化、接口抽象、领域拆分。
• 容量扩展：水平扩展、分库分表、无状态服务、弹性伸缩。
• 反例：强耦合、共享数据库表过多、硬编码流程。

论文怎么写：

• “我将业务能力按领域边界拆分，降低模块间耦合，便于后续功能演进。”
• “服务层保持无状态，使系统可以通过增加实例实现水平扩展。”
• “通过接口抽象隔离外部系统变化，降低需求变更对核心业务的影响。”

1.5 可维护性

定义：系统在定位问题、修改功能、修复缺陷和适应变化时的容易程度。

案例怎么答：

• 常用措施：分层架构、模块化、低耦合高内聚、统一日志、代码规范、自动化测试。
• 关注点：修改影响范围、复杂度、可读性、可测试性。

论文怎么写：

• “系统采用分层架构，将表现层、业务层、数据访问层职责分离。”
• “公共能力沉淀为统一组件，避免重复实现带来的维护成本。”
• “通过单元测试和接口测试覆盖核心业务流程，提升变更后的回归效率。”

1.6 安全性

定义：系统保护数据和服务免受未授权访问、篡改、泄露和破坏的能力。

案例怎么答：

• 身份认证：口令、短信、OAuth2、单点登录、多因素认证。
• 授权控制：RBAC、ABAC、最小权限、接口鉴权。
• 数据保护：传输加密、存储加密、脱敏、签名、防重放。
• 攻击防护：SQL 注入、XSS、CSRF、越权、暴力破解。

论文怎么写：

• “我采用统一认证中心完成身份认证，结合 RBAC 控制用户访问范围。”
• “敏感数据在传输层使用 HTTPS，在存储层进行加密或脱敏处理。”
• “对关键接口加入签名、时间戳和随机数校验，降低重放攻击风险。”

1.7 可测试性

定义：系统支持测试设计、测试执行、缺陷定位和结果验证的能力。

案例怎么答：

• 措施：依赖注入、接口隔离、Mock、日志追踪、测试数据隔离、自动化测试。
• 关注：核心业务规则、边界条件、异常分支、接口契约。

论文怎么写：

• “我通过接口抽象和依赖注入降低测试难度，使核心业务逻辑可独立测试。”
• “围绕关键业务链路设计单元测试、集成测试和回归测试。”

2.1 分层架构

定义：将系统划分为表现层、业务层、数据访问层、基础设施层等，每层只承担明确职责。

案例怎么答：

• 优点：职责清晰、易维护、易替换、利于团队分工。
• 缺点：层间调用可能带来性能损耗，复杂业务容易出现贫血模型。
• 适用：管理系统、信息系统、业务流程清晰的应用。

论文怎么写：

• “我采用分层架构隔离展示逻辑、业务规则和数据访问逻辑，提升系统可维护性。”
• “对跨层公共能力，如日志、权限、异常处理，统一放在基础设施层实现。”

2.2 MVC

定义：Model 负责数据和业务，View 负责展示，Controller 负责请求分发和流程控制。

案例怎么答：

• 优点：界面与业务分离，便于维护和测试。
• 常见答法：Controller 不应堆积复杂业务，业务规则应下沉到 Service 或领域层。

论文怎么写：

• “前端交互采用 MVC 思想组织，降低界面变化对业务逻辑的影响。”

2.3 微服务架构

定义：按业务能力拆分为一组小型自治服务，各服务可独立开发、部署和扩展。

案例怎么答：

• 优点：独立部署、技术异构、弹性扩展、故障隔离。
• 挑战：分布式事务、服务治理、链路追踪、配置管理、部署复杂度。
• 配套：注册发现、网关、配置中心、监控、限流熔断、消息队列。

论文怎么写：

• “我按领域边界拆分微服务，使订单、支付、库存等服务独立演进。”
• “通过 API 网关统一接入认证、限流和路由，降低客户端调用复杂度。”
• “使用链路追踪定位跨服务调用问题，提升分布式环境下的可运维性。”

2.4 事件驱动架构

定义：系统组件通过事件发布和订阅完成协作，生产者与消费者解耦。

案例怎么答：

• 优点：异步解耦、削峰填谷、易扩展。
• 风险：消息重复、消息丢失、顺序问题、最终一致性。
• 措施：幂等消费、消息确认、死信队列、重试、事务消息。

论文怎么写：

• “对通知、统计、积分等非核心同步业务采用事件驱动方式异步处理。”
• “消费者侧基于业务唯一键实现幂等，避免消息重复消费造成数据错误。”

2.5 管道-过滤器

定义：数据经过一系列过滤器逐步处理，每个过滤器完成独立转换。

案例怎么答：

• 适用：编译器、数据清洗、日志处理、图像处理、批处理流程。
• 优点：步骤可复用、可替换、便于并行。

论文怎么写：

• “在数据处理链路中采用管道-过滤器风格，将采集、清洗、转换和入库拆成独立步骤。”

2.6 客户端-服务器与 B/S

定义：客户端发起请求，服务器提供服务；B/S 是基于浏览器的客户端-服务器模式。

案例怎么答：

• C/S：交互强、客户端能力强，但部署维护成本高。
• B/S：部署简单、跨平台好，但复杂交互依赖浏览器和网络。

论文怎么写：

• “系统面向多部门用户，采用 B/S 架构降低客户端安装和升级成本。”

3.1 工厂模式

定义：封装对象创建过程，使客户端不直接依赖具体类。

案例怎么答：

• 适用：根据类型创建不同处理器、策略、适配器。
• 价值：降低创建逻辑和业务逻辑耦合。

论文怎么写：

• “对多渠道接入的处理器创建采用工厂模式，避免业务代码中大量条件判断。”

3.2 策略模式

定义：将一组可替换算法封装成独立策略，使其可以在运行时切换。

案例怎么答：

• 适用：计费规则、促销规则、路由规则、审批规则。
• 价值：消除复杂 if-else，满足开闭原则。

论文怎么写：

• “针对不同业务类型的计费规则，我采用策略模式封装算法，新增规则时只需扩展策略类。”

3.3 观察者模式

定义：对象状态变化时自动通知依赖对象，常用于发布订阅。

案例怎么答：

• 适用：事件通知、状态变更、缓存刷新。
• 注意：同步观察者可能拖慢主流程，复杂场景可用消息队列替代。

论文怎么写：

• “订单状态变化后，通过事件通知库存、积分和消息服务，降低核心流程耦合。”

3.4 适配器模式

定义：将一个接口转换成调用方期望的接口，以兼容不同系统或组件。

案例怎么答：

• 适用：对接第三方支付、短信、地图、遗留系统。
• 价值：隔离外部接口变化。

论文怎么写：

• “对第三方服务封装适配层，使业务层不直接依赖外部接口细节。”

3.5 代理模式

定义：通过代理对象控制对真实对象的访问，可增加鉴权、缓存、日志、远程调用等能力。

案例怎么答：

• 适用：AOP、远程代理、缓存代理、权限代理。

论文怎么写：

• “通过代理机制统一处理权限校验、日志记录和事务控制，减少业务代码侵入。”

3.6 CQRS

定义：将命令写操作和查询读操作分离，分别优化写模型和读模型。

案例怎么答：

• 适用：读多写少、复杂查询、报表统计、性能要求高的系统。
• 风险：读写模型同步延迟，通常是最终一致。

论文怎么写：

• “针对查询压力大的场景，我采用读写分离思想构建查询模型，提高复杂查询性能。”

3.7 DDD 分层

定义：以领域模型为核心组织系统，常见层次包括用户接口层、应用层、领域层、基础设施层。

案例怎么答：

• 领域层放核心业务规则。
• 应用层负责编排流程，不承载复杂规则。
• 基础设施层处理数据库、消息、外部接口。

论文怎么写：

• “我围绕核心业务概念建立领域模型，将关键规则沉淀在领域层，避免业务逻辑散落。”

4.1 功能需求与非功能需求

定义：功能需求描述系统做什么，非功能需求描述系统做得怎么样。

案例怎么答：

• 功能需求：下单、支付、审批、查询、报表。
• 非功能需求：性能、安全、可靠性、可用性、可维护性、易用性。
• 案例题常要求把模糊描述转成质量属性。

论文怎么写：

• “需求分析阶段，我不仅识别业务功能，还重点分析性能、安全和可用性等质量属性。”

4.2 需求获取

定义：通过访谈、问卷、原型、文档分析、现场观察等方式识别干系人真实需求。

案例怎么答：

• 多角色系统要识别干系人：用户、管理员、运维、监管、外部系统。
• 模糊需求可用原型确认。
• 冲突需求要评审和优先级排序。

论文怎么写：

• “我通过用户访谈、业务流程梳理和原型评审获取需求，并与关键干系人确认范围。”

4.3 需求分析与建模

定义：对需求进行抽象、分解、建模和验证，形成可设计、可实现、可测试的规格说明。

案例怎么答：

• 常用模型：用例图、活动图、状态图、数据流图、ER 图。
• 复杂业务优先画状态和流程。
• 数据密集系统优先画数据模型和数据流。

论文怎么写：

• “对核心业务流程采用活动图建模，对关键对象采用状态图约束状态迁移。”

4.4 需求变更管理

定义：对需求变更进行提出、评估、审批、实施、验证和追踪的过程。

案例怎么答：

• 流程：变更申请 -> 影响分析 -> 评审批准 -> 修改计划 -> 实施验证 -> 更新文档。
• 影响分析：范围、进度、成本、质量、风险、接口。

论文怎么写：

• “项目中建立需求变更控制流程，对每次变更进行影响分析，避免范围蔓延。”

4.5 需求跟踪

定义：建立需求与设计、代码、测试、交付物之间的关联，保证需求完整实现和可验证。

案例怎么答：

• 正向跟踪：需求到设计、代码、测试。
• 反向跟踪：测试或代码回溯到需求。

论文怎么写：

• “通过需求跟踪矩阵关联需求、设计和测试用例，确保核心需求均可验证。”

5.1 ATAM

定义：架构权衡分析方法，用于评估架构对质量属性的满足程度，识别风险点、敏感点和权衡点。

案例怎么答：

• 步骤：介绍架构 -> 识别业务驱动 -> 提取质量属性场景 -> 分析架构决策 -> 识别风险。
• 关键词：质量属性场景、效用树、风险点、非风险点、敏感点、权衡点。

论文怎么写：

• “架构评审阶段，我采用 ATAM 思路构建质量属性效用树，重点评估性能、可用性和安全性。”
• “通过分析架构决策对质量属性的影响，识别缓存一致性和数据库扩展能力等风险点。”

5.2 质量属性场景

定义：用具体场景描述质量属性需求，通常包含刺激源、刺激、环境、制品、响应和响应度量。

案例怎么答：

• 性能场景：高峰期用户提交订单，系统 2 秒内返回结果。
• 可用性场景：某服务实例故障，系统 30 秒内自动切换。
• 安全场景：未授权用户访问敏感接口，系统拒绝并记录审计日志。

论文怎么写：

• “我将抽象质量需求转化为可度量场景，例如高峰期核心接口 P95 响应时间不超过 2 秒。”

5.3 敏感点与权衡点

定义：敏感点是一个设计决策对某质量属性影响显著；权衡点是一个决策同时影响多个质量属性且可能相互冲突。

案例怎么答：

• 缓存容量是性能敏感点。
• 加密强度可能是安全与性能的权衡点。
• 数据强一致是可靠性与性能、可用性的权衡点。

论文怎么写：

• “我识别到同步强一致会影响性能和可用性，因此对非核心数据采用最终一致性。”

5.4 架构视图

定义：从不同角度描述架构，常见包括逻辑视图、开发视图、进程视图、物理视图和场景视图。

案例怎么答：

• 逻辑视图：功能模块和职责。
• 开发视图：代码组织和组件依赖。
• 进程视图：运行时并发、通信、同步。
• 物理视图：部署节点、网络和硬件。
• 场景视图：用例驱动验证架构。

论文怎么写：

• “我从逻辑、开发、进程和部署多个视角描述架构，确保设计既能指导开发也能指导运维部署。”

6.1 生命周期模型

定义：软件从需求到交付维护的过程模型，包括瀑布、迭代、增量、螺旋、敏捷等。

案例怎么答：

• 瀑布：需求稳定、文档要求高。
• 迭代/增量：需求逐步明确，分阶段交付。
• 螺旋：风险高的大型项目，强调风险分析。
• 敏捷：需求变化快，强调快速反馈。

论文怎么写：

• “项目采用迭代增量方式，先交付核心业务闭环，再逐步扩展报表和运营能力。”

6.2 软件复用

定义：在新系统中使用已有需求、设计、代码、组件、框架或服务，以降低成本和风险。

案例怎么答：

• 复用层次：代码复用、组件复用、服务复用、架构复用、领域模型复用。
• 风险：不匹配、过度通用、依赖外部组件质量。

论文怎么写：

• “我将认证、权限、日志和消息通知沉淀为公共组件，提高复用率并减少重复开发。”

6.3 配置管理

定义：对代码、文档、配置、版本和变更进行标识、控制、审计和发布管理。

案例怎么答：

• 关键点：版本控制、基线管理、变更控制、发布管理、配置审计。

论文怎么写：

• “项目建立配置管理基线，对代码、数据库脚本和部署配置进行统一版本控制。”

6.4 测试策略

定义：通过不同层次和类型的测试验证软件满足需求并发现缺陷。

案例怎么答：

• 单元测试：验证函数或类。
• 集成测试：验证模块协作。
• 系统测试：验证整体需求。
• 性能测试：验证负载和响应。
• 安全测试：验证漏洞和权限。

论文怎么写：

• “我围绕核心交易链路设计单元、集成和性能测试，保障系统上线质量。”

6.5 DevOps 与持续交付

定义：通过自动化构建、测试、部署和监控，提升软件交付效率和质量。

案例怎么答：

• 常用措施：CI/CD、自动化测试、容器化、灰度发布、监控告警、回滚机制。

论文怎么写：

• “项目引入 CI/CD 流水线，在代码提交后自动执行构建、测试和部署，提高交付效率。”

7.1 事务 ACID

定义：原子性、一致性、隔离性、持久性，是关系数据库事务的基本特性。

案例怎么答：

• 原子性：要么全部成功，要么全部失败。
• 一致性：事务前后数据满足约束。
• 隔离性：并发事务互不干扰。
• 持久性：提交后数据永久保存。

论文怎么写：

• “对账户扣款等强一致操作使用数据库事务，保证关键数据满足 ACID 特性。”

7.2 CAP 与 BASE

定义：CAP 指一致性、可用性、分区容错性三者不能同时完全满足；BASE 强调基本可用、软状态、最终一致。

案例怎么答：

• 分布式系统必须考虑 P。
• CP：优先一致性，牺牲部分可用性。
• AP：优先可用性，接受最终一致。
• BASE 适合互联网高可用场景。

论文怎么写：

• “考虑网络分区不可避免，系统对核心资金数据选择 CP，对通知和统计类数据采用 BASE 思想实现最终一致。”

7.3 分布式事务

定义：跨多个服务或数据库的事务一致性问题。

案例怎么答：

• 2PC：强一致，但阻塞、性能差、协调者单点风险。
• TCC：Try、Confirm、Cancel，适合业务可补偿场景。
• Saga：长事务拆分为局部事务和补偿事务。
• 事务消息：本地事务与消息发送一致。

论文怎么写：

• “跨服务操作避免直接使用强分布式事务，对订单、库存等场景采用 Saga 补偿机制。”

7.4 分库分表

定义：将数据按规则拆分到多个库或表，以提升容量和并发能力。

案例怎么答：

• 垂直拆分：按业务或字段拆分。
• 水平拆分：按用户、订单、时间等维度拆分。
• 问题：跨库查询、分布式事务、全局 ID、扩容迁移。

论文怎么写：

• “随着数据量增长，我按用户 ID 进行水平分表，并引入全局 ID 生成机制避免主键冲突。”

7.5 读写分离

定义：主库负责写，从库负责读，通过复制降低主库压力。

案例怎么答：

• 优点：提升读性能。
• 风险：主从延迟导致读到旧数据。
• 措施：关键读走主库、延迟监控、读一致性策略。

论文怎么写：

• “对查询量大的业务采用读写分离，普通查询走从库，写后立即查询走主库保证一致性。”

7.6 NoSQL

定义：非关系型数据库，常见包括键值、文档、列族、图数据库。

案例怎么答：

• Redis：缓存、计数、分布式锁。
• MongoDB：文档数据、结构灵活。
• HBase/Cassandra：海量列式数据。
• 图数据库：关系网络、路径分析。

论文怎么写：

• “针对结构变化频繁的业务扩展信息，采用文档数据库降低表结构变更成本。”

8.1 缓存

定义：将高频访问数据放到更快介质中，减少后端系统压力并提升响应速度。

案例怎么答：

• 适用：热点数据、读多写少、允许短暂不一致的数据。
• 策略：Cache Aside、Read Through、Write Through、Write Back。
• 风险：缓存穿透、击穿、雪崩、数据不一致。

论文怎么写：

• “我将热点配置和商品信息放入 Redis 缓存，降低数据库访问压力。”

8.2 缓存穿透、击穿、雪崩

定义：

• 穿透：查询不存在数据，请求直接打到数据库。
• 击穿：热点 Key 失效，大量请求同时访问数据库。
• 雪崩：大量 Key 同时失效或缓存集群故障。

案例怎么答：

• 穿透：布隆过滤器、缓存空值、参数校验。
• 击穿：互斥锁、热点数据不过期、逻辑过期。
• 雪崩：过期时间随机化、多级缓存、限流降级。

论文怎么写：

• “为防止缓存雪崩，我设置随机过期时间，并在异常时通过限流和降级保护数据库。”

8.3 消息队列

定义：通过异步消息在系统之间传递数据，实现解耦、削峰和异步处理。

案例怎么答：

• 作用：异步解耦、削峰填谷、广播通知、最终一致。
• 问题：重复消费、消息丢失、顺序消费、积压。
• 措施：ACK、持久化、重试、死信队列、幂等、监控告警。

论文怎么写：

• “高峰期将耗时任务写入消息队列异步处理，避免同步链路阻塞用户请求。”
• “消费者使用业务唯一键去重，保证重复投递情况下处理结果仍然正确。”

9.1 认证与授权

定义：认证确认“你是谁”，授权确认“你能做什么”。

案例怎么答：

• 认证：账号密码、Token、OAuth2、SSO、MFA。
• 授权：RBAC、ABAC、ACL、最小权限。
• 越权问题：水平越权、垂直越权。

论文怎么写：

• “系统通过统一身份认证识别用户身份，并基于角色和资源权限控制访问范围。”

9.2 加密、签名与摘要

定义：

• 加密：保护数据机密性。
• 摘要：验证数据完整性。
• 签名：验证身份和防篡改。

案例怎么答：

• 对称加密：快，适合大量数据。
• 非对称加密：适合密钥交换和签名。
• 哈希摘要：不可逆，适合完整性校验。

论文怎么写：

• “敏感数据采用加密存储，接口报文通过签名和摘要校验防止篡改。”

9.3 常见 Web 安全

定义：Web 应用常见安全风险包括注入、跨站脚本、跨站请求伪造、越权等。

案例怎么答：

• SQL 注入：参数化查询、ORM、安全过滤。
• XSS：输出编码、输入过滤、CSP。
• CSRF：Token、SameSite Cookie、Referer 校验。
• 文件上传：类型校验、大小限制、隔离存储。

论文怎么写：

• “系统对输入参数进行合法性校验，并使用参数化查询防止 SQL 注入。”

9.4 安全审计

定义：记录关键操作和安全事件，支持追踪、追责和合规。

案例怎么答：

• 记录内容：用户、时间、IP、操作、对象、结果。
• 注意：日志防篡改、敏感字段脱敏、权限隔离。

论文怎么写：

• “对登录、授权、审批和数据导出等敏感操作记录审计日志，满足安全合规要求。”

10.1 限流

定义：控制单位时间内请求数量，防止系统被突发流量压垮。

案例怎么答：

• 算法：计数器、滑动窗口、漏桶、令牌桶。
• 位置：网关、服务端、接口级、用户级。

论文怎么写：

• “在 API 网关层设置限流策略，对高频接口按用户和接口维度控制访问速率。”

10.2 熔断与降级

定义：熔断是在依赖异常时快速失败，降级是在资源不足时提供简化服务。

案例怎么答：

• 熔断：防止故障扩散。
• 降级：保核心，牺牲非核心。
• 常和超时、重试、限流配合。

论文怎么写：

• “当外部服务异常时，系统自动熔断并返回默认结果，保障核心业务可用。”

10.3 幂等

定义：同一操作执行一次或多次产生相同结果。

案例怎么答：

• 场景：支付回调、订单提交、消息消费、重试。
• 实现：唯一业务号、去重表、状态机、乐观锁。

论文怎么写：

• “支付回调基于交易流水号做幂等校验，避免重复通知导致重复入账。”

10.4 灾备与备份

定义：通过备份、容灾和恢复方案，在故障或灾难后恢复服务和数据。

案例怎么答：

• RTO：恢复服务需要多长时间。
• RPO：最多允许丢失多少数据。
• 方案：冷备、热备、双活、多活、异地容灾。

论文怎么写：

• “系统制定备份和恢复策略，核心数据定期备份，并通过演练验证 RTO 和 RPO 目标。”

11.1 范围管理

定义：明确项目边界，控制范围变更，防止范围蔓延。

案例怎么答：

• 明确 WBS、需求基线、验收标准。
• 变更必须评估影响并审批。

论文怎么写：

• “我组织团队形成需求基线和 WBS，将项目范围分解到可交付成果，避免范围蔓延。”

11.2 进度管理

定义：对任务活动、资源和里程碑进行计划、跟踪和调整。

案例怎么答：

• 工具：甘特图、关键路径、里程碑、燃尽图。
• 延误处理：压缩工期、快速跟进、调整资源、削减非关键范围。

论文怎么写：

• “项目按迭代制定里程碑，核心功能优先交付，非核心需求排入后续迭代。”

11.3 风险管理

定义：识别、分析、应对和监控可能影响项目目标的不确定事件。

案例怎么答：

• 风险类型：技术、需求、进度、人员、外部依赖、安全。
• 应对：规避、转移、减轻、接受。

论文怎么写：

• “我建立风险清单，对高并发性能、第三方接口稳定性和数据迁移风险制定预案。”

11.4 沟通管理

定义：保障项目干系人及时获得准确、一致的信息。

案例怎么答：

• 机制：例会、周报、评审会、问题跟踪、会议纪要。
• 关键：明确责任人、截止时间和闭环结果。

论文怎么写：

• “项目建立定期沟通机制，通过周会和评审会同步风险、进度和变更事项。”

11.5 质量管理

定义：通过质量计划、质量保证和质量控制，确保交付物满足要求。

案例怎么答：

• 质量保证：过程是否按规范执行。
• 质量控制：交付物是否满足质量标准。
• 手段：评审、测试、审计、度量。

论文怎么写：

• “我在需求、设计、编码和测试阶段设置质量门禁，通过评审和自动化测试控制缺陷。”

12.1 质量属性题

先定位质量属性 -> 再说明问题原因 -> 最后给架构措施和指标

示例：
该问题主要影响系统可用性和可靠性。
原因是外部服务故障缺少隔离机制，导致请求阻塞并扩散。
可采用超时、熔断、降级、限流和异步队列进行治理，
并通过 MTTR、错误率、P95 响应时间等指标验证效果。

12.2 架构改进题

现状问题：
模块耦合高、数据库压力大、同步链路长、缺少故障隔离。

改进措施：
1. 按领域拆分模块或服务，降低耦合。
2. 引入缓存和读写分离，降低数据库压力。
3. 使用消息队列异步处理非核心任务。
4. 增加限流、熔断、降级和监控告警。
5. 通过接口抽象和适配层隔离外部系统变化。

12.3 分布式一致性题

核心资金、库存扣减等强一致场景，应优先保证一致性。
通知、积分、统计、搜索索引等可接受最终一致。
跨服务事务可采用 Saga、TCC 或事务消息。
同时要设计幂等、补偿、重试、死信队列和审计日志。

13.1 开头背景

本项目面向多角色、多业务流程和高并发访问场景，
既要满足核心业务功能，又要兼顾性能、可用性、安全性和可维护性。
作为系统架构设计人员，我主要负责需求分析、架构设计、
关键技术选型和架构评审工作。

13.2 架构设计

在架构设计上，我遵循高内聚、低耦合和关注点分离原则。
系统整体采用分层架构，将表现层、业务层、数据访问层和基础设施层分离。
对变化频繁或外部依赖较强的部分，通过接口抽象和适配层进行隔离，
从而提升系统的可维护性和可扩展性。

13.3 性能优化

针对高并发访问压力，我从缓存、异步化、数据库优化和水平扩展四个方面处理。
热点数据进入 Redis 缓存，复杂查询通过读写分离降低主库压力，
非核心耗时任务通过消息队列异步处理。
同时对核心接口进行压测，并以响应时间、吞吐量和资源利用率作为验证指标。

13.4 可用性保障

为了提高系统可用性，关键服务采用多实例部署并接入负载均衡。
对外部依赖设置超时、重试、熔断和降级策略，防止局部故障扩散。
同时建设监控告警和日志追踪机制，保证故障能够及时发现、定位和恢复。

13.5 安全设计

在安全设计方面，系统通过统一认证中心完成身份认证，
并基于角色权限模型控制用户访问范围。
敏感数据在传输过程中使用 HTTPS，在存储过程中进行加密或脱敏。
对登录、审批、数据导出等关键操作记录审计日志，满足追踪和合规要求。

13.6 总结收尾

通过上述架构设计和工程措施，系统在满足业务功能的同时，
较好地兼顾了性能、可用性、安全性和可维护性。
项目上线后运行稳定，核心业务响应时间和故障恢复能力达到预期目标。
后续仍可在自动化运维、容量预测和精细化监控方面继续优化。

材料

• 身份证
• 准考证
• 黑色签字笔，多准备 2 支
• 2B 铅笔、橡皮
• 手表或确认考场时间显示方式
• 透明文件袋

状态

• 不熬夜刷大题。
• 睡前只看论文提纲和质量属性表。
• 确认考点路线、入场时间、天气。

时间分配

0-5 分钟：扫题，确定选做题
5-65 分钟：完成最有把握的大题
65-82 分钟：补不会但能套框架的题
82-90 分钟：检查漏问、编号、术语

答题模板

该问题主要影响【质量属性】。
结合材料中的【业务/技术约束】，可采用【架构措施】。
其作用是【机制解释】，能够带来【效果】。
同时需要注意【代价/风险】，可通过【补偿措施】降低影响。

不会时的保底写法

• 性能：缓存、异步、并发控制、读写分离、负载均衡。
• 可用：冗余部署、故障转移、限流降级、健康检查、备份恢复。
• 安全：认证、授权、加密、审计、输入校验、最小权限。
• 可维护：分层、接口隔离、配置化、日志监控、自动化测试。
• 可扩展：微服务、模块化、事件驱动、插件化、水平扩容。

时间分配

0-10 分钟：审题 + 列提纲
10-25 分钟：摘要 + 项目背景
25-95 分钟：正文三大措施
95-110 分钟：效果、问题、改进
110-120 分钟：检查标题、扣题、字数、错别字

摘要模板

本文以我参与的【项目名称】为例，该项目面向【业务领域】，
需要解决【核心问题】。我作为系统架构设计师，负责【职责】。
围绕【论文主题】，我从【措施一】、【措施二】、【措施三】
三个方面开展架构设计与实施。项目上线后，在【性能/可靠性/
安全性/可维护性】等方面取得了较好效果。本文结合项目实践，
总结相关经验与不足。

正文万能三段

第一段：为什么需要这样做
第二段：具体怎么设计
第三段：实施效果与遇到的问题

质量属性

• 性能：响应时间、吞吐量、资源利用率。
• 可用性：故障检测、恢复时间、服务连续性。
• 安全性：机密性、完整性、可用性、可追溯。
• 可修改性：影响范围、修改成本、回归风险。
• 可扩展性：容量增长、功能扩展、水平扩容。

架构措施

• 分层降低复杂度。
• 缓存提升读性能。
• 消息队列削峰填谷、解耦异步。
• 冗余部署提升可用性。
• 熔断限流防止故障扩散。
• 统一认证授权保障安全。
• 监控日志提升可观测性。