从决策到演进的软件架构全景

软件架构不是“画一张漂亮的技术图”，而是在业务目标、质量要求和现实约束下，对系统结构与演进路径作出一组影响深远、需要解释且可以验证的决策。

架构的三个对象

建议的三种学习模式

架构能力地图

先找出真正会改变结构的少数因素：业务目标、关键质量属性、核心领域、硬约束与最大风险。没有优先级，就没有可执行的架构。

五类架构驱动

从模糊愿望到可用驱动

系统边界：先画“外面”，再设计“里面”

架构驱动画布

业务目标：目标 / 指标 / 负责人 / 截止时间
关键用户旅程：主路径 / 失败影响 / 业务优先级
Top 3–5 质量属性：场景 + 数值目标 + 测量窗口
核心领域：关键规则 / 不变量 / 领域负责人
硬约束：法规 / 数据驻留 / 预算 / 期限 / 技术或组织限制
外部依赖：契约 / 限额 / SLA / 失败模式 / 替代方案
最大风险：概率 × 影响 × 可探测性
关键假设：怎样验证 / 最晚验证日期 / 证据
不在范围：明确排除，防止边界持续膨胀

质量属性不是形容词，而是可观察的系统行为。把它写成具体场景，才能连接到架构策略、测试方法、运行指标和业务后果。

质量属性场景：六个字段

十类常见质量属性

权衡不是缺陷，而是架构的本体

优先级：只保留真正决定结构的 Top 3–5

可使用 业务价值 × 风险暴露 × 区分度 排序。所有系统都希望“安全、稳定、快速”，但只有那些会导致不同结构决策的属性才是架构驱动。例如“结算绝不重复扣款”比泛化的“可靠”更有区分度。

属性名称：
刺激源：
刺激：
环境（正常 / 峰值 / 部分故障 / 攻击）：
受影响的系统或组件：
期望响应：
度量（分位数 / 比例 / 时间窗口 / 数据量）：
业务后果：
验证方式（测试、演练、监控、审计）：
负责人及复审日期：

架构不是瀑布阶段。它是一条反复循环的证据链：理解问题、提出假设、比较选项、记录决策、实现验证、观察结果，再修正模型。

十步轻量架构循环

决策记录（ADR）的最小结构

选项比较：定量辅助，定性负责

加权评分表适合让隐含偏好显性化，但分数不是“科学真相”。权重、证据置信度和否决项应与总分一起呈现。

风险驱动评审

大型系统可借鉴 ATAM 的思想：由不同利益相关者建立质量属性效用树，用具体场景评估方案，识别敏感点（某参数变化显著影响质量）、权衡点（同时影响多个属性）和风险主题。轻量团队可用 90 分钟工作坊完成简化版：

1. 10 分钟：目标、范围和架构概览。
2. 20 分钟：独立提出失败场景与变化场景。
3. 15 分钟：按业务影响和发生可能排序。
4. 30 分钟：逐个追踪到结构、策略、监控和证据。
5. 15 分钟：确认风险所有者、验证动作与截止时间。

ISO/IEC/IEEE 42010:2022 区分“架构”与表达它的“架构描述”，并以利益相关者、关切、视点、视图和模型组织描述。它规定应表达什么关系，但不强制某种格式或工具。[1]

先选读者和问题，再选图

C4：按抽象层级缩放

C4 还包含系统景观、动态和部署图。官方建议并非每次都画四层；对多数团队，上下文图与容器图已经能提供大部分价值。[2]

arc42：一份可裁剪的架构文档骨架

arc42 的 12 个部分是问题清单，不是要求全部写满的官样模板；按系统风险和读者需求裁剪。其官网在 2026 年提供 Version 9 及中文模板。[3]

最小可行架构文档（MVAD）

一张架构图的合格线

高内聚、低耦合不是口号。一个好边界应围绕同一业务能力共同变化，隐藏内部细节，拥有清晰契约，并允许团队在不理解整个系统的前提下安全工作。

十条可操作的架构原则

耦合不止是“是否调用”

DDD：让业务语言成为边界工具

战略 DDD决定“哪里应该不同”：子域、限界上下文、通用语言、上下文关系；战术 DDD帮助“内部如何表达”：实体、值对象、聚合、领域服务、仓储和领域事件。不要在没有战略边界时机械堆叠战术模式。

