【系统架构设计】架构的不变量：穿越技术周期的设计原则

Part XIV 从 AI 原生架构 谈到 多租户隔离，技术名词换了一轮：LLM 推理网关、边缘 Worker、Wasm 组件、Shopify Pod。若只记名词，很容易得出「旧原则已过时」的印象——微服务被 Serverless 取代，强一致被最终一致取代，监控被可观测性取代。

这种印象有一半对、一半错。对的一半：部署单元、数据平面产品、交互协议确实在演进；错的一半：演进并没有取消物理与数学约束。网络仍会分区，磁盘仍会坏，线程仍会阻塞，团队沟通结构仍会映射到模块边界。Peter Deutsch 等人在 1994 年归纳的分布式计算谬误（Fallacies of Distributed Computing）——网络可靠、延迟为零、带宽无限、拓扑不变、中间没有攻击者——在 2026 年仍被新系统反复「重新发现」。

本文不是「架构师必备十则心法」式的清单。每一条不变量都要能指回本系列已写篇章里的具体机制、故障模式或设计权衡，并标明它不承诺什么（例如：不变量不等于「永远用微服务」）。读完 Part I–XIV 的读者，可以把本文当作收束索引：用不变量检验新方案，而不是用新方案否定旧约束。

系列导航： 上一篇：多租户架构 · 下一篇：【系统架构设计】防御性架构：用系统设计约束 AI 犯错（待写）

相关专题： 康威定律 · SLO 工程 · 混沌工程 · Shopify Pod 案例 · 可观测性工程索引 · 容器隔离强度

一、问题：为什么需要「不变量」而不是「最佳实践」

1.1 技术周期与架构时尚的轮换

过去二十年里，行业默认答案至少经历了四轮明显轮换：

1. 2000 年代中后期：垂直扩展 + 关系型单体 + 会话粘滞；
2. 2010 年代：微服务 + 容器 + 最终一致 + 领域驱动拆分；
3. 2020 年代初：Serverless / 边缘计算 + 事件驱动 + 湖仓一体；
4. 2024 年起：AI 原生运行时——LLM 作为非确定性依赖、RAG 管线、Agent 编排。

每一轮都有真实的工程收益，也都有被事后证明过度泛化的教条。「微服务一定比单体好」「最终一致一定够用」「Kubernetes 等于云原生」——这些句子省略了前提，因此在不同团队、不同阶段会得出相反结论。本系列 《什么是软件架构》 与 《架构质量属性》 反复强调：架构是在冲突的质量属性之间做可追溯的 trade-off，不是选型题的标准答案。

不变量回答的是另一类问题：无论当前默认答案是什么，哪些约束如果忽视，系统会在 6–18 个月内以事故、成本或组织摩擦的形式「补课」？

1.2 不变量 vs 模式 vs 产品

三者容易混用，边界如下：

把不变量当成「永远用 X 技术」是误读。正确用法是：当引入 X 时，不变量帮你列出必须显式设计的检查项——例如上 Kubernetes 并不取消尾延迟放大，只是把故障域从进程换成 Pod。

1.3 本文边界

• 会写：与系列前文一一对应的八条核心不变量、一条「范式迁移」对照、开放问题与自检清单。
• 不写：重复 Part IV–VII 全文；不替代 《数据密集型应用架构》 对 Lakehouse 的专题讨论。
• 证据等级：机制结论优先链本系列已发文章；跨周期断言链经典文献或 A 级工程材料（Google 论文、SRE 书、DDIA），不编造引文。

1.4 与 Part I 思维基础的关系

01 什么是架构 把架构定义为关键 design decisions；03 ADR 要求决策可追溯。不变量清单是 ADR 的约束语言——不是替代 ADR，而是提供「每条决策必须回应哪些问题」的公共词汇。若 ADR 只记录「选用 Kafka」而不记录「一致性选点、失败语义、lag SLI」，则决策在 operation 阶段不可验证。

04 架构评估 ATAM 的 trade-off 分析可与第十二节自检合并使用：ATAM 识别 quality attribute 冲突；不变量清单确保分布式环境下冲突不会被「云厂商默认配置」悄悄决议。

二、不变量地图

下面这张图不是架构蓝图，而是约束之间的依赖关系：上层设计若违反下层不变量，上层无法长期成立。

graph TB
    subgraph Org["Organizational layer"]
        CONWAY["Conway / team boundaries"]
    end

    subgraph Observe["Observability prerequisite"]
        OBS["Metrics / Logs / Traces / SLO"]
    end

    subgraph Control["Feedback & capacity"]
        CAPFB["Capacity planning"]
        AUTOS["Autoscaling control loop"]
    end

    subgraph Runtime["Failure & isolation"]
        FAIL["Failures are normal"]
        ISO["Isolation & blast radius"]
    end

    subgraph Data["Time & consistency"]
        LAT["Latency budget & tail"]
        CONS["Consistency spectrum"]
    end

    CONWAY --> ISO
    OBS --> CAPFB
    OBS --> AUTOS
    OBS --> LAT
    CAPFB --> AUTOS
    FAIL --> ISO
    LAT --> CONS
    ISO --> FAIL
    AUTOS --> LAT

图 1：架构不变量依赖关系——可观测性支撑容量与延迟管理；失败假设驱动隔离设计；一致性选择受延迟预算约束；组织边界影响隔离能否落地。

2.1 读图的三个例子

例 A：跳过观测直接上 HPA
没有 66 指标 与 28 SLO，22 HPA 只能基于默认 CPU——控制环稳定性的论证缺少数据基础，属于图中 OBS → AUTOS 边被剪断。

例 B：微服务拆分无舱壁
09 微服务 增加 fan-out，若未实施 24 舱壁，FAIL → ISO 路径不成立：单点慢依赖通过共享连接池扩散（26 酒店案例）。

