架构决策记录（ADR）
ADR 保存重要技术选择的上下文、决定和后果。本文负责选型依据、记录状态和验证条件。它用于资深岗位的架构决策追问。
1. 面试核心
先记住这几条，再读正文- 决策记录。 ADR 记录架构选择的约束、备选方案、决定和后果。卡 · 综合题
- 约束与假设。 硬约束用于淘汰方案，假设通过实验或数据验证。
- 决策替代。 已接受的 ADR 保留原结论，新 ADR 通过 Superseded 关系替代它。
- 复审条件。 复审条件将技术决定与 SLO、成本和迁移结果关联。
2. 架构决策范围
ADR 适合影响广、改动成本高的选择。例如服务边界、存储方案、公开协议和运行平台。局部实现细节留在代码评审中。
判断标准是后续修改是否依赖当时的取舍。重要约束和放弃方案应留下记录，便于后来者复查。
3. 约束
约束包括业务目标、交付期限和运行能力。性能、一致性、地域与隐私要求需写清适用范围。
例如“峰值 5000 QPS、P99 低于 200 ms”可用于验收。“高性能”缺少可判断的边界。尚未确认的内容标为假设，并指定验证方法。
选型从目标开始，再比较工具。团队已有技能、迁移窗口和供应商退出成本也应计入。
4. 备选方案比较
保留可行替代方案，并评估维持现状。各方案使用同一组标准：
- 方案是否满足硬约束。
- 实现与迁移需要多少投入。
- 运行故障会影响哪些用户。
- 方案如何验证，如何退出。
违反硬约束的方案可以提前淘汰。性能结论需有负载、数据量和环境条件。证据不足的项保留为待验证风险。
5. ADR 的内容
标题：一个具体架构决定
状态、日期、负责人
上下文与问题
约束与假设
备选方案
决定与适用范围
收益、成本与后续工作
验证方式与复审条件
每份 ADR 聚焦一个重要决定。详细流程和代码放在设计文档中。标题可写“订单事件采用 transactional outbox 发布”。读者能直接判断决策对象。
6. 决策状态
草案使用 Proposed，接受后转为 Accepted。拒绝的方案标为 Rejected，并保存原因。废弃方案可以标为 Deprecated。
新结论通过新 ADR 表达。新记录接受后，旧记录标为 Superseded，并链接新记录。原上下文和后果仍保留，便于解释迁移期行为。
7. 决策验证
ADR 关联实现任务、压测结果和运行指标。验证条件需包含目标值、负责人和复审时间。
例如异步复制方案需写出允许的 RPO。复制延迟告警和灾后对账用于验证这一约束。长期超出目标时，按复审条件重新评估。
架构检查还能验证模块依赖与 API 兼容性。可执行规则用于发现实现偏离。
8. ADR 评审
评审确认问题、证据和决策负责人。具体分歧处理见设计评审。
ADR 中保留最终决定、未消除风险和验证任务。尚有阻塞任务时，记录继续处于 Proposed。接受状态表示决定获准，运行结果仍需持续验证。
9. 示例
订单服务需要可靠发布事件。团队已有 MySQL 与 Kafka，业务允许秒级延迟。业务记录和待发事件需要共同提交。
可以比较直接双写与 transactional outbox。直接双写存在一侧成功的窗口。Outbox 使用本地事务写入业务和待发事件。发布器负责重试，消费者负责去重。
决策后果包括事件表清理和发布延迟监控。验证需覆盖发布器崩溃与重复投递。机制见Transactional Outbox 与 CDC。
10 · 面试题卡片
10.1 做技术选型时怎样形成可追溯的架构决策
出现公司：暂无已核验的公开来源（本站自测）
题型：综合题
考察重点
- 理解问题、硬约束、假设和证据。
- 理解备选方案、后果与可逆性。
- 理解ADR 生命周期、验证和复审条件。
参考回答
可追溯的选型需要记录约束、方案、证据和后果。
硬约束用于淘汰方案，假设用原型或压测验证。可行方案与维持现状使用同一组评估标准。
ADR 保存最终决定、适用范围和验证条件。决定接受后保留原结论。约束变化时，新 ADR 链接并替代旧记录。实现任务与运行指标用于核验决定是否仍然适用。