六边形、洋葱与 Clean Architecture

三者名称与分层细节不同，但共享一个目标：业务规则位于内侧，外部世界通过端口/接口接入，源代码依赖指向更稳定的内层。它们是单个部署单元内部的组织方式，不自动等于微服务。

先选能满足驱动因素的最简单结构，再让真实的团队协作、扩缩容和故障数据推动拆分。多数系统会组合多种风格，但每种风格都要有明确适用范围。

常见风格与真实代价

微软的架构风格指南同样强调：风格通过约束产生性质，每种风格都有权衡；选择应从业务驱动和质量属性开始，而不是追求“纯度”。[4]

同一原则在不同场景中的特化

微服务是否值得：四个前置条件

启发式风格顾问

这是用于学习的启发式提示，不替代质量场景、成本模型和架构评审。

拆分服务的顺序

1. 先在代码内建立模块、依赖规则和数据所有权。
2. 用遥测识别真实的变更冲突、热点、故障耦合或合规边界。
3. 为候选边界建立明确 API/事件契约和独立测试。
4. 使用绞杀者模式逐条迁移能力，保留回退路径。
5. 最后才独立部署与存储，并补齐 SLO、值班、成本与安全所有权。

分布式设计的目标不是假装网络可靠，而是让不确定性有边界：每个远程调用有时间预算，每个重复操作安全，每个异步流程可追踪、可对账、可补偿。

八个必须默认成立的事实

• 网络会失败
• 延迟不为零且会抖动
• 存在部分失败
• 时钟并不完全同步
• 消息可能重复或乱序
• 容量与队列有限
• 拓扑与版本会变化
• 遥测也可能缺失或延迟

远程调用的韧性工具箱

CAP 与 PACELC：讨论业务语义，而不是背字母

CAP关注发生网络分区时，系统无法同时保证线性一致与每个请求都成功响应；必须按操作选择倾向。PACELC进一步提醒：即使没有分区，也常在延迟（L）与一致性（C）间权衡。真正要问的是：

• 哪个业务不变量必须同步守住？例如“同一座位只能售出一次”。
• 哪些读允许陈旧，陈旧多久，用户能否看见“处理中”？
• 冲突如何检测、谁有权合并、能否补偿、是否需要人工介入？
• 分区期间是拒绝、排队、只读、有限降级，还是接受暂时分歧？

跨服务事务的选择

消息语义：Exactly-once 是端到端性质

全局有序代价高且通常不必要。优先定义按聚合/实体键有序；事件含业务键、版本或序列号，消费者检测缺口、陈旧与重复。用事件时间处理迟到数据，用水位线或窗口明确完整性。

缓存是一个数据系统

把操作主记录与派生副本分开：前者守住业务不变量，后者服务搜索、分析、推荐或 AI。每个副本同样需要所有者、血缘、新鲜度、删除传播与恢复策略。

数据生命周期控制面

按访问模式选择存储

先写访问模式、数据量、增长、读写比、一致性、延迟、保留、合规和恢复目标，再选产品。“多模型数据库”也不会消除数据建模。

OLTP 与 OLAP：一份事实，两类优化目标

数据产品卡片

名称与业务用途：
Owner / Steward / Producer / Consumer：
System of Record 与来源：
数据分类、合法依据、驻留与租户：
Schema / Data Contract / 版本与兼容策略：
血缘与 Provenance：
质量 SLO（准确、完整、一致、有效、及时、唯一、可追溯）：
访问控制、脱敏、加密与审计：
新鲜度、保留、归档、删除及下游传播：
RPO / RTO、备份恢复、重处理与对账：
成本归属、消费者清单、废弃流程：

Data Mesh：组织模型，不是买一套平台

当组织规模、领域自治和跨域数据需求不足时，Data Mesh 的协调成本可能大于收益。小团队先建立明确所有权、契约、目录与质量指标，通常比组织重构更有效。

多租户数据隔离

协议选择只是表层；真正决定长期成本的是语义、所有权、兼容性、失败行为、身份边界和变更流程。契约必须同时描述正常返回与失败、限额、幂等和废弃。

交互风格对比

契约设计的最低要求

兼容性规则

命令、事件与通知