例 C：多租户共享库无配额
99 多租户 逻辑隔离若缺少 25 限流 与 cgroup（72），CONWAY → ISO 仅停留在文档：组织承诺了隔离，runtime 未 enforce。

读图方式：例如你在设计 AI 原生推理链，若未建立 SLI/SLO（28），则延迟预算无法分配，一致性降级（缓存旧上下文 vs 实时检索）也无法量化讨论——这不是「监控没做」，而是后续不变量全部失去度量基础。

三、不变量一：失败是常态，可用性是统计量

3.1 从「尽量避免故障」到「假设故障并限制损害」

《高可用设计模式》 开篇的两个支付系统案例说明同一命题：冗余部署不等于高可用。备节点切换、脑裂（Split-Brain）、Fencing、仲裁——这些机制处理的是故障必然发生前提下的状态机，而不是「把 MTBF 做到无穷大」。

Michael Nygard 在 Release It!（2nd ed., 2018）中把稳定性模式（断路器、舱壁、超时）与反模式（无界队列、级联超时）对照讲解；书中案例来自生产事故，核心信息不是「某模式名称」，而是：单点故障与级联故障是默认路径，除非你用架构把它改写成可控降级。

Google SRE 一书在「Managing Incidents」与「Addressing Cascading Failures」等章节中同样预设：大规模系统每周都会有需要人工或自动化介入的事件；追求的目标是在给定错误预算（Error Budget）内交付功能，而非零故障。

3.2 出站、入站与业务层：三层防护链

本系列 Part IV 用五篇连写把「失败常态」拆成可实现的机制层：

25 与 24 的分工值得反复核对：熔断保护调用方，限流保护被调用方。「下游全健康但被热点打挂」不是熔断能解决的——这是不变量「失败是常态」的扩展含义：过载与错误一样，都是常态压力而非例外。

26 引用 Google SRE 关于 degraded mode 的表述：降级必须预先工程化，且要能区分可降级流量。没有 fallback 的熔断器，只是把异常从「慢」换成「快失败」——用户仍看到 502，只是更快看到。

3.3 混沌工程：把假设变成可证伪实验

《混沌工程》 引用 principlesofchaos.org 的五条原则：稳态假设、真实世界事件、生产（或类生产）环境、自动化、最小爆炸半径。Netflix 在 2011 年 AWS 美东故障中相对可用的经验，常被误读为「随机杀进程就好」——该文强调的核心是：在受控半径内持续证伪「我们以为能扛住」的假设。

这与 23 的 HA 模式形成闭环：HA 设计给出故障时的期望行为；混沌实验验证实际行为是否匹配期望。不做后者，HA 文档与运行 reality 之间的裂缝只能在真实大故障中暴露。

3.4 不变量表述与常见误用

不变量（精确表述）：任何规模的生产系统，在足够长的时间窗口内，必然经历组件故障、依赖超时、人为变更失误与流量异常；架构必须显式定义检测、 containment、恢复与用户可见语义。

常见误用：

• 把「五个 9」理解成「不会故障」——23 的可用性表说明 4 个 9 仍允许每年约 52 分钟不可用，且 MTTR 必须自动化。
• 堆叠重试而不做幂等（50 幂等性）——24 的重试风暴分析给出 \(r^n\) 放大公式。
• 只做冗余不做隔离——92 Shopify Pod 的 with_each_shard 危机说明：共享控制面对多 shard 迭代会把局部故障扩成全局故障。

3.5 分布式谬误与本系列映射

Fallacies of Distributed Computing 八条在现代架构中的「复活方式」如下——每条都可在本系列找到对应篇章，而非抽象道德训诫：

Kleppmann DDIA 第八章 “The Trouble with Distributed Systems” 与上述列表在问题域上高度重叠：不可靠网络、不可靠时钟、进程暂停——23 HA 的 Fencing 与 50 幂等 处理的正是「消息可能重复、顺序可能乱」这一组合。

3.6 容灾与 HA 的边界

27 容灾架构 讨论 RPO/RTO、多活与备份——与 23 的组件级 HA 互补。不变量：HA 缩短 MTTR；DR 应对关联失败（整个 region、整个云控制面）。86 Netflix 在区域故障上的实践与 30 混沌 的 Chaos Kong 级实验，是把「region 也会挂」纳入常态假设的实例；若只做双机热备而不做跨 region 演练，HA 文档覆盖的事件空间是不完整的。

3.7 幂等与「至少一次」世界

Google SRE 一书在 “Handling Overload” 与 “Addressing Cascading Failures” 中给出负载脱落（load shedding）与 graceful degradation 的工程化要求——与 25 的算法层、26 的业务层形成对照。SRE 手册强调：过载时返回 fast failure 优于 slow success，因为排队深度 \(L\) 与等待时间 \(W\) 在 Little 定律下互相放大（29）。

Nygard Release It! 中的 Stability Anti-patterns（无界队列、集成点超时缺失、级联失败）可逐项映射到本系列：

3.8 主动验证 vs 被动祈祷

30 混沌工程 与 71 故障排查 构成「实验—事故—复盘」闭环。不变量：未在实验中观察到的 failure mode，在生产中出现的概率与时间无关，只与复杂度单调增相关（与 05 复杂性管理 的论述一致）。

四、不变量二：延迟有预算，尾部决定体验

4.1 平均值撒谎：Fan-out 与 Tail at Scale

《延迟分析》 用搜索服务 30 分片 fan-out 说明：单分片 P99 100ms 时，整请求至少一分片命中尾部的概率约为 \(1 - 0.99^{30} \approx 26\%\)。Jeff Dean 与 Luiz André Barroso 在 Communications of the ACM 2013 年发表的 “The Tail at Scale” 系统阐述同一数学事实：大规模并行下，尾延迟 dominate 用户体验，优化 P50 对 SLO 贡献有限。

