从需求约束到故障注入：十一场系统设计推演

每题先写三行：可接受的失败、必须持久化的事实、对外可见的成功点。第一次只画单机路径，第二次增加并发实例，第三次让进程恰好在跨系统调用后崩溃。最后决定如何测试。不必为所有问题选相同的基础设施。

以下含设计扩展；具体实测边界以项目章和验收报告为准。

高并发 GPU 资源申请

**架构与数据：**网关接收 request_id，异步 admission worker 扣账。reservation 唯一键、tenant_quota.used/cap、outbox。

**主流程：**写入 waiting，事务内条件更新并入 outbox，成功后查询状态。 **异常：**请求超时后以同 ID 重试；冲突 payload 不覆盖已提交申请。

**瓶颈与取舍：**热门租户形成行锁热点；按租户拆分任务，不拆同一额度的不变量。

多租户配额

**架构与数据：**鉴权层把主体映射到租户，账本维护租户和全局两级上限。tenant、pool、reservation 三张表加操作 ID。

**主流程：**先判租户预算再挑可容纳的池，同事务提交。 **异常：**额度下调小于正在使用量时进入排水状态，不强行驱逐。

**瓶颈与取舍：**强一致条件扣减牺牲部分吞吐，允许超发的乐观缓存不适合硬配额。

高可用 Operator

**架构与数据：**多个 Manager 共享 Lease，watch CR 与受管子资源。Spec、Conditions、UID、observedGeneration、finalizer。

**主流程：**按键 Reconcile，拒绝抢占未受管对象，只写变化字段。 **异常：**Leader 丢失后重新 List，旧写入靠 resourceVersion 冲突保护。

**瓶颈与取舍：**大 cache 有内存成本，限定 namespace 与 selector；增加并发前测 apiserver QPS。

推理网关

**架构与数据：**认证、模型授权、EndpointSlice 发现、流代理分开。token→允许模型、服务→Ready 端点、在途计数。

**主流程：**先过滤再锁内选最少在途，锁外创建上游请求。 **异常：**快照过期停止路由；尚未输出且可重放时有限重试；流中断给客户端。

**瓶颈与取舍：**每请求排序 O(n log n)，大集群可抽取两候选；共享全局计数更准但更慢。

流式负载均衡

**架构与数据：**路由时参考排队、decode 活动与 KV 水位。端点指标快照、采样时间、预估 token 工作量。

**主流程：**剔除过期指标，按标准化代价选择端点，派发后立即增加本地估计。 **异常：**多个网关同时读到空闲值造成羊群；加随机选择与滞后保护。

**瓶颈与取舍：**高频抓取拖累推理进程，低频又过时；对比 TTFT 分布而非只看请求数。

GPU 碎片优化

**架构与数据：**业务 planner 与 scheduler 节点约束分离。节点能力向量、拓扑域、空闲容量、请求宽度和等待年龄。

**主流程：**先过滤硬件类型和拓扑，再 best-fit 或 spread，跟踪绑定结果。 **异常：**账本有槽却无法绑定时回到对账/补偿，不伪造 Running。

**瓶颈与取舍：**紧凑分配有利于大作业，也增加故障域集中；真实拓扑需要驱动支持。

跨系统一致性

**架构与数据：**数据库提交意图，worker 至少一次投递，控制器收敛实际对象。outbox 状态、request_id、CR UID、版本及最后观察时间。

**主流程：**事务提交→创建确定身份的 CR→回读→确认 delivered。 **异常：**外部 create 成功后 DB 更新失败，下一轮核验身份而非再次扣款。

**瓶颈与取舍：**大事务持锁调用 API 放大故障，生产采用短事务租约和周期对账。

弹性与冷启动

**架构与数据：**KEDA 从 Prometheus 读队列，HPA 管副本，Operator 管模板。负载窗口、min/max、Ready 世代、可用 GPU 预算、模型版本。

**主流程：**先满足扩容配额，再允许目标上升；加载完成 readiness 成功才派发。 **异常：**指标缺失保留可用容量，抖动用稳定窗口，拉取失败限制重试。

**瓶颈与取舍：**预留峰值降低利用率，按需批准会延长扩容；用冷/热两组基准比较。

高可靠 Agent Runtime

**架构与数据：**单 Agent 状态图、工具进程、持久化检查点、审批者。thread_id、观测字典、next node、UID、操作 ID。

**主流程：**每步有界执行，证据充分才挂起审批；修复后独立验证。 **异常：**写后响应丢失时按 ID 回读；未知状态保留检查点，不自动批准。

**瓶颈与取舍：**SQLite 适合单机教学，多副本要任务租约、数据库并发控制与限额。

权限与执行审计

**架构与数据：**只读 planner 与确定性 writer 使用不同 RBAC 和 API 角色。操作枚举、身份、资源 UID、generation、决策时间、审计记录。

**主流程：**验证身份→展示精确计划→审批→JSON Patch test→回读。 **异常：**日志诱导越权或陈旧批准时拒绝，保留失败原因。

**瓶颈与取舍：**细粒度策略更安全但覆盖故障少；不能用宽泛 shell 提升成功率。

自动故障诊断

**架构与数据：**观察器触发任务，Agent 查询有界工具，策略器按证据输出或弃权。Pod 条件、事件 UID、容器状态、日志片段和来源引用。

**主流程：**先区分调度/启动/运行/服务发现阶段，再选择来源，达到预算就停。 **异常：**事件过期、监控断连或不同故障共存时标注不确定性。

**瓶颈与取舍：**大量全量日志挤占上下文；先保存有界原始证据，再用压缩投影供 planner。

一次完整的白板验收

拿“高并发 GPU 资源申请”练习：同一 ID 重复提交，不准双扣；不同团队可以排队，不能抢占运行中的作业。先画提交事务、异步交付、调度和就绪四个时刻；在每两个时刻之间标记重启后的事实来源。把答案落到账本并发实验和网关重试边界。如果需求换成严格全局 FIFO，则原来的 SKIP LOCKED 与跨租户跳过队首不再满足承诺，必须讨论吞吐损失和队首阻塞。

让面试官选择一个断点

画完图后，把笔交给对方，请对方在数据库提交、外部 Create、写回确认三处任选一点让进程退出。逐处列出重启者能读到的记录，指出哪一种情况下不能判断外部操作是否成功。若设计只能说“重试即可”，再问一次重试的单位：整笔扣减、单个 outbox 任务，还是状态查询？选择不同，故障后余额可能完全不同。用最后一行才失败的实测反例区分本地事务原子性与跨系统投递。