event_id: 全局唯一，用于去重
event_type: 领域事实名称
schema_version: 契约版本
occurred_at / recorded_at: 事件时间与记录时间
source: 发布上下文与所有者
subject_id / partition_key: 业务主体与局部顺序键
correlation_id / causation_id / trace_id: 流程、因果与追踪
tenant / classification: 租户与数据分类（不放不必要敏感数据）
payload: 业务事实；只承诺契约内字段
注意：代理生成的文本、用户输入和外部数据永远不应成为可信指令。

API Gateway 与 BFF 的边界

网关适合终止 TLS、身份验证、路由、配额、协议转换和统一遥测；BFF适合为特定客户端聚合与裁剪体验。两者都不应吞下领域规则、跨域事务和所有业务编排，否则会形成“聪明管道、贫血服务”的新中心。

从托管服务、自动化和声明式基础设施获得弹性与反馈，再按业务价值决定需要多少控制。平台应成为内部产品，为团队提供安全默认值和自助“黄金路径”，而不是新的工单中心。

三大云架构框架的共同视角

三者名称略有差异，但都要求把安全、可靠、性能、运营和成本一起权衡。可持续性不只是环境议题：减少空闲、过度配置和无价值数据，也通常同时降低成本与复杂度。

Kubernetes：何时是平台，何时是负担

平台工程：平台即产品

CNCF 将内部平台定义为按用户需要整合与呈现能力的横切层，并强调“平台即产品”、一致体验、自助、降低认知负荷、可选可组合及默认安全；“最薄可行平台”往往优于自建所有底层能力。[10]

云基础与交付控制面

• 基础设施即代码：版本化、评审、自动计划与应用；检测漂移，秘密不进入代码库。
• 策略即代码：阻止公开存储、未加密、无所有者/成本标签、超权限与不可信制品等违规。
• GitOps：声明的期望状态与自动协调有助于审计和回退，但紧急流程、秘密、数据库变更仍需专门设计。
• 可观测默认：新服务无需工单即可获得统一指标、追踪、日志、告警模板和成本归属。

单区、多区与多地域

多云与可移植性的现实

“未来可能迁移”不足以支撑同时运营多云。先定义要保护的对象：数据可导出、应用可重建、身份不锁死、核心契约开放、退出时间和成本可接受。真正的多云还要支付双平台技能、联网、可观测、安全、数据一致性和故障演练成本；常见更务实做法是主云 + 可恢复数据 + 可替换边界。

成本架构（FinOps 思维）

从关键用户旅程定义 SLI 和 SLO，再用错误预算平衡交付速度与可靠性投资。高可用、备份和灾难恢复解决的是不同问题，必须分别设计、验证和演练。

SLI、SLO、SLA 与错误预算

Google SRE 将 SLO、消除琐事、监控、发布、事故响应与复盘放在同一套可靠性实践中；100% SLO 通常意味着无法承担持续变更的成本。[11]

“几个九”在 30 天窗口意味着什么

数字按 30 天计算，仅用于直觉。实际应使用成功事件比例、业务窗口或用户旅程 SLI；“不可用分钟”并非所有系统的最佳度量。

好的 SLI 从用户结果出发

可靠性分层

RTO、RPO 与灾备策略

RTO 是业务可接受的恢复时间，RPO 是可接受的数据丢失窗口。两者应按业务能力分级，包含依赖和人员，不应只写数据库参数。

监控四个黄金信号

叫醒人的告警应同时满足：紧急、用户可感知、需要立即行动。原因型指标适合诊断；症状型 SLO 燃烧率更适合寻呼。为快故障与慢消耗使用多窗口、多燃烧率策略。

事故与复盘

1. 指挥与沟通：设事故指挥、操作、沟通和记录角色；先稳定影响再找根因。
2. 时间线与影响：基于证据记录用户、业务、数据和合规影响，避免记忆重构。
3. 促成因素：设计、流程、组织、容量、依赖、变更和检测如何共同作用。
4. 无责学习：区分直接触发与系统性条件，不把“操作失误”当最终答案。
5. 行动闭环：每项行动有负责人、截止、优先级和验证；跟踪到完成并更新运行手册。

混沌与 Game Day

先写稳态假设、保护指标、实验范围、停止条件和回滚路径，再从非生产和小爆炸半径开始。测试的不只是实例重启，还应包括：依赖变慢、限额耗尽、证书过期、控制面不可用、区域隔离、消息积压、错误配置和人工接管。