这不是「性能优化技巧」，而是架构不变量：只要存在 fan-out（微服务调用链、分布式查询、MapReduce shuffle、LLM 多路检索），就必须为链路分配端到端延迟预算，并在预算内分配各 hop 的上界。

4.2 SLO：把延迟预算变成可仲裁的契约

《SLO 工程》 将 SLI/SLO/Error Budget 定义为产品、研发、SRE 的共同语言。对延迟不变量而言，关键不是「监控 P99」，而是：

1. 选定用户可感知的 SLI（如「搜索 API 成功响应且延迟 < 300ms」）；
2. 设定窗口与目标（30 天 99.9%）；
3. 用燃烧率告警在预算耗尽前触发变更冻结或降级（链 26）。

没有 SLO，延迟优化缺少停手条件——这与 Google SRE 关于「无限追求可靠性成本无限」的论点一致。

4.3 扩缩容滞后是延迟问题，不是「机器不够」

《弹性伸缩》 把 HPA 建模为带观测、决策、执行延迟的反馈控制环。大促复盘案例表明：新 Pod Ready 之前，队列已堆积；CPU 因线程阻塞不升反降，触发错误缩容——控制环延迟 + 错误指标 = 振荡，直接体现为用户侧尾延迟尖刺。

这与 29 容量规划 形成分工：容量模型回答「稳态与峰值需要多少资源」；扩缩容回答「多快把供给对齐到需求」；两者都解决不了「下游连接池不随 Pod 扩展」——那是隔离与配额不变量（见第六节）。

Little 定律 \(L = \lambda W\)（29）在直觉上连接延迟与队列：到达率 \(\lambda\) 上升而服务时间 \(W\) 因过载上升，系统中在途请求 \(L\) 爆炸——表现为尾延迟恶化。扩缩容若只增 \(\lambda\) 处理能力而不减 \(W\)（例如 DB 锁竞争），定律不变。

4.4 延迟预算分解表（示意）

表内百分比仅为设计对话起点，非 universal 常数；AI 原生链路中 LLM 首 token 延迟可能独占 60% 以上（见 95），预算表必须重写，但「必须分解预算」这一不变量不变。

4.5 协调省略（Coordinated Omission）与测量失真

32 讨论的协调省略陷阱属于观测不变量的子问题：若压测客户端在等待慢响应期间暂停发送新请求，测得的 P99 会系统性偏低——你会「优化」一个并不存在的 tail。全链路压测（37）与生产 trace（67 分布式追踪）必须分离「负载生成语义」与「用户真实并发模型」。否则容量（29）与 SLO（28）都建立在错误分布上。

4.6 对冲请求与尾延迟策略的代价

Dean & Barroso 讨论的 hedged requests、tied requests 等策略在 32 中有工程化展开：用额外负载换 tail 裁剪。不变量表述：任何 tail 优化都增加平均资源消耗或放大下游 QPS——必须与 25 限流 和 29 容量 联算，否则 tail 优化在峰值日成为过载入口。

4.7 连接池与排队：隐藏的延迟预算吞噬者

21 连接池设计 与 22 弹性伸缩 的联动说明：线程在等连接时，延迟预算消耗在「无业务进展的等待」上，且 HPA 可能读不到真实压力。延迟不变量要求把池等待时间纳入 SLI 或至少纳入 saturation 指标（USE 模型中的 Utilization/Saturation/Errors，见 observability 03）。

五、不变量三：一致性是谱系，不是「强或弱」二选一

5.1 CAP：分区下的权衡框架，不是 slogan

Eric Brewer 在 2000 年 PODC keynote 提出 CAP；2002 年 Computer 杂志文章 “CAP Twelve Years Later: How the ‘Rules’ Have Changed” 澄清：在分区（Partition）发生时，必须在一致性（Consistency）与可用性（Availability）之间取舍——不是三种属性任意时刻只能选两个的简单口诀。

Martin Kleppmann 在 Designing Data-Intensive Applications（O’Reilly, 2017）第七章进一步区分：线性一致（Linearizability）、顺序一致、因果一致、最终一致在语义与成本上不可混谈。本系列 45 应用层一致性模式 从 Saga、TCC、Outbox 出发，说明微服务下跨库原子性 often 被替换为可补偿的最终一致——这不是「偷懒」，而是在 2PC 的阻塞与可用性代价（文中有 FLP 相关讨论）之间的显式选择。

5.2 应用层模式：在谱系上选点

45 的核心对比：

不变量：不存在「免费强一致」；每条业务链路都要在谱系上标注可接受的不一致窗口，并设计用户可见语义（26 与 50）。

5.3 Spanner 与 Google：谱系上的极端点仍有假设

《Google 基础设施》 分析 Spanner（Corbett et al., OSDI 2012）：TrueTime 用 GPS/原子钟约束时钟不确定界，在全球范围提供外部一致（Externally Consistent）事务。这是谱系上的强一致端点，但假设包括：专用硬件与时间基础设施、可接受的 commit 延迟、跨大陆 WAN RTT——与多数 SaaS 团队默认栈不同。

同文讨论 Borg 调度与 Colossus 演进，说明 Google 内部也长期并存最终一致路径（早期 Bigtable）与强一致路径（Spanner/F1）——「一种一致性打天下」从来不是其基础设施叙事。

98 数据密集型架构 从 Lambda/Kappa 批流分裂谈到 Lakehouse，强调分析链路与 serving 链路对一致性与新鲜度（Freshness）要求不同——Freshness 作为 SLI 类型在 28 表中已有列位。

5.4 PACELC 与工程默认

