架构决策与评审机制全景图
回答“业务目标、现实约束、质量属性和技术取舍怎样留下可追溯的理由，并在长期演进中持续校正”
阅读边界: 这页不是讲架构师如何拍板，也不是先选技术再补理由；它讲 ADR、架构评审、技术原则、例外管理、风险评估和适应度函数如何组成一套轻量但可执行的决策系统。
一句话判断: 好的架构治理不是审批更多事情，而是让重要决策有理由、有边界、有复查点、有退路。
| 先问什么 | 为什么影响架构 | 没有说清的后果 |
|---|
| 业务目标和成功指标 | 决定系统优先保护的是增长、成本、时效、准确性、合规还是体验。 | 方案看起来先进，但无法判断是否真的解决业务问题。 |
| 功能需求与核心场景 | 决定哪些能力是主路径，哪些只是边缘能力或后续扩展点。 | 为了少数场景设计过重架构，或者漏掉主链路风险。 |
| 非功能需求 | 性能、可靠性、安全、可维护性、可扩展性会直接改变模块、数据、部署和治理方案。 | 技术选型争论变成偏好之争，缺少可验证标准。 |
| 外部约束 | 团队规模、预算、上线时间、合规要求和供应商锁定会限制可行方案。 | 设计正确但落不了地，或上线后由运维和成本替架构还债。 |
识别重要决策
记录上下文
评估取舍
明确例外
设验证函数
定期复查
| 问题 | 根因 | 治理判断 |
|---|
| 几年后没人知道为什么这样设计 | 只留下结果，没有留下上下文和约束 | ADR 要记录当时为什么不选其他方案 |
| 架构评审变成走流程 | 评审只看图，不看风险、演进和运行后果 | 评审要围绕决策质量，而不是材料完整度 |
| 先定技术，再倒推理由 | 业务目标、约束和质量属性没有进入判断 | 先写清为什么做、约束是什么、哪些质量属性最重要，再比较技术方案 |
| 原则很多，但没人遵守 | 原则没有例外机制和验证方式 | 原则必须能触发检查、例外登记和复查 |
| 局部最优不断侵蚀整体结构 | 项目级目标压过系统级约束 | 通过适应度函数和架构雷达持续暴露退化 |
ADR
记录背景、候选方案、取舍、结果、影响和复查点，重点不是格式，而是保存判断。
架构评审
评审重大跨系统变更、不可逆决策和公共能力，不把所有小改动都拖进委员会。
技术原则
原则要少而硬，能指导取舍；太多原则会变成谁都能引用的装饰品。
例外管理
允许合理例外，但必须说明期限、风险、补偿措施和复查时间。
风险评估
关注可逆性、数据影响、依赖扩散、运行复杂度和组织承载能力。
适应度函数
把架构约束变成自动检查、指标看板或定期扫描，防止原则停在口号层。
| 例外机制 | 最低要求 | 判断重点 |
|---|
| 例外登记 | 说明偏离了哪条标准、为什么必须例外、影响哪些系统 | 例外不是口头豁免，而是可追踪的架构债 |
| 补偿控制 | 用额外监控、测试、隔离、人工复核或安全措施弥补风险 | 不能因为业务急就完全放弃标准保护 |
| 期限与迁回 | 例外必须有 owner、到期时间、迁回计划和复查节奏 | 长期例外会把技术标准掏空 |
| 标准反馈 | 高频例外要反向检验标准是否过时、过重或缺少平台支撑 | 治理不是僵化执行，标准本身也要演进 |
| 不宜随意动态化的对象 | 为什么危险 | 更合适的治理方式 |
|---|
| 核心数据语义 | 字段含义、金额口径、账务规则如果随配置变化，历史数据和审计口径会难以解释。 | 用版本化契约、迁移脚本和 ADR 管理，而不是线上随手切换。 |
| 安全边界默认值 | 认证、授权、加密、隐私遮蔽等默认值一旦被配置误改，事故面会很大。 | 默认安全写进代码和策略；例外配置走高权限审批、审计和复查。 |
| 未测试的逻辑组合 | 多个开关叠加会产生测试矩阵爆炸，线上变成未知分支。 | 限制组合数量，把关键组合纳入自动化测试、灰度验证和发布复盘。 |
| 复杂业务流程编排 | 大量流程逻辑藏进配置，短期灵活，长期会形成看不见的 DSL 和排障黑箱。 | 把流程版本显式化，配合工作流治理、变更审计和回滚方案。 |
| 决策类型 | 是否需要 ADR / 评审 | 判断理由 |
|---|
| 局部实现细节 | 通常不需要，只在代码评审里处理。 | 影响范围小、可逆、不会形成跨团队长期承诺。 |
| 服务边界、数据权威源、事件语义 | 需要 ADR，必要时评审。 | 一旦形成消费者和数据依赖，后续修改成本高。 |
| 公共平台、共享库、SDK、统一网关 | 必须评审。 | 影响多个团队，错误设计会被大范围复制。 |
| 不可逆迁移、存储选型、外部供应商锁定 | 必须评审并设置复查点。 | 退出成本高，失败后不能简单回滚。 |
| 偏离技术标准的例外 | 需要登记，重大例外需要评审。 | 例外会侵蚀标准，必须有期限、补偿控制和迁回计划。 |
| 字段 | 要写什么 | 常见失败 |
|---|
| 背景与约束 | 业务目标、系统现状、规模、可靠性、安全、成本、组织能力等约束。 | 只写“为了提升性能”，没有说明真实约束。 |
| 备选方案 | 至少列出 2-3 个可行方案，包括不做或延后。 | 只有一个方案，ADR 变成事后公告。 |
| 取舍理由 | 为什么选它，放弃了什么，哪些风险被接受。 | 只写优点，不写代价和失败条件。 |
| 影响范围 | 影响哪些服务、数据、消费者、团队、成本和运维动作。 | 只看本团队，不看上下游和运行成本。 |
| 验证与复查 | 上线后看哪些指标，什么时候复查，什么情况触发调整或回滚。 | 决策落地后无人再看，条件变化也不修正。 |
| 误区 | 为什么危险 | 修正方式 |
|---|
| 所有架构决策都要上会 | 治理成本太高，团队会绕开流程 | 只评审跨边界、高风险、不可逆和公共能力决策 |
| ADR 写成事后公告 | 没有体现取舍，无法帮助未来复盘 | 记录备选方案、约束和为什么当时这样选 |
| 用原则替代事实验证 | 原则争论容易变成观点之争 | 为关键原则配置指标、测试或架构扫描 |
| 检查项 | 最低要求 |
|---|
| 决策分级 | 明确哪些变更必须写 ADR 或进入评审 |
| 取舍记录 | 记录上下文、备选方案、放弃理由、风险和复查点 |
| 例外登记 | 例外有 owner、期限、补偿措施和回归计划 |
| 验证机制 | 关键架构约束进入 CI、测试、监控、扫描或评审节奏 |
| 知识可发现 | ADR、系统图、服务目录和运行文档能够互相跳转 |
| 评审环节 | 必须回答的问题 | 不应陷入的误区 |
|---|
| 先确认决策等级 | 这是局部实现、跨系统边界、公共能力、不可逆迁移，还是标准例外？ | 所有议题都按同一强度评审，最后让团队绕开流程 |
| 再还原上下文 | 当前业务目标、约束、规模、组织能力、已有系统债分别是什么？ | 只看目标架构图，不看为什么此时必须改变 |
| 比较备选方案 | 至少有哪些可行选项？不做、延后、局部试点是否被认真比较过？ | 把评审开成单方案宣讲会 |
| 暴露代价与失败条件 | 选中方案牺牲了什么？哪些指标或事件说明这个决策失败了？ | 只讲收益，不写代价、退出条件和回滚路径 |
| 确定落地责任 | 谁负责实现、迁移、监控、文档、复查和例外关闭？ | 会议通过后没有 owner，决策变成无人跟踪的口头共识 |
| 决策债类型 | 典型表现 | 追踪字段 | 复查触发 |
|---|
| 临时例外 | 为了赶期偏离技术标准、可靠性要求或安全基线 | owner、到期时间、补偿控制、迁回计划、剩余风险 | 到期、事故、相关系统扩容或安全审计 |
| 未验证假设 | 容量、成本、延迟、组织协作或供应商能力只是估计 | 假设内容、验证指标、数据来源、复查日期 | 上线后一到两个迭代，或指标偏离预期 |
| 不可逆承诺 | 存储选型、外部供应商、公共协议、数据权威源难以回退 | 退出成本、替代方案、锁定风险、灾备方案 | 合同续约、规模翻倍、性能瓶颈或合规变化 |
| 组织依赖 | 方案依赖某个团队长期维护公共能力或承担额外值班 | 责任团队、SLO、支持边界、升级路径、成本归属 | 团队调整、值班负荷升高、支持请求持续增加 |
| 相关页 | 连接关系 |
|---|
| 架构偿债 | 架构债往往来自没有记录、没有验证或没有复查的决策 |
| 后端工程 | 模块边界、接口风格、事务边界等后端判断需要决策机制承载 |
| 服务目录与系统地图 | ADR 要能连接到真实服务、owner、依赖和运行入口 |
| 测试与质量工程 | 适应度函数需要测试、扫描和质量门禁落地 |
| 《演进式架构》 | 提供适应度函数和持续架构演进的书页锚点 |