不要从“加缓存、加机器”开始。先建立负载模型和延迟预算，识别排队与饱和点，再用最小改动验证瓶颈。平均值会隐藏真正伤害用户的尾延迟。

性能模型的六个量

端到端延迟预算

扩展的基本手段

缓存优化的顺序

1. 先证明慢在哪里，避免缓存错误或低频路径。
2. 定义可接受陈旧窗口和失效责任。
3. 选择缓存位置：浏览器、CDN、网关、应用、本地或数据层。
4. 设计命中率、键空间、容量、TTL、预热、穿透与击穿。
5. 故障时决定绕过、使用陈旧值还是拒绝；监控源系统回源压力。
6. 保护隐私：认证响应、租户数据和含敏感字段的缓存键不能串用。

性能测试类型

容量计划简表

当前基线：峰值需求 / 请求混合 / 数据量 / 区域 / 读写比
增长模型：业务增长 + 季节/活动系数 + 安全余量
单实例实测能力：满足目标分位数与错误率时的吞吐
故障容量：失去一个节点/区/地域后，剩余容量仍满足哪一级目标
扩容滞后：指标采集 + 决策 + 启动 + 预热总时间
有界资源：连接、线程、队列、文件、内存、磁盘、配额、下游限额
单位成本：每 1,000 请求 / 订单 / GB / AI 任务
触发点：何时扩容、分片、归档、重构或改变产品策略

从资产、威胁、信任边界和业务影响开始，用最小权限、分层防御和可验证控制降低风险。安全架构要同时保护运行系统与“生产软件的系统”——源代码、依赖、构建、制品和发布渠道。

NIST CSF 2.0：六个持续职能

CSF 2.0 于 2024 年正式发布，新增 Govern 并强化供应链治理；可用 Current/Target Profile 表达当前与目标状态，而不是把 Tier 当成认证分数。[12]

威胁建模：围绕数据流和信任边界

零信任不是“买一套产品”

NIST SP 800-207 的核心是保护资源而非隐式信任网络位置；用户、设备和工作负载持续认证与授权。云原生补充 SP 800-207A 强调应用/服务身份与细粒度策略。[13]

• 默认拒绝；最小权限、短时凭据、MFA、工作负载身份与 mTLS。
• 高风险动作重新评估上下文并 step-up；授权不能只在登录时发生一次。
• 单独保护策略系统、身份源与遥测；验证其故障时是 fail-safe 还是有限降级。
• 微分段限制横向移动，但不能替代应用内对象、字段和业务动作授权。

NIST SP 1800-35 已于 2025 年正式发布，给出 19 个基于商用技术的零信任参考实现与经验，可用于从原则进入实施验证。[29]

身份、授权与秘密

应用安全基线：Top 10 不是验收标准

OWASP Top 10:2025 是风险意识文档；ASVS 5.0.0（2025 年发布）才提供可测试的 Web 应用安全控制基线。引用 ASVS 要带完整版本化控制 ID，例如 v5.0.0-x.y.z。[14][15]

软件供应链：三个问题、三类证据

供应链工程基线

• 受保护分支、MFA、最小权限；关键变更双人评审，仓库与 CI 审计可追踪。
• 依赖、工具和基础镜像按 digest/hash 固定，禁止仅依赖可变标签。
• 构建使用短生命周期隔离环境，CI 秘密最小化；制品不可变、可吊销、可回滚。
• 每次发布生成并绑定 SBOM、签名 provenance；部署入口验证受信构建器和策略。
• 自动关联资产、漏洞情报与 VEX；第三方组件有准入、升级、淘汰和应急替换计划。

NIST SSDF 1.1 是安全软件开发实践基线；SLSA 当前批准版为 v1.2。CycloneDX 当前规范 1.7 可表达组件、服务、依赖、漏洞、构建、ML 模型等供应链信息。[16][17][18]

隐私工程

• 明确用途和合法依据；只采集完成用途所需的最少数据。
• 数据分类驱动访问、加密、脱敏、保留、驻留和审计。
• 将删除传播到缓存、搜索、分析、副本、备份策略与向量索引；记录例外。
• 尽量使用匿名化、假名化、令牌化和聚合；评估重识别风险。
• 为访问、更正、导出、删除和申诉设计可操作流程，不靠临时脚本。