Daniel Abadi 提出的 PACELC 扩展：即使没有 Partition，也常在 Latency 与 Consistency 间取舍。这与 32 尾延迟讨论直接耦合——读自己的写（read-your-writes）往往足够，但实现成本仍低于全局线性一致。

开放争论（有文献）：跨云多活（27 容灾、77 多云）中，同步复制 stretch cluster 与异步复制 + 冲突解决（CRDT、last-write-wins）谁更可控——取决于 RPO/RTO 与合规，无 universally 最优（参见 Kleppmann 关于 CRDT 与 DDIA 第九章讨论）。

5.5 读路径与写路径可以处于谱系不同点

11 CQRS 与 57 CQRS+ES 实战 的架构哲学是：写模型与读模型不必同强度一致。读侧接受秒级 lag（Freshness SLI），写侧在单聚合内保持 ACID——这是谱系思想在单 bounded context 内的应用，而非「全面最终一致」。

17 缓存架构 中的 cache-aside、write-through 选型同样是在读新鲜度 vs 写路径复杂度之间选点；缓存击穿场景（25 开篇）说明：一致性与过载在热点下同时失效——两条不变量耦合。

5.6 时钟、顺序与 Spanner 之外的世界

Spanner 依赖 TrueTime 界定 commit wait 窗口（Corbett et al., OSDI 2012）。多数团队使用 NTP/LPT 同步的逻辑时钟或版本向量（DDIA 第七章）。不变量：没有全局完美时钟时，因果顺序（happens-before）比「wall clock 对齐」更可靠——41 流处理 的水位线（Watermark）与 10 事件驱动 的事件顺序讨论，都是这一约束在数据管道中的体现。

5.7 与 98 批流一体的交叉：双写是一致性的债务

98 数据密集型架构 指出 Lambda 架构维护批视图与实时视图的双轨成本——本质是两个读模型 + 合并逻辑的一致性问题。Lakehouse 与统一引擎试图把谱系上的两个点合并为一个存储，但新鲜度 vs 查询语义仍未消失，只是从「两套代码」变成「一套引擎内的 trade-off 参数」。

5.8 FLP 与「Consensus 不是免费午餐」

Fischer、Lynch、Paterson 1985 年证明：在异步网络中，若允许进程崩溃，不存在确定性的 consensus 算法能在有限步内终止（FLP impossibility）。45 在 2PC/3PC 讨论中引用这一背景：强一致协调协议在分区与崩溃同时出现时必然面临不可判定窗口——工程上靠超时、Fencing、人工介入（23 HA）打破纯异步假设，而非假装 FLP 不存在。

Raft/Paxos 族算法（DDIA 第九章；88 微信案例 PaxosStore）通过 partial synchrony 假设（ eventually 存在足够长的同步窗口）获得实践可用性——这是「不变量 + 显式假设」的范例：共识可行，但延迟与运维复杂度是谱系上的代价。

5.9 Netflix 与可用性优先选点

86 Netflix 在 CAP 叙事中选择 AP 并向用户显式暴露 stale 数据（如「继续观看」列表短暂不一致）——说明产品可接受的不一致窗口是业务决策，不是数据库默认值。架构文档应记录该窗口，而非仅写「用 Cassandra 所以最终一致」。

六、不变量四：隔离界定爆炸半径

6.1 爆炸半径（Blast Radius）的定义

爆炸半径：单点故障或单租户异常所能影响的最大范围——多少用户、多少服务、多少数据分区。不变量：共享组件越多，默认爆炸半径越大；隔离是缩小半径的 deliberate 成本。

6.2 Shopify Pod：运行时隔离 vs 代码模块化

《Shopify 架构》 提供当代多租户样本（依据 Shopify Engineering 公开材料）：

• 2015 垂直扩展触顶 → 数据库分片；
• 2016 with_each_shard 放大故障 → Pod 完全隔离（独立 MySQL/Redis/memcached）；
• 2017+ Packwerk 模块化单体 → 代码边界与 Pod 边界正交。

Sorting Hat 在边缘把请求绑定到单一 Pod，避免跨 shard 事务；超大商户可独占 Pod（Shop Mover）。这与 99 多租户架构 讨论的隔离层（逻辑 / 进程 / 命名空间 / 数据面）形成对照：Shopify 选的是数据面硬隔离 + 无状态 Worker 共享的混合。

6.3 多租户：吵闹邻居与公平性

99（Part XIV）系统讨论 SaaS 隔离：租户键、配额、Noisy Neighbor、合规域（PCI/HIPAA）。不变量：逻辑隔离（row-level tenant_id）在负载与故障上仍是软隔离——除非配合 rate limit（25）、资源配额（cgroup/K8s limits）或物理分片（Pod/Cell 模型，参见 90 Google 的 cell 思想）。

6.4 容器与 OS：隔离强度可核对

《容器架构》 说明 namespace 提供视图隔离而非完整安全边界；生产需叠加 seccomp、AppArmor、非 root、只读根文件系统。更完整的威胁模型见 《容器隔离的真实强度》——容器 ≠ 虚拟机是不变量，Kubernetes Pod 共享内核（73）进一步意味着：Pod 级隔离低于 VM 级，Node 级 compromise 影响面上界更大。

30 混沌工程 的「最小爆炸半径」原则与隔离设计一致：实验从单 Pod、单 AZ、单租户开始——因为验证隔离是否有效与设计隔离同等重要。

6.5 舱壁：进程内隔离

24 的 Bulkhead 模式与 26 的 Nygard 酒店案例：共享线程池让无关功能耦合——逻辑模块独立 ≠ 资源隔离。不变量在单体内同样成立，Shopify 用 Packwerk 解决代码耦合，用 Pod 解决数据耦合，用 Semian 等做 Ruby 层熔断——多层隔离叠加。

