83.1 术语表
一句话
术语表不是词典,是一份防歧义清单:只收两种词——同一个词在不同人嘴里指两件不同的事,以及说错一句话就暴露没做过的词;每条给一句定义 + 最容易混的那个邻居。
怎么用这份表(三条纪律)
| 纪律 | 具体做法 | 违反的后果 |
|---|---|---|
| 只解释「在本体系里的意思」 | 定义绑定到它所在的那一层(L0–L5 / 应用层),不追求百科全解 | 术语变成正确但无用的废话 |
| 定义必须能被反例检验 | 每条都能答出「什么不是它」 | 说不出反例 = 没定义,只是背了词 |
| 首次出现给英文,后文只留一个写法 | 例:幂等 (idempotency),后文统一写「幂等」 | 同一概念三种译名,读者以为是三个东西 |
🔑 判断一个术语是否真的懂了,只问一句:「它和它隔壁那个词,差在哪?」 差在哪说不出来,就是没懂。
先看这张:十个最容易说错的词
这十条每一届评审、每一轮面试都会有人踩。先记住正确说法,再往下看分组表。
| 常见说法 | 错在哪 | 正确说法 |
|---|---|---|
| 「CAP 三选二」 | P(分区)不是可选项,是网络的事实;分区发生时才在 C 与 A 之间取舍 | 「分区发生时,在一致性 (C) 与可用性 (A) 之间选一个;没分区时在延迟 (L) 与一致性 (C) 之间选一个」——这就是 PACELC |
| 「ZooKeeper 是强一致」 | 它只保证写线性一致 + 客户端 FIFO 顺序;读可能陈旧 | 「写走 ZAB 多数派提交,读默认读本地副本;要新鲜读先 sync()」 |
| 「Kafka 保证 exactly-once」 | 只在 Kafka 自己的「读-处理-写」链路 + 事务内成立 | 「Kafka 事务保证不重复生产/不丢;跨出 Kafka 的下游副作用仍要幂等」 |
| 「上了微服务就高可用」 | 微服务把 1 个故障点变成 N 个,故障面变大 | 「可用性来自冗余 + 隔离 + 快速失败;微服务只让隔离变便宜,不自动带来可用性」 |
| 「最终一致就是不一致」 | 最终一致是带收敛承诺的模型,缺的是时间界,不是承诺 | 「最终一致 = 停止写入后必然收敛;工程上要补一个可观测的收敛时间界(秒/分钟),没有界才是 bug」 |
| 「幂等就是加唯一索引」 | 唯一索引只是去重的一种实现;幂等是语义(同一次请求执行 N 次 == 执行 1 次) | 「先定去重键,再选实现:唯一索引 / 状态机前置校验 / 去重表 / 幂等 token」 |
| 「SLO 就是我们对客户的承诺」 | 对客户的法律/商务承诺是 SLA;SLO 是内部目标,错误预算是它的预算化 | 「SLA 对外(违约赔钱),SLO 对内(决定发布节奏),SLI 是度量本身」 |
| 「P99 降了,用户体验就好了」 | 平均值与 P99 会同时「好看」而 P99.9 恶化;长尾由少数请求决定 | 「先定长尾目标(P99.9 / P999),再谈均值;一次重试就可能把 1% 的请求变成 2 倍延迟」 |
| 「RAG 就是向量检索」 | 向量检索只是召回的一种;RAG 是「切分 → 召回 → 重排 → 拼上下文 → 生成 → 引用」的整条链路 | 「RAG 的瓶颈通常在切分与重排,不在向量库本身」 |
| 「Agent 就是会调工具的 LLM」 | 调工具只是 function calling;Agent 必须有「目标 → 计划 → 执行 → 观测 → 终止/重试」闭环 | 「没有终止条件与状态管理的,叫 tool calling;有闭环与预算的,才叫 Agent」 |
⚠️ 注意最后三条是 2024 年之后才进入架构评审的词。它们的共同点是:传统术语的直觉会误导你(见本节末尾的映射表)。
一、架构与需求(第 1–4 章、第 79–80 章)
| 术语 | 一句话说清 | 别混成 |
|---|---|---|
| 架构 | 一组难以撤销的决策:它决定了后面哪些改动便宜、哪些改动昂贵 | ≠ 架构图;图是表达,决策才是实体 |
| 质量属性 (quality attribute) | 能用数字验收的非功能要求:延迟、可用性、成本、可维护性 | ≠ 「性能好」这种形容词;不可度量就不是质量属性 |
| 非功能性需求 (NFR) | 系统「做到什么程度」,与「做什么」相对 | ≠ 技术方案;NFR 是约束,方案是满足约束的手段 |
| 约束 (constraint) | 不能谈判的前提:合规、预算、存量系统、团队规模 | ≠ 需求;约束通常没有优先级,只有「必须」 |
| 取舍 (trade-off) | 提升 A 必然损害 B 的那个点;说不出被损害的是什么,就不是取舍,是许愿 | ≠ 优化;优化是「同样代价做得更好」 |
| ADR (架构决策记录) | 一页纸:背景 / 选项 / 决定 / 后果,按编号归档 | ≠ 设计文档;ADR 记「为什么」,设计文档记「是什么」 |
| 技术债 | 为了短期收益而主动接受的未来成本;关键是记账(本金 + 利息 + 还款计划) | ≠ 代码烂;无意识的烂代码是缺陷,不是债 |
| 演进式架构 | 把「架构会变」写进设计:留接缝、留开关、留版本 | ≠ 不做设计;它要求更明确地定义「哪里稳定、哪里可变」 |
| 康威定律 | 系统结构会复制组织的沟通结构 | ≠ 组织决定架构;逆康威是主动用架构目标去改组织,见 74.1 康威定律及其逆定律 |
| 认知负荷 | 一个人同时要装进脑子的概念数量上限;团队边界应按它切 | ≠ 工作量;活多可以加班,概念多只能减 |
| 技术雷达 | 四象限(技术/工具/平台/语言)× 四环(采纳/试验/评估/暂缓)的有时效清单 | ≠ 技术榜单;雷达的价值在「谁在什么时候把它挪了一环」 |
| Make / Buy / Reuse | 自建、采购、复用存量三条路的成本比较,含退出成本 | ≠ 开源 vs 商业;开源也要算维护与人力 |
| 单位经济 (unit economics) | 每笔订单 / 每个租户 / 每次调用的收入与成本 | ≠ 总成本;总量会掩盖单笔亏损 |
| ATAM | 用「质量属性场景」逼出架构风险与权衡点的评审方法 | ≠ 代码评审;ATAM 评审的是决策,不是实现 |
二、L0 运行时底座(第 5–15 章)
| 术语 | 一句话说清 | 别混成 |
|---|---|---|
| 虚拟化 | 用软件造出「假硬件」,让多个 OS 以为自己独占一台机器 | ≠ 容器;VM 虚拟硬件,容器隔离进程,见 6.1 容器与虚拟机的本质差异 |
| Hypervisor | 管虚拟机的薄层:Type 1 直接跑在硬件上,Type 2 跑在宿主 OS 上 | ≠ 容器运行时;runc 不虚拟硬件 |
| 容器 | 用内核的 namespace(看得见什么)+ cgroup(能用多少)隔离出来的进程 | ≠ 轻量虚拟机;共用宿主内核,内核漏洞即逃逸面 |
| 镜像层 (layer) | 镜像由只读层叠加而成,改一层只传一层 | ≠ 快照;层是构建产物,快照是运行态数据 |
| OCI 标准 | 镜像格式 + 运行时规范的行业契约,让「构建」与「运行」解耦 | ≠ Docker;Docker 是 OCI 的一个实现 |
| 容器运行时 | 真正把镜像跑成进程的组件:高层 containerd,低层 runc | ≠ 编排;运行时管单机,编排管集群 |
| Pod | K8s 的最小调度单位:一个或几个共享网络与存储的容器 | ≠ 容器;Pod 是调度与生命周期的边界 |
| 声明式 API | 你只提交「期望状态」,控制器负责把它变成现实 | ≠ 脚本式;脚本描述步骤,声明式描述结果,见 7.1 声明式 API 与控制器模式 |
| 控制器循环 (reconcile) | 观测实际状态 → 与期望比对 → 执行动作 的死循环 | ≠ 事件处理;它必须能「无事件也收敛」 |
| CRD / Operator | CRD 扩对象类型,Operator = CRD + 带领域知识的控制器 | ≠ 自定义脚本;Operator 的核心是幂等收敛,不是装软件 |
| QoS 等级 | Guaranteed / Burstable / BestEffort,决定 OOM 时先杀谁 | ≠ 优先级抢占;QoS 管驱逐顺序,PriorityClass 管调度顺序 |
| CNI | 容器网络接口规范:谁负责给 Pod 分配 IP、连通、做策略 | ≠ Service;CNI 管 Pod 网络,Service 管虚拟 IP 与负载均衡 |
| Service Mesh | 把「重试/超时/熔断/mTLS/遥测」从代码搬到 Sidecar 或节点代理 | ≠ API 网关;Mesh 管东西向(服务间),网关管南北向(入站),见 47.1 反向代理 |
| Sidecar | 与业务容器同 Pod 部署的辅助进程,共享网络命名空间 | ≠ 边车模式万能;每跳多两次代理,延迟与资源要算账 |
| Serverless / FaaS | 只付调用时间、不管理实例;代价是冷启动与状态受限 | ≠ 容器;见 5.1 服务模型 |
| 冷启动 | 从「零实例」到「能处理第一个请求」的时间 | ≠ 启动时间;含调度、拉镜像、初始化运行时、预热 |
| 不可变基础设施 | 机器/镜像只替换不修改,任何变更都产出新版本 | ≠ 不用改配置;配置必须外置注入 |
| IaC (基础设施即代码) | 用声明式代码描述资源,靠 plan/diff 保证可审阅 | ≠ 自动化脚本;IaC 的核心是状态文件 + 差异计算 |
| 配置漂移 (drift) | 线上实际状态与代码声明不一致 | ≠ 配置错误;漂移是「有人手工改了」的痕迹 |
| GitOps | 以 Git 为唯一事实源,集群内 agent 持续把实际状态拉回 Git 声明 | ≠ CI/CD;GitOps 是持续拉取,不是一次性推送 |
| eBPF | 把受验证的小程序挂到内核钩子上,做观测/网络/安全,不写内核模块 | ≠ 内核模块;eBPF 有验证器,崩溃面小得多 |
| 零拷贝 | 让数据在内核与用户态之间少搬几次(sendfile / splice / mmap) | ≠ 不拷贝;协议头解析、加密仍要碰数据 |
| IO 多路复用 | 一个线程等多个 fd 的就绪事件(select/poll/epoll) | ≠ 异步 IO;就绪通知不等于数据已拷贝完,见 11.4 epoll 与 IO 多路复用 |
| 协程 (goroutine) | 用户态调度的轻量执行单元,栈按需增长 | ≠ 线程;协程阻塞系统调用时仍要占用线程(Go 用 M:N 调度缓解) |
| 微虚拟机 (microVM) | Firecracker / gVisor / Kata 这类「有硬件级隔离、启动毫秒级」的沙箱 | ≠ 容器;它给的是更强的隔离边界,代价是兼容性与启动开销 |
三、L1 分布式原理(第 16–25 章)
| 术语 | 一句话说清 | 别混成 |
|---|---|---|
| CAP | 分区发生时,只能在「保持一致性」与「保持可用」之间选一个 | ≠ 「三选二」;P 是既定事实,见本节开头第 1 条 |
| PACELC | 有分区时选 A/C;无分区时在延迟 (L) 与一致性 (C) 之间选 | ≠ CAP 的替代;它补上了「平时」的取舍 |
| BASE | 基本可用 + 软状态 + 最终一致,是「放弃强一致换可用」的工程纲领 | ≠ 一种协议;它是目标集合,不是实现 |
| 线性一致性 (linearizability) | 每个操作在自己的调用与返回之间原子生效,且符合实时先后 | ≠ 严格一致;后者要求全局物理时钟,不可实现,见 16.2 线性一致性 |
| 顺序一致性 | 所有进程看到同一个全局顺序,但不必符合实时先后 | ≠ 线性一致;少了「实时」这一约束 |
| 因果一致性 | 只保证有因果关系的操作顺序,并发操作可各看各的 | ≠ 最终一致;它保因果,最终一致连因果都可能违反 |
| 最终一致性 | 停止写入后,所有副本终将收敛到同一值 | ≠ 「可能永远不一致」;缺时间界才是缺陷,见 16.5 最终一致性 |
| 会话保证 | 读己之写 / 单调读 / 单调写 / 写后读,四类单客户端保证 | ≠ 全局一致;它只对同一个会话成立,见 16.6 会话保证 |
| happened-before | 「a 一定在 b 之前」的偏序关系:同进程先后、发收消息、可传递 | ≠ 时间先后;它不依赖物理时钟 |
| Lamport 时钟 | 一个单调计数器,保证 a → b ⇒ C(a) < C(b),但反向不成立 | ≠ 向量时钟;它测不出并发 |
| 向量时钟 | 每个节点一个维度,能判定「因果在前 / 并发」 | ≠ 全序;并发就是并发,不能强行排序 |
| HLC (混合逻辑时钟) | 物理时间 + 逻辑计数,接近真实时间且保因果 | ≠ TrueTime;HLC 不提供「时间不确定区间」 |
| Quorum | 多数派集合;W + R > N 才能保证读到的写集合有交集 | ≠ 多数派选举;quorum 管读写交集,选举管唯一 leader |
| 共识 (consensus) | 多个节点对「一个值」达成不可反悔的一致 | ≠ 复制;复制是实现共识的手段之一 |
| Raft | 强 leader + 日志复制 + 任期号,把 Paxos 拆成三个可懂的子问题 | ≠ Paxos 的替代品;两者等价,Raft 胜在可教学可工程化 |
| Leader 租约 (lease) | leader 在租约期内有权决策,避免每次写都问多数派 | ≠ 选举;租约是省 RTT 的优化,代价是时钟假设 |
| Fencing token | 单调递增的令牌,让「旧 leader 的迟到写」被存储层拒绝 | ≠ 分布式锁;锁防并发,fencing 防过期持有者 |
| 脑裂 (split-brain) | 分区后出现两个都自认 leader 的节点,同时写 | ≠ 单点故障;脑裂的伤害是双写,不是不可用 |
| 半同步复制 | 至少 1 个副本确认即返回,兼顾延迟与不丢 | ≠ 强同步;落后副本仍可能丢最后一段 |
| 复制延迟 | 主库已提交、从库尚未应用的那段时间 | ≠ 网络延迟;主要是回放速度与并发冲突 |
| 一致性哈希 | 把节点与 key 映射到同一个环,增删节点只迁移邻接区间 | ≠ 哈希取模;取模在节点变化时几乎全量搬迁,见 19.4 一致性哈希 |
| 虚拟节点 | 一个物理节点在环上占多个位置,用来削平负载倾斜 | ≠ 副本;虚拟节点解决均衡,副本解决可靠,见 19.5 虚拟节点 |
| 热点 (hot key) | 某个 key 的流量远超均值,单分片被打满 | ≠ 数据倾斜;倾斜是静态分布问题,热点是流量问题 |
| 再平衡 (rebalance) | 把分区/数据从旧节点搬到新节点,让负载重新均衡 | ≠ 扩容;扩容只是加机器,再平衡才是数据搬家 |
| 2PC | 协调者两阶段(prepare / commit),阻塞且怕协调者宕机 | ≠ 分布式事务的默认答案;它是协议,不是产品 |
| TCC | Try-Confirm-Cancel 三段业务补偿,靠预留资源换隔离性 | ≠ 2PC;TCC 没有全局锁,靠业务幂等与空回滚兜底,见 24.4 TCC (空回滚 / 幂等 / 悬挂) |
| Saga | 长事务拆成一串本地事务 + 逆操作,失败就反向补偿 | ≠ 回滚;补偿是业务上的抵消,不是物理撤销,见 24.5 Saga (编排 / 协同 / 补偿) |
| 本地消息表 | 业务写库与「待发消息」同库同事务提交,再由投递器发出 | ≠ 事务消息;它是应用层方案,不依赖 MQ 特性,见 24.6 本地消息表 |
| 事务消息 | 半消息 + 本地事务 + 回查,把「发消息」纳入事务 | ≠ 本地消息表;它把可靠性交给 MQ,见 24.7 事务消息 |
| 最大努力通知 | 只保证「尽力重试 N 次」,允许最终不一致,由对账兜底 | ≠ 可靠投递;它明确放弃了投递保证 |
| 幂等 (idempotency) | 同一请求执行 N 次的效果 == 执行 1 次 | ≠ 去重;去重是实现手段,幂等是语义,见 25.4 幂等设计与去重 |
| 去重键 (dedup key) | 用来判定「这是同一次请求」的业务标识 | ≠ 主键;主键保证唯一,去重键要在入口就固定 |
| CRDT | 一种「合并操作可交换、可重复」的数据结构,天然最终一致 | ≠ 万能并发解;它只适合可定义合并语义的数据 |
| Chandy-Lamport 快照 | 用 marker 消息在分布式系统中切出一致性全局快照 | ≠ 备份;快照是「某一刻的状态」,不含历史 |
| 拜占庭故障 | 节点可能作恶/说谎,不只是宕机 | ≠ 崩溃故障;互联网内部系统通常只假设崩溃模型 |
| FLP 不可能性 | 完全异步 + 一个进程可能崩溃 ⇒ 不存在既安全又终止的共识算法 | ≠ 「共识做不了」;工程上用超时/随机化绕开,见 22.2 FLP 不可能性 |
四、L2 架构风格(第 26–33 章)
| 术语 | 一句话说清 | 别混成 |
|---|---|---|
| 分层 | 上层依赖下层,同层不互相依赖;依赖方向就是改动方向 | ≠ 分层越多越好;每层都是转发与心智成本,见 26.1 分层架构 |
| 依赖倒置 (DIP) | 高层定义接口,低层实现接口,依赖指向抽象 | ≠ 依赖注入;DI 是一种实现手段,DIP 是原则,见 26.2 依赖倒置 |
| 整洁 / 六边形 / 洋葱 | 同一件事的三种说法:业务在内圈,IO 在外圈,靠端口适配器翻转依赖 | ≠ 三种不同架构;差别只在画法与术语,见 26.5 六边形架构 |
| 模块化单体 | 一个部署单元,但内部模块边界与依赖规则像微服务一样严格 | ≠ 微服务预备队;它是独立终点,不是过渡态 |
| 大泥球 (big ball of mud) | 没有边界、任何改动都可能影响任何地方的系统 | ≠ 老系统;老而清晰不是泥球 |
| 微服务 | 以业务能力为边界、独立部署、独立数据的小服务集合 | ≠ 拆得越细越好;粒度由团队与变更频率决定 |
| 分布式单体 | 拆成了多个服务,但必须一起发版、共享数据库、同步调用成链 | ≠ 微服务;它拿到了微服务的成本,没拿到收益 |
| 服务契约 | provider 对 consumer 的承诺:接口、语义、错误码、兼容策略 | ≠ API 文档;契约是可被测试执行的(契约测试) |
| 编排 (orchestration) | 一个中心大脑按流程依次调用参与者 | ≠ 协同;编排易读但中心化,见 24.5 Saga (编排 / 协同 / 补偿) |
| 协同 (choreography) | 参与者各自监听事件、自行决定下一步,无中心 | ≠ 无政府;协同需要事件契约与全局可观测 |
| EDA (事件驱动架构) | 以「已发生的事实」为第一类公民,生产者不关心消费者 | ≠ 消息队列;MQ 是传输,EDA 是依赖方向的翻转 |
| CQRS | 读写模型分离,写模型管一致性,读模型管查询形状 | ≠ 读写分离;CQRS 分的是模型,不是库 |
| 事件溯源 (event sourcing) | 只存事件流,状态由重放推导 | ≠ 审计日志;审计日志不是事实源,事件流是 |
| 投影 (projection) | 把事件流折叠成可查询的读模型 | ≠ 物化视图;投影可由事件重建,物化视图由查询定义 |
| 限界上下文 (bounded context) | 一个术语只有一种含义的边界 | ≠ 微服务;一个上下文可以是一个模块,见 29.1 领域、子域、限界上下文 |
| 上下文映射 | 上下文之间的七种关系(共享内核、防腐层、客户-供应商…) | ≠ 系统集成图;它描述的是团队与模型的关系 |
| 聚合 (aggregate) | 一致性边界:一次事务只改一个聚合 | ≠ 实体;聚合是一簇对象 + 不变式 |
| 事件风暴 | 用便利贴把领域事件、命令、聚合、边界一次性铺出来的工作坊 | ≠ 头脑风暴;它产出的是可执行的模型 |
| BFF | 为某类前端定制的后端聚合层 | ≠ API 网关;BFF 管「形状」,网关管「入口」 |
| 多运行时 (multi-runtime) | 业务逻辑与分布式能力(状态、绑定、发布订阅)分进程,通过 sidecar 提供 | ≠ Service Mesh;Mesh 管网络,多运行时管能力 |
| 绞杀者模式 (strangler) | 用新实现逐步包住旧系统,流量一点点切走 | ≠ 重写;重写是 big bang,绞杀是渐进 |
| 防腐层 (ACL) | 在边界做一层翻译,隔离外部模型的污染 | ≠ 适配器;ACL 翻译的是语义,适配器翻译的是协议 |
五、L3 质量属性(第 34–40 章)
| 术语 | 一句话说清 | 别混成 |
|---|---|---|
| SLI | 被度量的那个数:成功率、延迟、饱和度 | ≠ SLO;SLI 是「体温计读数」 |
| SLO | 对 SLI 的内部目标,例如「30 天 99.9% 成功」 | ≠ SLA;SLO 破了不用赔钱,但要停发布 |
| SLA | 对外承诺 + 违约后果(赔付、信用) | ≠ 技术目标;SLA 是商务合同的一部分 |
| 错误预算 | 1 - SLO 折算成可失败的量(时间或请求数) | ≠ 允许出错;预算用完要冻结变更才有意义 |
| 「9」的换算 | 99.9% ≈ 每月 43.2 分钟;99.99% ≈ 4.32 分钟;99.999% ≈ 26 秒 | ≠ 线性成本;每加一个 9,成本与组织要求都跳一级 |
| P99 / P999 | 99% / 99.9% 的请求快于该值 | ≠ 平均值;均值会被少数极慢请求或大量极快请求扭曲,见 34.1 性能指标 |
| 长尾放大 | 一次请求要扇出 N 个下游,只要一个慢,整体就慢 | ≠ 平均延迟;扇出把尾部概率放大 N 倍 |
| 利特尔法则 | 并发 = 到达率 × 停留时间,容量规划的起点 | ≠ 性能公式;它只描述稳态,见 34.2 性能建模 |
| 排队论 | 利用率接近 1 时,排队长度与延迟非线性爆炸 | ≠ 线性扩容;见 34.2 性能建模 |
| Amdahl 定律 | 加速比受不可并行部分上限约束 | ≠ 线性扩展;见 37.5 加速比与阿姆达尔定律 |
| 熔断 (circuit breaker) | 失败率超阈值就快速失败,给下游恢复时间 | ≠ 限流;熔断看错误,限流看速率,见 35.6 熔断与降级 |
| 降级 (degradation) | 主动关闭非核心功能,保住核心链路 | ≠ 熔断;降级是选择,熔断是反应 |
| 限流 | 把入口速率压到系统能承受的上限(令牌桶 / 漏桶 / 滑动窗口) | ≠ 削峰;限流丢弃,排队/异步才削峰,见 35.7 限流 (漏桶 / 令牌桶 / 滑动窗口 / 自适应) |
| 背压 (backpressure) | 下游处理不过来时,把压力反向传导给上游 | ≠ 限流;限流在入口,背压在全链路 |
| 隔离舱 (bulkhead) | 按依赖/租户/请求类型分配独立资源池,一处打满不拖垮全船 | ≠ 多副本;副本共享同一资源池时起不到隔离作用 |
| 重试风暴 | 失败 → 全体重试 → 压力翻倍 → 更失败 | ≠ 重试;必须配退避 + 抖动 + 预算,见 35.5 超时、重试与退避 |
| RTO | 故障后恢复服务所需时间 | ≠ RPO;RTO 管「多久能用」,见 36.1 RTO / RPO |
| RPO | 可容忍丢失的数据时间窗 | ≠ 备份周期;RPO 决定「最多丢多少」,备份只是手段 |
| 冷 / 温 / 热备 | 备站是否常驻运行、能否分钟级接管 | ≠ 多活;热备有数据、未必有流量,见 36.3 冷备 / 温备 / 热备 |
| 两地三中心 | 同城双活 + 异地灾备,兼顾 RTO 与 RPO | ≠ 三活;同城两中心通常一主一备或双活,异地是冷/温备,见 36.4 两地三中心与多活 |
| 单元化 (set 化) | 按用户维度切片,每片自带全套服务与数据,故障只影响一片 | ≠ 分库分表;单元化切的是全栈,不是单表 |
| 零信任 | 不因「在内网」而信任,每次访问都要认证 + 授权 + 最小权限 | ≠ VPN;VPN 建立的是网络信任,见 38.8 零信任 |
| STRIDE | 威胁建模六分类:伪造、篡改、否认、信息泄露、拒绝服务、提权 | ≠ 漏洞扫描;STRIDE 在设计期用 |
| mTLS | 双向证书认证,双方都要证明身份 | ≠ TLS;TLS 只验服务端,mTLS 验两端 |
六、L4 组件与技术(第 41–50 章)
| 术语 | 一句话说清 | 别混成 |
|---|---|---|
| Cache-Aside | 应用自己读写缓存与数据库:读时回填,写时删缓存 | ≠ 读穿;旁路缓存由应用编排,见 41.1 缓存模式 (旁路 / 读穿 / 写穿 / 写回) |
| 读穿 / 写穿 / 写回 | 由缓存层代理数据库读写;写回先写缓存、异步落库 | ≠ 旁路;写回有丢数据窗口 |
| 缓存穿透 | 查一个不存在的 key,每次都打到数据库 | ≠ 击穿;穿透是「查无此物」,见 41.3 缓存穿透 / 击穿 / 雪崩 |
| 缓存击穿 | 一个热点 key 过期瞬间,大量请求同时回源 | ≠ 雪崩;击穿是单 key,雪崩是批量 |
| 缓存雪崩 | 大批 key 同时过期或缓存整体挂掉,流量瞬间压到数据库 | ≠ 击穿;雪崩的规模是面 |
| 布隆过滤器 | 用位图 + 多哈希判断「一定不存在 / 可能存在」,有假阳无假阴 | ≠ 精确去重;删元素困难,见 41.8 布隆过滤器 |
| B+ 树 | 多叉平衡树,叶子链表,适合范围查询与磁盘页 | ≠ LSM;B+ 树原地更新,读放大低、写放大高 |
| LSM 树 | 内存表 + 有序文件分层合并,写快读慢 | ≠ B+ 树;LSM 写放大在 compaction,读要查多层 |
| WAL | 先写日志再改数据页,崩溃后重放恢复 | ≠ binlog;WAL 是存储引擎内部日志,binlog 是复制日志 |
| MVCC | 多版本并发控制:读不阻塞写,靠版本可见性判断 | ≠ 乐观锁;MVCC 管可见性,乐观锁管冲突 |
| 隔离级别 | 读未提交 / 读已提交 / 可重复读 / 串行化,规定能看见什么异常 | ≠ 一致性模型;隔离级别是单库事务语义 |
| 幻读 | 同一事务两次范围查询,第二次多出「幻影行」 | ≠ 不可重复读;后者是同一行被改,前者是行集变了 |
| 间隙锁 (gap lock) | 锁住索引区间,阻止别的事务在区间内插入 | ≠ 行锁;间隙锁在 RR 下防幻读,也更容易死锁 |
| 覆盖索引 | 查询需要的列全在索引里,不用回表 | ≠ 联合索引;覆盖是结果,联合索引是手段 |
| 最左前缀 | 联合索引只能从最左列开始连续匹配 | ≠ 索引失效;范围查询之后的列失去有序性,见 44.8 索引原理 |
| 执行计划 | 优化器选出的访问路径与连接顺序 | ≠ 实际执行;计划是估算,慢查询要看真实行数 |
| 读写放大 | 一次逻辑读写引发的物理 IO 次数 | ≠ 磁盘 IOPS;放大倍数决定了同样的 QPS 需要几倍磁盘 |
| 列式存储 | 按列连续存放 + 压缩 + 向量化执行,适合扫描聚合 | ≠ 行存;点查与事务不是它的强项 |
| OLTP / OLAP | 事务型(点查、短事务)vs 分析型(大扫描、聚合) | ≠ 数据库产品分类;同一个产品可以两种负载都跑,只是不划算 |
| 湖仓一体 | 数据湖存原始文件 + 表格式(Iceberg / Delta / Hudi)提供 ACID 与 schema | ≠ 数仓;湖仓的存储与计算解耦更彻底 |
| 物化视图 | 把查询结果预先算好存下来 | ≠ 缓存;物化视图有刷新语义与一致性代价 |
| CDC | 捕获数据变更(日志/快照)并投递出去 | ≠ 定时抽数;CDC 是增量 + 低延迟,见 46.4 CDC (变更数据捕获) |
| 倒排索引 | 词 → 文档列表,支撑全文检索 | ≠ 正排;倒排解决「哪些文档含此词」,见 45.1 倒排索引与分词 |
| 投递语义 | at-most-once / at-least-once / exactly-once | ≠ 业务幂等;exactly-once 通常指链路内,见 43.2 投递语义 |
| 消费组 / 再均衡 | 同组内分摊分区;成员变化触发分区重新分配 | ≠ 扩缩容;再均衡期间可能全组暂停 |
| 堆积 (lag) | 最新生产位点与消费位点的差 | ≠ 延迟;lag 是消息条数,要除以吞吐才是时间 |
| 延迟消息 | 到期才投递的消息(定时/延时) | ≠ 重试队列;延迟消息是业务语义 |
| RPC / Stub | 把远程调用伪装成本地调用,Stub 负责编解码与传输 | ≠ REST;RPC 强调接口与 IDL,见 42.1 RPC 原理与 Stub |
| IDL | 接口定义语言(proto / thrift),契约的唯一事实源 | ≠ 文档;IDL 能生成代码与校验 |
| 服务发现 | 让调用方找到「当前有哪些实例、地址是什么」 | ≠ 负载均衡;发现解决「名单」,LB 解决「选谁」,见 48.2 服务发现 |
| 配置中心 | 集中管理配置 + 变更推送 + 灰度 + 回滚 | ≠ 环境变量;配置中心的核心是变更管理,见 48.1 配置中心 |
| 分布式锁 | 跨进程互斥,靠租约 + 续期 + fencing 保证安全 | ≠ 单机锁;网络分区下「锁」只能靠令牌兜底,见 48.3 分布式锁 |
| Watch / 长轮询 | 变更通知的两种形态:服务端推送 vs 挂起请求 | ≠ 轮询;长轮询省 QPS 但占连接,见 48.5 Watch 与通知机制 |
| 向量数据库 | 存 embedding 并做近似最近邻检索(ANN) | ≠ 传统数据库加个字段;索引结构与查询语义都不同 |
| ANN / HNSW / IVF | 近似最近邻:图索引(HNSW)或倒排聚类(IVF),用召回率换速度 | ≠ 精确 KNN;ANN 有召回率这个一等公民 |
| 量化 (quantization) | 用更低精度(int8 / fp8 / 4bit)存权重或激活,换显存与吞吐 | ≠ 压缩;量化会改变数值分布,要重新评测 |
七、L5 工程效能(第 51–59 章)
| 术语 | 一句话说清 | 别混成 |
|---|---|---|
| 测试金字塔 | 单元多、集成中、端到端少,按反馈速度分层 | ≠ 覆盖率目标;金字塔管结构,覆盖率管广度,见 53.1 测试金字塔 |
| 单元 / 集成 / 端到端 | 只测一段逻辑 / 测组件间真实协作 / 从用户入口走完整链路 | ≠ 按代码行数分;分类依据是依赖的真实程度 |
| 契约测试 | 只验证 provider 是否满足 consumer 的期望,不启动整套环境 | ≠ 集成测试;契约测试跑得快,能进 CI 门禁 |
| 测试替身 | mock(验交互)/ stub(给固定返回)/ fake(可用实现)/ spy | ≠ 都是 mock;选错替身会让测试绑死实现 |
| 覆盖率门禁 | 覆盖率低于阈值就阻断合并 | ≠ 质量保证;覆盖率只证明「跑过」,不证明「验对」 |
| 不可变制品 | 一次构建、处处部署,制品带 digest | ≠ 版本号;tag 可被覆盖,digest 不会 |
| 滚动 / 蓝绿 / 金丝雀 | 逐个替换 / 两套并存切流 / 小流量先验 | ≠ 灰度;灰度是能力,三者是策略,见 55.1 发布策略 |
| 特性开关 | 代码先上线,行为由开关控制 | ≠ 配置;开关要定期清理,否则变成技术债 |
| Expand-Contract | 数据库变更三步:先扩(兼容新旧)、再迁、后收(删旧) | ≠ 一次性改表;跨版本发布必须能新旧共存 |
| 向后兼容 | 新版本能读旧数据 / 旧客户端能调新服务 | ≠ 向前兼容;两者方向相反,别混用 |
| 混沌工程 | 主动注入故障,验证系统假设 | ≠ 压测;压测找容量上限,混沌找失效路径 |
| DORA 四指标 | 交付周期、部署频率、变更失败率、恢复时长 | ≠ KPI;它是团队诊断工具,拿来考核必然被优化,见 59.1 DORA 四指标 |
| 古德哈特定律 | 一个指标一旦成为目标,就不再是好指标 | ≠ 指标无用;要配反向指标(如速度配质量),见 59.3 度量的陷阱 |
| SBOM / SLSA | 软件物料清单 / 供应链完整性等级 | ≠ 漏洞扫描;SBOM 回答「我用了什么」,SLSA 回答「怎么构建的」 |
| FinOps | 让云成本可归因、可预测、可优化的运营机制 | ≠ 省钱;FinOps 首先要求成本能分到团队 |
| 容量模型 | 用「单实例能力 × 副本数 × 冗余系数」推导所需资源 | ≠ 压测报告;模型要能解释为什么是这个数 |
八、AI 原生(第 60–64 章 + 大模型时代新增)
这一组的判定标准:它们是不是改变了架构决策。只是「新名词」的,不进这张表。
| 术语 | 一句话说清 | 别混成 |
|---|---|---|
| LLM (大语言模型) | 用海量文本训练出的「下一个 token 概率分布」,能力来自规模与对齐 | ≠ 知识库;它记的是统计规律,不是可检索的事实 |
| token | 模型处理文本的最小单位(约等于 0.5–1 个汉字,视分词器而定) | ≠ 字符;计费、上下文、限流全按 token 算 |
| 上下文窗口 (context window) | 单次推理能容纳的 token 上限(输入 + 输出) | ≠ 记忆;窗口是每次请求重算的,不是持久状态 |
| 上下文工程 (context engineering) | 决定「这一轮到底往窗口里放什么」:指令、检索片段、工具结果、历史摘要 | ≠ prompt 工程;prompt 是写指令,上下文工程管整个窗口的预算分配 |
| prompt / system prompt | 输入指令 / 系统级人设与规则,后者优先级更高 | ≠ 代码;prompt 是不可编译的规格说明,必须配评测 |
| few-shot | 在 prompt 里给几个示例,让模型照格式做 | ≠ 微调;few-shot 不改权重,改的是上下文 |
| CoT (思维链) | 让模型先写推理过程再给答案,提升复杂任务准确率 | ≠ 解释;CoT 是计算过程,不保证忠实反映真实因果 |
| 结构化输出 (structured output) | 用 JSON Schema / 语法约束让输出可被程序解析 | ≠ 提示「请输出 JSON」;约束要由解码器保证 |
| function calling / tool use | 模型输出「调用哪个工具、什么参数」,由宿主执行 | ≠ Agent;它只是一次工具调用 |
| MCP (Model Context Protocol) | 把「模型 ↔ 工具/数据源」的连接标准化:server 暴露 tools/resources/prompts,client 负责调用 | ≠ 插件;MCP 是协议,换了宿主不用重写适配器 |
| A2A (Agent2Agent) | Agent 之间互相发现、委派任务、交换产物的协议(含 Agent Card) | ≠ MCP;MCP 连工具,A2A 连Agent |
| Agent | 有目标、有计划、能调工具、能观测结果、有终止条件的执行体 | ≠ 聊天机器人;判据是闭环 + 预算 + 终止 |
| agentic workflow | 用固定编排(链、路由、并行、评审)把多次 LLM 调用组合成流程 | ≠ 自主 Agent;workflow 的路径是人定的,更可控 |
| planning | 把目标拆成可执行步骤,并在执行中重规划 | ≠ 一次 CoT;planning 要能被外部状态打断与修正 |
| memory | 跨轮次保留的信息:短期(窗口内)、长期(外部存储 + 检索) | ≠ 上下文窗口;窗口是容量,memory 是机制 |
| reflection | 让模型检查自己的输出并修正(自评、重写、验证) | ≠ 重试;reflection 要有新的判据,否则只是重复犯错 |
| RAG (检索增强生成) | 先检索、再拼进上下文、再生成,并给引用 | ≠ 向量检索;RAG 是整条链路,瓶颈常在切分与重排 |
| chunking | 把文档切成语义完整的片段,决定检索的最小单位 | ≠ 分页;切分边界决定召回质量 |
| embedding | 把文本映射成向量,语义相近则距离近 | ≠ 关键词匹配;embedding 对精确串(编号、错误码)反而弱 |
| 混合检索 (hybrid search) | 向量召回 + 关键词召回(BM25)融合 | ≠ 只用向量;精确词与长尾词靠关键词兜底 |
| rerank | 用交叉编码器对候选集重新打分排序 | ≠ 召回;rerank 精度高但贵,只能对少量候选做 |
| grounding | 让答案绑定到可引用的证据上 | ≠ 事实正确;grounding 保证「有出处」,不保证「出处对」 |
| 幻觉 (hallucination) | 模型生成看似合理但无依据的内容 | ≠ 错误;幻觉的特点是流畅且自信,所以必须靠外部校验 |
| eval(评测集) | 一组「输入 + 判据」的回归测试集,用于比较模型/prompt/检索策略 | ≠ 单元测试;eval 是概率性的,看通过率与置信区间 |
| LLM-as-judge | 用更强的模型按 rubric 打分,替代人工评审 | ≠ 客观真值;judge 有偏好(长度、格式、自家模型),要校准 |
| 微调 (fine-tuning) | 用领域数据继续训练,改变权重与风格/格式能力 | ≠ RAG;微调改行为,RAG 补知识 |
| LoRA / QLoRA | 只训练低秩旁路矩阵,大幅降低显存与成本 | ≠ 全参微调;LoRA 容量有限,适合风格与格式 |
| RLHF / DPO | 用人类偏好数据对齐模型(奖励模型 + RL / 直接偏好优化) | ≠ 监督微调;对齐改的是偏好,不是知识 |
| 蒸馏 (distillation) | 用大模型生成的数据训练小模型 | ≠ 量化;蒸馏换模型规模,量化换数值精度 |
| KV cache | 缓存已算过的 Key/Value,避免每生成一个 token 都重算历史 | ≠ 上下文缓存;KV cache 是显存换算力,长度 × 层数 × 头数 线性增长 |
| prefill / decode | 预填充(并行处理输入,算力密集)/ 解码(逐 token 生成,访存密集) | ≠ 训练的前向/反向;推理两阶段瓶颈完全不同 |
| TTFT / TPOT | 首 token 延迟 / 每输出 token 时间 | ≠ 总延迟;流式体验看 TTFT,长文吞吐看 TPOT |
| continuous batching | 请求级动态拼批,一个 batch 里不断有请求进出 | ≠ 静态批;它把 GPU 利用率从「等最慢的」变成「填满每个 slot」 |
| PagedAttention | 把 KV cache 按页管理,消除显存碎片、支持前缀共享 | ≠ 普通注意力优化;它解决的是显存管理 |
| 投机解码 (speculative decoding) | 小模型先猜几个 token,大模型一次校验 | ≠ 蒸馏;输出分布不变,只换速度 |
| MoE (混合专家) | 每层只激活少数专家,参数总量大、单次算力小 | ≠ 模型集成;MoE 是一个模型内部的稀疏激活 |
| 推理模型 / 测试时计算 | 用更长的思考 token 换准确率(可调 reasoning effort) | ≠ CoT 提示;它是训练出来的能力 + 可调预算 |
| LLM 网关 | 统一入口:多模型路由、配额、重试、缓存、审计、成本归因 | ≠ API 网关;多了token 计量与模型路由 |
| 语义缓存 | 用 embedding 相似度命中历史答案 | ≠ KV 缓存;语义缓存有误命中风险,要设阈值 |
| guardrail | 输入输出两侧的规则/模型检查:敏感词、越权、注入、格式 | ≠ WAF;guardrail 检查的是语义,有误杀率 |
| prompt injection | 把恶意指令藏在 retrieved 内容或工具返回里,劫持模型行为 | ≠ 越狱;越狱针对模型策略,注入针对你的应用逻辑 |
| HITL (human-in-the-loop) | 高风险动作前插入人工确认 | ≠ 人工兜底;HITL 是设计出来的检查点 |
| AgentOps / LLMOps | 对 LLM 应用的版本、评测、追踪、成本、回滚做工程化管理 | ≠ MLOps;多了 prompt/检索/工具的版本与在线评测 |
| AI 原生 (AI-native) | 把模型能力当作一等依赖来设计:不确定性、成本、延迟、评测都进架构 | ≠ 「加了个 AI 功能」;判据是没有模型,系统就不成立 |
8.1 映射:AI 术语 ↔ 传统架构的等价物
这张表是这一节最重要的部分——它让你用已有知识去理解新词,也提醒你哪里不能类比。
| AI 术语 | 传统架构里的等价物 | 映射成立的部分 | 不成立的部分 |
|---|---|---|---|
| 上下文窗口 | 内存 / 工作集 | 都是「当下能同时处理的数据量」 | 窗口每次请求重建,没有持久性;且要按 token 付费 |
| RAG | 带缓存的读路径(Cache-Aside + 检索) | 都是「先查再算,查不到就降级」 | 检索结果是概率性的,没有「命中/未命中」的二值语义 |
| embedding + 向量库 | 二级索引 | 都是「为查询建索引」 | ANN 有召回率,索引会漏;传统索引漏了就是 bug |
| LLM 网关 | 反向代理 / API 网关 | 都是统一入口、限流、鉴权、可观测 | 还要做token 计量、模型路由、成本归因 |
| 语义缓存 | 缓存 | 都是「用旧结果省一次计算」 | 命中靠相似度,会错;必须设阈值 + 兜底校验 |
| guardrail | WAF / 输入校验 | 都是入口拦截 | 语义判断有误杀,且攻击面是自然语言 |
| eval 集 | 回归测试套件 | 都是「改了就重跑,防退化」 | 结果是通过率而非通过/失败,要看统计显著性 |
| Agent | 有状态的服务编排器(Saga / 工作流引擎) | 都有状态、步骤、补偿 | 步骤由模型动态决定,不可穷举,必须设预算与终止条件 |
| MCP | 驱动 / 适配器层(ODBC、SPI) | 都是「换实现不改调用方」 | 工具描述本身进上下文,描述质量影响行为 |
| prompt | 配置 / 规格说明 | 都是「不改代码改行为」 | 无编译期校验,只能靠 eval 回归 |
| 微调 | 编译期特化 / 代码生成 | 都把「通用能力」变成「专用能力」 | 会遗忘、会引入偏见,且不可回滚到「上一版权重」以外 |
| 推理成本 | 单次请求的 CPU 成本 | 都是「单位经济」 | 成本随输出长度变化,不可预估,必须按预算限流 |
| 幻觉 | 缓存脏数据 / 陈旧索引 | 都是「返回了不可信的结果」 | 幻觉没有错误码,监控抓不到,只能靠 grounding 与抽检 |
🔑 一句话:AI 原生系统不是「传统系统 + 模型」,而是「把不确定性当成一等公民重新设计」。凡是「输入 → 确定输出」的假设,都要改写。
8.2 AI 时代新增的质量属性
传统七件套(性能、可用性、灾备、扩展、安全、成本、可维护)不够用了。下面五个指标必须进 SLO 讨论:
| 指标 | 定义 | 为什么不能省 | 典型做法 |
|---|---|---|---|
| 答案质量 (quality) | eval 集通过率 / 人工抽检合格率 | 系统「没报错」但答案是错的,传统监控完全看不见 | 固定 eval 集 + 每次改 prompt/模型/检索都跑回归 |
| groundedness | 答案中「有引用支撑」的比例 | 幻觉是静默失败,只能靠引用审计 | 强制引用 + 引用校验 + 无据不答 |
| 工具调用成功率 | 工具调用中参数合法且执行成功的比例 | Agent 的失败大多发生在工具边界 | schema 校验 + 幂等 + 重试预算 + 沙箱 |
| TTFT / 流式体验 | 首 token 时间与 token 间间隔 | 用户感知的是「多久开始出字」 | 流式输出 + 前缀缓存 + 就近推理 |
| 单任务成本 (cost per task) | 完成一个业务任务的平均 token + 工具成本 | 成本随「思考长度」不可预估,会失控 | token 预算 + 模型分级路由 + 语义缓存 + 结果复用 |
九、让术语表可执行:一个歧义检测器
术语表的敌人不是「不知道」,是说的人以为说清了。下面这个脚本把「裸用歧义词」找出来——它不能替你判断,但能让「一致性」「延迟」这类词在评审前就暴露出来。
#!/usr/bin/env python3
"""术语歧义检测:把「裸用」的歧义词揪出来。
用法:python3 check-terms.py 80.1-C4模型.md
规则:歧义词左右 12 个字符内没有出现任一限定词,就报一行。
"""
import re
import sys
# 歧义词 -> 能消除歧义的限定词(任一出现即算合格)
AMBIGUOUS = {
"一致性": ["线性", "顺序", "因果", "最终", "强", "弱", "会话", "读己之写"],
"延迟": ["P99", "P999", "平均", "首", "尾", "网络", "TTFT", "TPOT"],
"幂等": ["语义", "去重", "键", "token", "接口", "执行"],
"缓存": ["本地", "分布式", "多级", "旁路", "穿透", "击穿", "雪崩"],
"扩展": ["垂直", "水平", "弹性"],
}
WINDOW = 12
def scan(path):
hits = []
with open(path, encoding="utf-8") as f:
for lineno, line in enumerate(f, 1):
for word, quals in AMBIGUOUS.items():
for m in re.finditer(word, line):
ctx = line[max(0, m.start() - WINDOW): m.end() + WINDOW]
if not any(q in ctx for q in quals):
hits.append((lineno, word, ctx.strip()))
return hits
if __name__ == "__main__":
hits = scan(sys.argv[1])
for lineno, word, ctx in hits:
print(f"{sys.argv[1]}:{lineno} 「{word}」缺限定词:{ctx}")
print(f"\n共 {len(hits)} 处待补限定词")
拿它扫 80.1 C4 模型,本机实际输出:
80.1-C4模型.md:41 「缓存」缺限定词:* (数据库、对象存储、缓存、队列)。
80.1-C4模型.md:133 「缓存」缺限定词:多层(上下文里塞数据库和缓存) | 抽象层级混乱,谁
80.1-C4模型.md:145 「一致性」缺限定词:两件事:① **抽象层级一致性**——一旦出现一个内部
80.1-C4模型.md:151 「缓存」缺限定词:务、1 个数据库、1 个缓存、1 个网关、2 个外部
80.1-C4模型.md:153 「缓存」缺限定词:+ 1 DB + 1 缓存 + 1 网关 = 6
共 5 处待补限定词
怎么用它,三条纪律:
| 纪律 | 说明 |
|---|---|
| 只报不拦 | 它是提示器,不是门禁。第 41/151/153 行是「组件清单里的缓存」,本来就无需限定——这类误报要靠人工判断,不要为了清零去改正文 |
| 只扫对外文档 | 评审稿、方案、架构图说明必扫;内部草稿不必 |
| 限定词表随团队长 | 团队被「一致性」坑过一次,就把那次的具体限定词(如「跨机房」「库存扣减」)加进 AMBIGUOUS |
🔑 这个脚本的价值不在准确率,在于把「你以为说清了」变成「有人替你看了一眼」。术语治理和代码规范一样,靠工具降低摩擦,不靠自觉。
反模式
| 反模式 | 后果 |
|---|---|
| 用「高可用」「高性能」代替数字 | 无法验收,也无法判断改动是变好还是变坏 |
| 说「一致性」不说哪一种 | 讨论原地空转:一个人在说线性一致,一个人在说最终一致 |
| 用产品名代替架构模式(「我们上了 Kafka,所以是事件驱动」) | 依赖方向没翻转,只是换了个中间件,仍是同步耦合 |
| 中英混用且首次出现不给英文 | 同一概念三种写法,检索不到、评审对不齐 |
| 把论文结论直接当 SLA(「论文说 P99 是 10ms」) | 论文的硬件、负载、数据分布都不是你的 |
| 术语堆砌的架构图(一张图 30 个名词) | 读者只能看到「很复杂」,看不到「怎么决策」 |
| 把新词当旧词用(Agent = 调工具的 LLM) | 设计缺闭环与预算,上线后无限循环、成本失控 |
| 只背定义不给反例 | 面试能过,评审会被追问到崩 |
自检
Q1 同事说「我们系统是 AP 的,所以不用管一致性」。这句话错在哪?请用 CAP 与 PACELC 各指出一个漏洞。
▸ 答案:CAP 里的 A/C 只在分区发生时才互斥,平时根本不需要放弃一致性;「是 AP 系统」不等于「随时可以不一致」。PACELC 进一步指出:无分区时真正的取舍是 L(延迟)与 C(一致性)——他可以为了低延迟选择读旧数据,但必须明确说出这个选择,并给出「多旧算可接受」的时间界。缺了时间界,「AP」就变成了「不保证」的遮羞布。
Q2 「Kafka 保证 exactly-once,所以我们的订单不会重复」。请指出这句话在哪个边界上失效,并给出正确的表述。
▸ 答案:Kafka 的 exactly-once 只在 Kafka 事务的「读-处理-写」范围内成立,且要求消费者用 read_committed 隔离级别。一旦下游是数据库、HTTP 接口、第三方支付,副作用就出了 Kafka 的事务边界,重复消费或重复调用仍然可能发生。正确表述是:「Kafka 事务保证链路内不重不丢;跨出 Kafka 的副作用必须由消费端幂等(去重键 + 状态机)兜底」。
Q3 有人把 RAG 等同于「接一个向量库」。请说出 RAG 链路上至少三个比向量库更常见的故障点,并说明为什么。
▸ 答案:① 切分——块太大导致检索到无关内容、块太小导致答案被截断,这是召回质量的第一杀手;② 重排——只靠向量相似度会把「语义相近但答案不对」的块排在前面,rerank 往往比换更大的向量库收益更高;③ 上下文预算——塞太多片段会挤掉指令与问题,模型开始「中间遗忘」(lost in the middle)。此外还有引用校验缺失导致的幻觉。结论:向量库只是召回的一种实现,RAG 的质量由链路最弱的一环决定。
Q4 Agent 与「带 function calling 的聊天」的判据是什么?请给出一个能暴露「假 Agent」的提问。
▸ 答案:判据是闭环:有目标分解、有执行、有对结果的观测与重规划、有明确的终止条件与预算(步数、时间、token、金额)。暴露假 Agent 的提问是:「这个任务如果三步之内没完成,它怎么停下来?停下来之后状态存在哪、谁能接手?」 答不出终止与状态,就只是一次工具调用,不具备 Agent 的工程属性。
Q5 一个团队说「我们的 SLO 是 99.99%」,但过去一个月实际是 99.95%。请判断这是不是事故,并说明下一步应该做什么。
▸ 答案:先算账:99.99% 意味着每月约 4.3 分钟不可用,99.95% 约 21.6 分钟——已经超支约 5 倍。这不是「差不多」,而是错误预算被击穿:按错误预算的纪律,应当冻结非必要变更,把精力放在稳定性上。下一步不是「把 SLO 调低到 99.95%」(那是把预算改成既成事实),而是:① 定位超支来源(是单点故障、发布事故,还是长尾慢请求被算进失败);② 判断 SLO 本身是否定错(比如把下游依赖的故障算进自己的分母);③ 补上能防住这次超支的具体机制,再恢复发布。
Q6 请解释「上下文窗口」和「memory」为什么不能互相替代,并各举一个会踩坑的场景。
▸ 答案:上下文窗口是容量,每次请求重建、按 token 付费;memory 是机制,负责决定「哪些历史值得留下、怎么取回」。用窗口代替 memory 的坑:长对话把历史全塞进去,成本线性上涨且触发「中间遗忘」,模型反而忽略关键指令。用 memory 代替窗口的坑:以为「存进向量库就等于记住了」,实际检索没召回,模型答得理直气壮却是错的。正确做法是分层:近期原文进窗口,远期摘要 + 关键事实进外部存储,按需检索回填,并给检索结果加引用。
关联
- 前置:1.1 功能性需求与非功能性需求、4.3 技术选型的评估维度
- 并列:83.2 参考文献与经典论文、83.3 工具与产品清单、83.4 学习路径索引
- 下游:80.2 架构图规范(术语统一是画图的前提)