资产 / 业务动作：
威胁主体与场景：
信任边界与数据分类：
预防控制：
检测与审计证据：
响应、遏制与恢复：
控制失败时的安全行为：
验证方法（测试、演练、审计、监控）：
剩余风险、接受人、复审日期：

本章用于架构学习，不替代适用地区、行业和组织的法律、合规或专业安全评估。

把反馈做快，把批量做小，把证据自动化。持续交付不是“每天上线”，而是系统始终处于可部署状态，任何变更都能以低风险按需发布。

一条可信的交付供应链

发布策略

测试组合：按风险建立证据

可观测性：从未知问题推断内部状态

OpenTelemetry 提供厂商中立的追踪、指标、日志和上下文传播模型；它解决采集与语义互操作，不替你决定什么值得测、如何告警和保留多久。[19]

DORA 已从“四项”演进为五项指标

DORA 当前明确使用“吞吐 + 不稳定性”的五指标模型，并指出速度与稳定性通常不是对立面。[20]

架构适应度函数示例

架构治理的最小闭环是：原则与安全默认值 → 轻量决策记录 → 自动护栏 → 风险分级评审 → 运行反馈 → 例外到期。它服务交付与风险，而不是服务文档数量。

从“关卡”到“护栏”

团队是架构的一部分

• 一个运行单元必须有明确团队所有者、SLO、值班和成本责任。
• 共享库、数据库和平台能力也需要产品式所有权与弃用机制。
• 依赖图应能映射到团队；频繁跨团队协调是边界或平台问题的信号。
• 避免“架构师决定、团队接单”；决策者应与实现和运行后果保持接近。

架构治理资产

企业架构与解决方案架构如何衔接

企业架构关注跨组织的业务、数据、应用与技术组合及迁移路线；解决方案/软件架构关注具体系统和工作负载。TOGAF 10th Edition 可用于组织企业架构能力与 ADM 迭代，但不应把项目文档变成全量 TOGAF 制品。[21]

技术债：描述后果，不只描述“代码不好”

ID / 标题 / 所有者：
产生背景与当时决策：
当前症状与证据：
受影响的业务、质量场景、团队和数据：
利息：每次变更延迟 / 事故 / 额外成本 / 安全暴露
触发器：达到什么条件必须处理
选项：偿还 / 降低 / 隔离 / 接受 / 淘汰
预估成本、优先级、目标日期：
完成与验证标准：

遗留系统现代化：按能力和风险切片

绞杀者式演进

AI 应用不是“模型 API + Prompt”。它包含数据、检索、策略、编排、工具、输出验证、人工监督、评估和运行控制；模型输入与输出都应视为不可信数据。

生产级 AI 应用参考结构

AI 系统的质量属性

RAG 的离线与在线两条管道

评估体系（Evals）

可重建一次回答需要记录：模型和参数、Prompt 模板、策略版本、embedding/index/data 版本、检索 chunk ID/score/ACL、工具请求/响应、验证决定和 trace；同时对敏感内容脱敏并限制访问。

RAG / Agent 威胁与控制

OWASP LLM/GenAI Top 10 2025 覆盖 Prompt Injection、敏感信息、供应链、投毒、输出处理、过度代理权、系统提示泄露、向量/嵌入弱点、错误信息与无界消耗；它是威胁意识基线，不替代完整威胁模型。[22]

Agentic AI 的确定性护栏

任何 Prompt、系统提示或模型 guardrail 都不是授权机制。即使模型“承诺不做”，高影响控制也必须由模型外的身份、策略、参数验证和执行层强制。

NIST AI RMF：治理贯穿全生命周期

NIST AI RMF 1.0 当前仍是正式基线但正在修订；NIST AI 600-1 是生成式 AI 的正式配套 Profile，强调风险治理、内容来源、上线前测试与事件披露。[23][24]

AI 项目应记录的 ADR

• 为什么此用例适合 AI；哪些结果不能交给概率系统。
• 模型/供应商选择、路由与退出路径；数据是否被用于训练。
• RAG、微调或纯提示的选择；知识源、ACL、刷新与删除。
• 质量、安全、公平、延迟和成本门槛；评估集与批准人。
• 工具权限、人工确认、失败降级、审计、事故与 Kill Switch。
• Prompt、模型、数据、索引和评估版本如何关联与回滚。