6.6 Kubernetes 命名空间不是租户隔离

73 Kubernetes 架构 中 Namespace 是软多租户——共享控制面、默认共享 Node 内核。生产级租户隔离常需 Cell 架构（90 Google）、独立集群或至少 node pool + NetworkPolicy + quota 组合（99）。把 Namespace 当安全边界违反隔离不变量，在合规审计中会直接失败。

6.7 服务网格与 Sidecar：隔离的 tax

76 服务网格 通过 Sidecar 注入 mTLS 与策略，增加的是流量路径上的隔离与可观测性，不是计算隔离——Sidecar 自身成为共享故障域（资源、升级、配置错误）。不变量：每增加一层中间件，就要更新爆炸半径分析与 30 混沌 实验矩阵。

6.8 零信任与边界消失

61 零信任 与 90 Google BeyondCorp 说明：网络边界隔离让位于身份与设备态——隔离维度从 VLAN 迁移到 policy engine（60 授权架构）。不变量「缩小半径」仍在，只是半径的度量坐标从 IP 换成 principal + resource + context。

七、不变量五：容量与扩缩是反馈控制，不是线性「加机器」

7.1 容量规划：先建模，再扩缩

《容量规划》 用 Little 定律、M/M/c 排队模型、USL 扩展性定律说明：瓶颈常在非 obvious 组件（连接池、锁、元数据服务）。「去年 100 台，今年 200 台」不是规划，是赌博。

全链路压测（37）与 89 阿里双十一 等案例表明：容量验证必须覆盖依赖链最窄处，而非应用 CPU。

7.2 自动扩缩：控制环稳定性

22 详细拆解 HPA 公式、VPA 冲突、KEDA 事件驱动与缩容 stabilization window。不变量：

1. 指标必须映射真实瓶颈（CPU 误导案例）；
2. 执行延迟导致过冲/振荡；
3. 下游硬上限不随副本数扩展（DB max_connections、21 连接池）。

当扩缩跟不上（冷启动、镜像拉取、JVM 预热），必须靠 25 限流 与 26 降级 兜底——这是控制论中的饱和执行器（saturated actuator）场景。

7.3 错误预算驱动变更速率

28 的 Error Budget 把可靠性变成可消耗资源：预算充足时可加速发布（69 部署架构）；预算燃烧过快则冻结功能、优先修复。容量不足常表现为 SLO 燃烧——容量与可靠性在同一反馈环，不应拆成两个团队各说各话。

7.4 Amdahl 与 USL：扩展的上界公式

29 容量规划 给出的 Amdahl 与 USL 公式是不变量数学表述：

\[ \text{Speedup} \leq \frac{1}{(1-P) + P/N} \]

\[ C(N) = \frac{N}{1 + \alpha(N-1) + \beta N(N-1)} \]

其中 \(P\) 为可并行比例，\(N\) 为节点数，\(\alpha\) 为串扰、\(\beta\) 为协调开销。无论 15 扩展性原理 讨论水平扩展还是 14 空间架构 的内存网格，存在串行段与协调开销则扩展曲线必弯曲——「再加机器」不能绕过公式，只能移动瓶颈（often 到数据库或全局协调服务）。

7.5 静态容量 vs 动态扩缩：何时不需要 HPA

22 开篇的教训也适用于反向情况：若负载可预测（批处理窗口、合同 SLA 峰值已知），29 的静态水位线 + 预 provisioning 比动态扩缩更稳、更便宜——反馈控制不是唯一解，是不确定负载下的解。不变量：你必须 explicit 选择「预容量」还是「跟容量」，并说明切换条件。

7.6 Serverless 的冷启动是执行延迟

74 Serverless 把扩缩粒度推到函数级，但冷启动与并发上限把执行延迟重新引入尾延迟（第四节）与隔离（第六节）：多租户共享运行时下的 Noisy Neighbor 以 cold start 尖刺形式出现。Serverless 没有取消控制环，只是把环路的执行段外包给云 vendor。

八、不变量六：组织结构与系统结构同构

8.1 康威定律：观察，不是建议

《康威定律》 引用 Melvin Conway 1968 年 Datamation 论文原句：组织沟通结构会被复制到系统设计。MacCormack 等 Harvard 2008 实证与 Microsoft Vista 研究（同文）支持紧耦合组织 → 紧耦合代码。

不变量：你不能长期维持与组织沟通图严重背离的架构，除非投入持续 tax（Platform 团队、API 治理、81 架构治理）抵消同构力。

8.2 逆康威与团队拓扑

84 讨论 Inverse Conway Maneuver：先 desired 架构，再调整团队边界（Team Topologies 的 Stream-aligned / Platform / Complicated-subsystem / Enabling）。与 58 DDD 与微服务、79 单体到微服务 交叉：服务拆分若超越团队沟通带宽，会得到分布式单体。

Shopify 选择模块化单体（92）而非百个微服务，与组织规模、部署频率、Packwerk enforcement 能力一致——这是逆康威在「减少分布式 tax」方向的实例，不是否定微服务。

8.3 与 Part XV 的衔接

Part XV 101 防御性架构（待写）将讨论 AI 生成代码时的边界——组织上谁对跨模块变更负责，同样受康威约束：若 Agent 可改全库而无模块 Owner，架构边界会被快速冲垮。

8.4 案例：Netflix、Amazon 与组织-架构对齐

86 Netflix 架构 的微服务拆分与 Chaos 文化同构：小团队 owning 小服务，才有权限在生产注入故障（30）。85 Twitter/X 的反面教材是长期存在「组织墙与系统墙不对齐」时的集成 tax。87 Uber 的领域拆分与 53 DDD 战略 讨论相互参照——限界上下文只有在团队 boundary 匹配时才是 runtime boundary。

78 平台工程 是逆康威的 institutional 形式：Platform 团队提供 paved road，减少 Stream 团队重复造轮子——但若 Platform 与业务 roadmap 脱节，会变成新的集中式 bottleneck（康威推论三：沟通路径 \(\binom{n}{2}\) 增长）。

8.5 架构治理：对抗同构漂移的 tax

81 架构治理 与 83 架构师工具箱 提供 ADR、ATAM（04 架构评估）、C4（06 架构文档）——这些不是官僚 paperwork，而是显式记录「我们想抵抗哪种同构漂移」。不变量：没有 governance tax，系统结构会向组织默认沟通图漂移（84 推论四）。

九、不变量七：可观测性是先决条件，不是事后补丁

9.1 「无法改善无法观测的系统」

本系列 Part X（65 日志、66 指标、67 追踪）与独立的 可观测性工程系列（25 篇，2026-06 完成）共同强调：现代系统需要 Metrics、Logs、Traces、Profiles、Events 五类信号协同，才能从「P99 抖了」定位到「哪条 span、哪行代码」。

不变量：没有 SLI 定义与采集，前面六条不变量都无法 operationalize：

• 失败常态 → 需要错误率、饱和度、排队深度；
• 延迟预算 → 需要 histogram 与 trace 分解；
• 一致性 → 需要复制 lag、outbox 积压；
• 隔离 → 需要 per-tenant/per-cell 指标；
• 容量 → 需要 USE/RED（observability 03）；
• 组织 → 需要变更事件与 ownership 标签（13 Events）。

9.2 告警与事故响应闭环

68 告警策略 与 71 故障排查 说明：告警应基于 SLO 燃烧率而非静态阈值（28）。混沌实验（30）的稳态假设必须来自同一套指标——否则实验无法判定回归。

9.3 轻量入口

若读者未系统读过可观测性系列，最低限度应读：

1. 可观测性全景；
2. OpenTelemetry 深入；
3. SLO 工程：错误预算与燃烧率告警（与 architecture 28 互补）。

9.4 三大支柱与架构 Part X 的分工

architecture 篇侧重架构决策与系统拓扑；observability 篇侧重协议、存储与成本。不变量要求两者同时存在——仅有架构图而无 SLI 定义，04 ATAM 的风险分析无法量化。

9.5 基数爆炸与可观测性自身成为故障源

66 指标架构 与 observability 04 埋点哲学 讨论高基数 label 如何拖垮 TSDB——观测系统也是生产系统，可能触发 25 过载 同类雪崩。设计 trace/log 采样（observability 10 Traces）不是省钱技巧，是防止观测反噬被观测系统的不变量推论。

9.6 变更关联：Events 与发布

69 部署架构、70 特性开关 与 observability 13 Events 串联：SLO 燃烧时，第一问题是「刚发布了什么」——无变更事件关联的 metrics 只能告诉你不正常，不能告诉你是谁不正常。

十、什么变、什么不变：从单体到 AI 原生

10.1 部署范式迁移对照

变的：打包方式、调度器、计费模型、默认中间件。不变的：上表右列对应的不变量检查项——AI 原生只是把「下游依赖」换成「非确定性 LLM + 向量库」，尾延迟、过载、降级、隔离、观测仍必须显式设计（95 专论此点）。

10.2 微服务不是终点，也不是原罪

79 单体到微服务 与 92 Shopify 共同说明：拆分时机取决于变更耦合、部署频率、团队边界，而非行业 marketing。不变量不要求「回退单体」或「全面微服务」，要求无论哪种形态，都应对照第三节至第九节的检查项。

10.3 数据密集型演进与不变量

98 记录 Lakehouse、流批一体——技术栈变，但 Freshness vs Correctness、双写一致性、Schema 演进（44）仍在谱系框架内。Lambda 双轨维护成本爆炸是组织与工程复杂度不变量的案例，不是「批流一体赢麻了」的口号。

10.4 质量属性框架：不变量的上层坐标

02 架构质量属性 列出性能、可用、安全、可修改性等冲突维度——本文八条不变量可视为这些质量属性在分布式环境下的不可省略子约束：

05 复杂性管理 指出：复杂性是状态与依赖的函数——不变量不是增加复杂性，而是标记不可假装不存在的复杂性。

10.5 事件驱动与 AI Agent：新的 fan-out 形状

10 事件驱动架构 与 57 CQRS+ES 把 fan-out 从 sync RPC 挪到 async 消费——尾延迟从「最慢同步 callee」变成「消费 lag + 重放风暴」（19 消息队列）。AI Agent 把 fan-out 挪到 tool call 图：每个 tool 是一次 RPC，LLM 一次推理可能触发并行工具调用——95 应在第四节延迟预算框架下设计，而非单独发明「Agent 延迟」指标。

10.6 边缘与中心：一致性与延迟的地理维度

94 Cloudflare 与 20 CDN 架构 把静态与部分动态逻辑下沉——不变量：边缘节点失效、回源、配置传播延迟（49 配置管理）都是失败与延迟在地理维度的实例；边缘不是「免运维」，是把爆炸半径切到 PoP 尺度。96 边缘计算架构 进一步讨论本地状态、离线可用与中心一致性的张力——与第五节一致性谱系直接相连。

10.7 Wasm、容器与 VM：隔离光谱上的不同点

97 WebAssembly 架构 与 72 容器架构 代表隔离光谱上两个新点：

不变量：选运行时是在选隔离强度与启动延迟的 trade-off，不是选「更现代」。Wasm 缩短 cold start 往往以 syscall 面与调试复杂度为代价；容器提供完整 Linux ABI 但以共享内核为假设——os 容器安全 说明该假设在 multi-tenant hostile 场景下必须加固。