场景：为多个零售品牌提供商品浏览、购物车、促销、库存预占、订单和支付编排。团队从 12 人增长到 4 个价值流团队；先在单地域多可用区运行，并保留区域灾备路径。

架构驱动（假设数据）

• 核心不变量：同一幂等键只创建一个订单；支付结果可对账；库存预占有过期和补偿。
• 降级：推荐、评价、个性化失败不影响浏览和结算；促销故障可使用已验证快照或关闭新优惠。
• 约束：团队初期没有 7×24 平台能力；支付由外部机构完成；租户数据必须逻辑隔离并审计。
• 最大风险：大促热点、第三方支付不确定结果、优惠规则复杂度、库存与订单最终一致。

阶段 A：先做清晰的模块化单体

为什么不直接微服务：领域边界和促销规则仍在探索，四个团队尚未形成，跨服务一致性与平台成本会延缓市场验证。模块通过代码可见性、架构测试、独立 Schema 和端口隔离，避免退化成“大泥球”。

阶段 B：先扩读路径和异步工作

阶段 C：用触发器决定是否提取服务

关键 ADR 示例

上线前故障场景

完整软件架构文档骨架

# 0. 文档控制与阅读指南
- 文档 ID、版本、状态、日期、作者、评审人、责任团队
- 适用系统/版本/环境、变更记录、源仓库与自动生成入口
- 目标读者、各角色阅读路径、图例与术语约定

# 1. 关注实体、目标与范围
- 业务使命、成功指标、关键用户旅程
- 系统职责 / 非目标 / 范围边界 / 假设
- 利益相关者、关切、影响力、期望和验收责任

# 2. 架构驱动与约束
- Top 3–5 质量目标及场景
- 核心领域、不变量、关键数据与信任边界
- 法规、组织、预算、期限、遗留、技术、驻留约束
- 风险、假设、验证动作与最晚决策时间

# 3. 系统上下文
- C4 System Context / Landscape
- 外部用户、系统、设备、组织及所有权
- 业务与技术接口、数据流、SLA、限额、失败行为

# 4. 解决方案策略
- 顶层架构风格、领域分解、数据与集成策略
- 质量属性策略、部署拓扑、关键技术与组织策略
- 选择理由、主要取舍及 ADR 链接

# 5. 静态结构 / 构建块
- C4 Container（必选）与必要的 Component
- 每块的职责、技术、API/事件、数据所有权、团队所有权
- 依赖方向、允许/禁止关系、版本与生命周期

# 6. 运行时视图
- 关键正常路径、异常路径、过载、恢复和管理场景
- 同步/异步、事务、幂等、顺序、超时、重试、降级、补偿、对账
- 序列图或动态 C4；每个场景关联 SLI/SLO

# 7. 部署与运行视图
- 环境、账号/项目、区域/可用区、网络/信任边界
- 软件到运行节点映射、扩缩容、故障域、容量和成本归属
- 配置、秘密、证书、备份、RTO/RPO、灾备与恢复演练

# 8. 数据架构
- System of Record、派生数据、Schema、血缘与数据契约
- 分类、授权、加密、保留、驻留、删除传播、质量 SLO
- 批/流、CDC、重放、对账、分区、主数据与多租户策略

# 9. API / 事件与集成
- OpenAPI / AsyncAPI / IDL、错误与幂等语义
- 身份、授权、配额、版本、兼容、废弃和消费者清单
- 外部依赖防腐层、失败隔离与退出路径

# 10. 横切质量概念
- 安全、可靠性、性能、可观测、测试、交付、可访问性
- 缓存、时间、错误处理、国际化、审计、供应链和 FinOps
- 每项：目标 → 策略 → 证据 → 所有者

# 11. AI / ML（如适用）
- 用例适配、数据/模型/Prompt/索引/工具架构
- Evals、风险、权限、人审、漂移、成本、回退与 Kill Switch

# 12. 架构决策
- ADR 索引：Proposed / Accepted / Deprecated / Superseded
- 重要、昂贵、难逆、跨边界和高风险决定的完整理由

# 13. 质量要求与验证
- 质量树、场景、优先级、验收和生产指标
- 架构适应度函数、性能/安全/恢复/混沌测试

# 14. 风险、技术债和开放问题
- 概率、影响、证据、缓解、剩余风险、接受人、截止与触发器