十一、开放问题：不变量帮不上忙的地方

不变量列出必须处理的约束，不消除尚未有共识的研究与工程前沿：

1. 跨 region 线性一致的可负担边界
   Spanner 式 TrueTime 对多数团队不可复制；异步多活 + CRDT 的业务语义仍常需产品层解释。参见 Kleppmann CRDT 批评与反驳（DDIA 与后续 blog），以及 27 的 RPO/RTO 框架。

2. AI 输出的正确性 SLI
   传统 SLI（可用、延迟）不足以描述 hallucination rate、tool call 安全失败率。95 与 Part XV 101–104 将展开；当前无 industry-wide A 级标准，评测集与在线 guardrail 仍在快速迭代。

3. 平台工程与开发者体验的量化
   78 平台工程 讨论 Internal Developer Platform，但「平台团队 ROI」缺少像 SLO 一样统一的 SLI——DORA 指标与 SPACE 框架（B 级）可借鉴，不能当物理定律。

4. 能耗与碳约束作为一等质量属性
   02 质量属性 已列性能与成本；大规模 AI 推理使能耗进入架构 trade-off，但缺少与延迟/成本同等的成熟度量实践（开放，见 OSDI/SOSP 近年 energy-aware scheduling 方向）。

5. 供应链与 provenance
   62 API 安全 触及依赖风险；SBOM、签名 attestation 与架构边界的交叉仍快速演化，不变量「隔离」需扩展到构建与发布链路（Part XV 102 待写）。

6. 形式化验证与 AI 生成代码的规模
   对小内核或可验证协议，TLA+ 等方法可证明不变量子集；对百万行 CRUD+业务规则系统，全面证明不现实（101 防御性架构 待写）。开放问题是：哪些边界（类型系统、契约测试、51 契约测试）能以可接受成本 enforce 不变量，而非依赖人工 review。

7. 全局最优 vs 局部最优的组织激励
   84 康威定律 说明结构同构，但不回答「谁为跨团队 externality 买单」——platform、SRE、安全团队常被期望 enforce 全局不变量，却缺少与 product team 对齐的 error budget 或 KPI。Team Topologies 的 Enabling 团队模式是一种组织解，但是否 scalable 仍依赖具体组织（B 级工程经验，非形式化定理）。

十二、如何使用本清单：架构评审与 ADR

12.1 八项自检（非打分表）

对任何重大变更（新区域、新租户模型、新 LLM 链路、新 mesh），逐项回答：

1. 失败：单点失效时期望行为是什么？是否在 30 或 GameDay 中验证过？
2. 延迟：端到端预算多少？fan-out 节点各是多少？P99 SLI 定义了吗（28）？
3. 一致：在 CAP/PACELC 谱系的哪一点？不一致窗口谁可见？
4. 隔离：故障/热点影响多少租户/服务？与 99 模型是否一致？
5. 容量：瓶颈组件建模了吗（29）？扩缩指标是否对齐瓶颈（22）？
6. 组织：谁 ownership？是否触发康威漂移（84）？
7. 观测：新路径有 trace/metric/log 吗？告警是否基于 SLO？
8. 降级：过载时关什么、谁决定、用户看到什么（26）？

任一项答「未设计」，不是「以后补」，而是已知技术债——应写入 ADR 的 Consequences。

12.2 ADR 模板字段建议

在 《架构决策与 ADR》 基础上，增加 Invariants touched 字段，列出本条决策加强或削弱了哪些不变量——便于 80 技术债 量化与复盘（71）。

12.3 与新范式文章的关系

• 读 95 AI 原生 前：用第三节（失败）、第四节（延迟）、第六节（隔离）打底；
• 读 99 多租户 后：用第六节与第八节对照自身租户模型；
• 进入 Part XV：把不变量当作对 AI 生成代码的约束语言（101 防御性架构 待写）。

12.4 评审场景示例（简表）

12.5 与遗留系统现代化

82 遗留系统现代化 与 80 技术债 常问「先还哪笔债」——不变量清单提供优先级启发：无观测（第七节）则其他优化不可验证；无过载保护（25）则迁移期更易被流量打穿；无隔离（第六节）则 modernization 试点会拖累生产全局。

12.6 全系列阅读路径（Part XIV 收束）

若从本文反向进入系列，可按 invariant 回溯：

1. 可靠性链：23 → 24 → 25 → 26 → 28 → 30
2. 性能链：31 → 32 → 29 → 22
3. 数据链：45 → 98 → 90
4. 组织链：84 → 79 → 92 → 99

12.7 不变量冲突时的仲裁顺序

当不变量彼此冲突（典型：强一致 vs 低延迟 vs 高可用），建议仲裁顺序：

1. 用户安全与合规（63、PCI 域）— 不可降级；
2. 核心路径可用（26 定义的 Tier-0 功能）— 可降级非核心；
3. SLO 与错误预算（28）— 量化剩余空间；
4. 一致性与新鲜度（45）— 在预算内选谱系点；
5. 成本与复杂度（05）— 避免为边缘 case 引入全局复杂度。

该顺序不是定理，是本系列多篇事故复盘归纳的工程启发——团队应写入 ADR 并根据 domain 调整。

12.8 检查清单的「失败定义」

自检项通过的标准应是可观测信号存在，而非「我们讨论过」：

• 有 documented steady-state metrics（混沌原则一，30）；
• 有 per-hop timeout 配置且之和 ≤ 端到端预算（24）；
• 有 per-tenant 或 per-cell 饱和度指标（99）；
• 有至少一次 GameDay 或 automated chaos 记录（30）。

缺任一项，在 04 ATAM 语义下属于 known risk accepted，必须在 ADR 的 Consequences 段显式出现。

十三、小结：穿越周期的是约束，不是名片

回顾 Part I–XIV：从 质量属性 到 Shopify Pod，从 Borg/Spanner 到 多租户，具体模式层出不穷，但以下八条在证据意义上稳定：

1. 失败是常态——HA、弹性、限流、降级、混沌是同一前提的不同切面（23–26、30）。
2. 延迟有预算，尾部定体验——fan-out 与扩缩滞后放大 tail（32、22、28）。
3. 一致性是谱系——2PC、Saga、Spanner 是不同假设下的选点（45、90、Kleppmann DDIA）。
4. 隔离界定爆炸半径——Pod、容器、舱壁、租户配额（92、72、99）。
5. 容量与扩缩是反馈控制——Little 定律 + 控制环延迟（29、22）。
6. 组织与架构同构——康威定律 + 逆康威（84）。
7. 可观测性是先决条件——无 SLI 则无 SLO、无混沌稳态、无容量验证（observability 系列）。
8. 范式变，约束不变——单体、微服务、边缘、AI 原生换外壳，检查项不换（07、09、95）。

技术周期会再换名：今天的「Agent 编排」像昨天的「服务网格」，今天的「RAG」像昨天的「CQRS 读模型」。架构师的工作不是预测下一个名词，而是在每个名词落地时，把上述约束翻译成可测试、可观测、可追责的设计。

13.1 安全与隐私：横切不变量

本文未单列「安全不变量」，因 Part IX 安全架构 整 Part 可视为隔离与失败不变量的特殊化：

• 59 认证 / 60 授权：principal 边界是逻辑隔离；
• 63 加密 / 64 密钥：密钥泄露的爆炸半径需最小化（与第六节同构）；
• 61 零信任：否定「内网即可信」——与 Fallacy「单一安全边界」同源。

失败不变量的安全推论：auth 服务 outage 不应拖垮已认证会话的读路径（degraded authz vs hard fail 的 product 决策，见 26）。

13.2 Part XIV 篇目之间的阅读顺序

Part XIV 前沿五篇（95–100）建议顺序：

1. 95 AI 原生 — 新运行时依赖；
2. 96 边缘计算 — 地理维度的隔离与一致；
3. 97 Wasm — 沙箱隔离的新形态；
4. 98 数据密集型 — 数据平面演进；
5. 99 多租户 — SaaS 隔离综合；
6. 100 不变量（本文） — 收束为检查清单。

读完 100 再进入 Part XV，不变量应成为防御性架构（101）的输入约束，而非被 AI 辅助编程绕过的「老派规矩」。

Part XIV 在此收束。下一篇进入 Part XV：防御性架构——当代码 increasingly 由 AI 生成，如何用类型、契约与权限边界把不变量 enforced 到实现层（101，待写）。

参考资料

规范与经典定义

1. Peter Deutsch et al., “Eight Fallacies of Distributed Computing,” 1994–1997. https://www.rgoarchitects.com/Files/fallacies.pdf
2. Eric A. Brewer, “CAP Twelve Years Later: How the ‘Rules’ Have Changed,” Computer, vol. 45, no. 2, 2012.
3. Eric A. Brewer, keynote at PODC 2000 (CAP 原始表述); 参见 Brewer 2012 文对分区的强调。
4. Melvin E. Conway, “How Do Committees Invent?”, Datamation, vol. 14, no. 4, April 1968.
5. Jeff Dean, Luiz André Barroso, “The Tail at Scale,” Communications of the ACM, vol. 56, no. 2, February 2013.

书籍与工程手册

6. Martin Kleppmann, Designing Data-Intensive Applications, O’Reilly Media, 2017.
7. Michael T. Nygard, Release It! Design and Deploy Production-Ready Software, 2nd ed., Pragmatic Bookshelf, 2018.
8. Betsy Beyer et al., Site Reliability Engineering, O’Reilly Media, 2016 — 尤其第 22 章 cascading failures、第 27 章 SLO、Handling Overload 相关章节。
9. Niall Richard Murphy et al., Site Reliability Workbook, O’Reilly Media, 2018 — SLO 实施与错误预算实践。

论文与系统（A 级案例）

10. James C. Corbett et al., “Spanner: Google’s Globally-Distributed Database,” OSDI, 2012.
11. Michael J. Fischer, Nancy A. Lynch, Michael S. Paterson, “Impossibility of Distributed Consensus with One Faulty Process,” JACM, vol. 32, no. 2, April 1985 — FLP 不可能性；与 45 2PC 讨论相关。
12. Alan MacCormack et al., “Exploring the Duality between Product and Organizational Architectures,” Harvard Business School, 2008.
13. Brendan Burns et al., “Borg, Omega, and Kubernetes,” Communications of the ACM, vol. 59, no. 5, May 2016.
14. Matt Welsh, David Culler, Eric Brewer, “SEDA: An Architecture for Well-Conditioned, Scalable Internet Services,” ACM SOSP, 2001 — 与 25 限流 分阶段准入对照。

混沌工程

14. Principles of Chaos Engineering. https://principlesofchaos.org/

本系列相关篇章（按 Part）

15. Part IV 可靠性：23–30
16. Part V 性能：32
17. Part VI 数据：45、98
18. Part X 可观测：65–67；可观测性工程索引
19. Part XII 组织：84
20. Part XIII–XIV 案例与前沿：90、92、99、95

操作系统与隔离

21. 容器隔离的真实强度

本系列 Part XIV 前沿篇

22. 95 AI 原生架构
23. 96 边缘计算架构
24. 97 WebAssembly 架构
25. 99 多租户架构

上一篇：多租户架构

下一篇：【系统架构设计】防御性架构：用系统设计约束 AI 犯错（待写）