# 15. 演进路线与治理
- 当前 → 过渡 → 目标状态；里程碑、依赖、回退和成功指标
- 团队边界、评审级别、例外、标准路径、弃用和现代化策略

# 16. 跨视图追溯
利益相关者关切 → 质量场景 → 视图/元素 → ADR
→ 测试/监控证据 → 风险/行动项

# 17. 词汇表与权威参考

ADR 模板

标题：用主动语态写清决定
状态：Proposed / Accepted / Deprecated / Superseded by ADR-…
日期 / 作者 / 决策者 / 参与者：

## 背景
什么问题要求现在决定？业务目标、质量场景、约束和证据是什么？
保持中立，不在背景中偷放结论。

## 决策驱动与评价标准
- 必须满足：
- 希望优化：
- 不在范围：

## 可行选项
0. 不改变 / 延迟决定
1. 方案 A：收益、代价、风险、证据、可逆性
2. 方案 B：收益、代价、风险、证据、可逆性

## 决定
我们将……（范围、负责人、生效日期）
选择理由；未选方案的主要理由。

## 后果
- 正面：
- 负面：
- 中性 / 新责任：
- 受影响系统、数据、契约、团队、成本与运行：

## 验证与跟进
原型 / 测试 / SLO / 成本 / 安全证据：
行动项、负责人、截止：
重审触发器与最晚复审日期：
相关 / 替代 ADR 与文档链接：

架构评审清单

生产就绪检查清单

C4 图审查速查

C4 官方提供更完整的架构图评审清单，可作为团队标准的起点。[25]

90 分钟架构评审议程

12 周实践路线

毕业项目评分表

建议书目：按问题读，不按厚度读

图书可能已有新版本或中文译本，购买/借阅时以出版社最新目录为准。本手册优先引用可在线核对的一手标准和项目文档。

版本锚点（资料核对日：2026-07-30）

权威参考资料

以下链接均为标准组织、项目官方站或原始方法来源。技术与标准会继续演进，实际项目采用前请再次确认版本和适用范围。

核心术语表

ADR

架构决策记录，保存背景、决定、状态与后果。

架构驱动

会显著改变结构的业务、质量、约束和风险因素。

视点 / 视图

视点是构建某类表达的约定；视图是针对具体系统的实例。

限界上下文

一套领域模型和通用语言保持一致的语义边界。

聚合

维护业务不变量的事务一致性边界。

模块化单体

单一部署单元，但内部模块有强边界和隐藏实现。

最终一致性

在没有新更新时，副本经过一段时间收敛；业务需容忍中间状态。

幂等

同一逻辑操作重复执行不会产生额外业务效果。

Saga

用一系列本地事务和业务补偿实现长事务。

Outbox

业务状态与待发布消息在同一本地事务中写入的模式。

CDC

捕获数据库变更并传播到下游的机制。

背压

消费者把容量信号反馈给生产者，以限制过载。

熔断

依赖连续失败时暂时快速失败，并周期探测恢复。

舱壁

隔离资源和故障，限制爆炸半径。

SLI / SLO / SLA

指标 / 目标 / 带后果的服务协议。

错误预算

由 SLO 允许的失败空间，用于平衡变化与可靠性。

RTO / RPO

可接受恢复时间 / 可接受数据丢失窗口。

可观测性

从系统输出推断内部状态、包括未知问题的能力。

适应度函数

持续验证架构特性是否仍满足意图的自动或人工检查。

平台工程

把共享能力作为内部产品，以自助和安全默认值降低认知负荷。

GitOps

以版本化声明状态和自动协调管理运行环境的方式。

零信任

不因网络位置隐式信任，每次访问按身份、资源和上下文评估。

SBOM

软件物料清单，描述制品包含的组件和依赖。

Provenance

制品来源与构建过程的可验证元数据。

System of Record

对某项事实具有最终判定权的主记录系统。

数据产品

有所有者、契约、质量、可发现性和生命周期的数据能力。

RAG

检索增强生成，用外部证据构造模型上下文。

Eval

用于度量 AI 组件或端到端任务质量、安全、延迟和成本的评估。

Prompt Injection

不可信输入操纵模型偏离预期指令或泄露/执行未授权行为。

技术债

过去决策在未来变更、风险和运行中持续产生的额外成本。