十分钟架构评审口述模板

本册用于把架构评审压缩成可复述、可追问、可复算的十分钟闭环。所有容量、成本与收益数字默认属于 E3（演练设计）；只有能定位到本人代码、评审、发布、监控或事故记录的内容，才允许升级为 E1（直接证据）。

图解读：正式图以业务不变量为起点，依次经过需求澄清、架构总览、正常链路、失败链路、容量成本、治理迁移与复盘。每一段都留下可追问证据，任何失败分支最终必须回到业务验收；可编辑源见 PlantUML（开源建模工具）架构评审图。

1. 开场与需求澄清：第一分钟先锁定评审问题

1.1 用不变量、范围和量级把模糊需求变成可评审约束

热门面试题

1. 问题：十分钟架构评审为什么不能从组件清单开场？
   • 考点：业务不变量、问题边界和决策顺序。
   • 回答思路：先说明组件没有脱离约束的绝对优劣，再给出一分钟澄清框架。
   • 详细答案：评审开场先说明谁使用系统、什么结果绝不能错、峰值规模、允许延迟、故障容忍和本次不解决什么。组件只是约束下的实现手段；若先报数据库、缓存和消息组件，面试官无法判断选择是否解决了真实问题，也无法检查是否过度设计。
   • 进阶追问：业务方给不出量级怎么办？
   • 进阶回答：给出低、中、高三档 E3（演练设计）假设，明确敏感参数和核对负责人，用区间做可逆设计，不伪造精确生产数字。
2. 问题：六类项目各自最重要的不变量是什么？
   • 考点：领域差异、权威事实和失败成本。
   • 回答思路：按数量、资金、履约意图、任务结果、租约代次和告警可达性归纳。
   • 详细答案：WMS（仓储管理系统）守数量与账实一致；跨境物流守一个业务意图只有一个有效履约结果；支付守本金、手续费、退款与渠道可对平；异步任务守一次业务请求只交付一个有效结果；Runner（执行器）守当前代次才能提交；IoT（物联网）告警守降噪不能漏掉严重事件。共享的是评审顺序，不共享项目事实。
   • 进阶追问：不变量冲突时如何取舍？
   • 进阶回答：先按合规、资金与安全底线设不可牺牲项，再在延迟、成本和体验之间权衡，并把降级权限交给明确负责人。
3. 问题：如何判断需求已经澄清到可以画架构图？
   • 考点：输入门禁、验收口径和未知项管理。
   • 回答思路：检查触发者、输入、输出、规模、质量属性、边界和验收是否齐全。
   • 详细答案：至少能回答业务触发、唯一身份、权威事实、峰均量级、延迟目标、可用性边界、数据保留、合规要求、上下游责任和成功验收。未知项不必全部消失，但要进入假设清单，标明它影响哪个决策、如何取证以及何时必须关闭。
   • 进阶追问：时间只够问三个问题时问什么？
   • 进阶回答：问“什么绝不能错、峰值多大、依赖失败后允许怎样退化”，三问分别锁定正确性、容量和可用性。

flowchart LR
    A[业务目标] --> B[核心不变量]
    B --> C[范围与参与者]
    C --> D[量级与时效]
    D --> E[一致性与可用性]
    E --> F[验收与未知项]
    F --> G{约束是否足以决策}
    G -->|否| C
    G -->|是| H[进入架构总览]

图解读：需求澄清不是追求信息百分之百完整，而是保证每个关键设计都有约束来源。未关闭的信息回到范围或量级继续核对，已足够决策的内容才进入架构图口述。

数据演绎 1：一分钟问题预算

E3（演练设计）：开场 60 秒可分为业务目标 10 秒、不变量 15 秒、范围 10 秒、量级 15 秒、验收与未知项 10 秒。第一次录音若背景占 35 秒，只剩 25 秒说明约束，应删除组织历史和无关术语，把“不变量、峰值、故障退化”三项各补到至少 10 秒。总时长不变，但评审输入从背景叙述转为决策证据。

2. 架构图口述与正常链路：第二至第四分钟讲清职责

2.1 先总览边界，再沿一条请求解释正常数据流

热门面试题

1. 问题：架构图口述应按什么顺序展开？
   • 考点：系统边界、分层职责和数据所有权。
   • 回答思路：从参与者到入口、领域裁决、数据、异步与观测逐层展开。
   • 详细答案：先指出图内外边界和上下游，再讲入口如何鉴权、限流与生成业务身份；随后说明领域服务如何裁决状态，权威数据存在哪里，缓存与消息承担什么非权威职责，最后补充观测和人工处置入口。每个方框只讲职责与边界，不朗读技术栈。
   • 进阶追问：图上组件很多时怎么办？
   • 进阶回答：合并同职责组件，只保留改变一致性、容量、失败隔离或所有权的节点，其余放到追问附图。
2. 问题：正常链路为什么要同时讲状态和数据？
   • 考点：控制流、数据流和业务语义。
   • 回答思路：说明“调用成功”不等于“业务完成”。
   • 详细答案：状态描述业务从受理、处理中到成功或失败，数据描述唯一键、版本、流水和结果如何落地。只讲调用顺序会遗漏重复、乱序和超时后的裁决；只讲数据表又无法解释谁在何时改变状态。两者结合才能说明事务边界、异步边界和最终验收。
   • 进阶追问：缓存是否属于正常链路必讲内容？
   • 进阶回答：只有缓存改变了延迟、容量或一致性边界时才讲，并明确它是否可绕过、失效后由谁兜底。
3. 问题：怎样在三分钟内讲完一条正常链路？
   • 考点：叙事压缩、关键节点和结果验收。
   • 回答思路：用“身份、裁决、落库、传播、验收”五步法。
   • 详细答案：请求先获得稳定业务身份；领域服务依据当前状态和版本做裁决；权威事实与流水在本地事务内落库；提交后通过 MQ（消息队列）传播事件；下游按身份和版本幂等处理，最终用业务结果验收。每步只回答输入、动作、输出和失败责任，不展开框架内部细节。
   • 进阶追问：同步调用和异步消息如何取舍？
   • 进阶回答：当前响应必须知道且失败能立即回滚的步骤同步；可延后、可重放、需隔离波峰的步骤异步，并承担重复和延迟成本。

sequenceDiagram
    participant U as 业务调用方
    participant G as 入口层
    participant D as 领域服务
    participant S as 权威存储
    participant Q as 消息通道
    participant W as 下游执行方
    U->>G: 业务请求与唯一身份
    G->>D: 鉴权限流后转发
    D->>S: 状态校验、版本裁决、流水落库
    S-->>D: 提交结果
    D-->>U: 返回受理或完成状态
    D->>Q: 发布已提交事件
    Q->>W: 至少一次投递
    W->>W: 按身份与版本幂等
    W-->>S: 回写结果或对账依据

图解读：正常链路的关键不是箭头数量，而是事务提交前后责任清楚。权威存储先完成裁决，异步通道只传播已提交事实；下游必须按业务身份和版本抵抗重复，不能依赖“消息只来一次”。

数据演绎 2：三分钟正常链路字数分配

E3（演练设计）：按每分钟约 210 个有效字符，三分钟预算约 630 字。架构边界 100 字、入口与身份 90 字、领域裁决和事务 170 字、异步传播 120 字、结果验收 100 字、衔接失败链路 50 字，合计 630 字。若技术栈枚举占 180 字，应压缩到 60 字，把释放出的 120 字补给数据所有权、版本裁决和下游幂等。

3. 失败链路与恢复验收：第五至第六分钟主动注入故障

3.1 用发现、止血、定位、修复、恢复、复盘讲最高成本失败

热门面试题

1. 问题：架构评审为什么必须主动讲失败链路？
   • 考点：风险前置、故障域和恢复能力。
   • 回答思路：说明正常路径只能证明功能可用，失败路径才暴露架构边界。
   • 详细答案：超时、重复、乱序、依赖故障和资源耗尽会把隐藏的所有权、幂等、恢复和人工责任暴露出来。主动选择最高失败成本场景，可以验证是否有检测信号、止血手段、可重放证据和业务验收，避免把“重试一下”当成恢复方案。
   • 进阶追问：十分钟要讲多少个故障？
   • 进阶回答：主讲一个最高成本故障并完整闭环，另外列出两到三个次要风险作为追问入口。
2. 问题：支付超时未知和普通接口超时有什么本质差异？
   • 考点：外部副作用、结果未知和资金安全。
   • 回答思路：区分“失败已知”和“结果未知”，强调查单、对账与补偿。
   • 详细答案：普通读请求超时通常可直接重试，支付请求超时可能已在渠道产生扣款，盲重试会重复支付。系统应把状态置为处理中或未知，使用同一业务身份主动查单，结合验签回调和账单对账裁决，只有确认失败才允许重发支付意图。
   • 进阶追问：回调和查单结果冲突怎么办？
   • 进阶回答：按渠道协议、事件时间、签名、交易标识和最终账单设裁决规则，冲突进入隔离队列与人工复核，不能用最后到达覆盖。
3. 问题：恢复验收为什么不能只看服务恢复？
   • 考点：技术恢复、业务恢复和历史差异。
   • 回答思路：区分流量恢复、存量修复和业务守恒。
   • 详细答案：进程健康和错误率下降只表示新请求可能可用，事故期间的积压、重复、单边账、旧租约提交或漏告警仍可能存在。恢复必须先确认新流量稳定，再重放或补偿存量，最后通过数量、资金、任务结果和告警可达性等业务守恒验收。
   • 进阶追问：存量修复如何避免二次事故？
   • 进阶回答：按时间窗和风险分批，限速重放，保留幂等和版本校验，持续对比业务差异并设置暂停门禁。

flowchart TD
    A[故障信号出现] --> B{是否伤害核心不变量}
    B -->|是| C[限流隔离暂停危险动作]
    B -->|否| D[降级非核心能力]
    C --> E[按业务身份和时间窗定位]
    D --> E
    E --> F[确认权威事实与差异范围]
    F --> G[修复代码配置或数据]
    G --> H[小批量恢复与重放]
    H --> I{业务守恒是否通过}
    I -->|否| C
    I -->|是| J[全量恢复并复盘]

图解读：失败处理先保护不变量，再处理吞吐和体验。修复不直接等于全量恢复，必须经过小批重放和业务守恒门禁；验收失败时回到止血状态，而不是继续扩大修复范围。

数据演绎 3：支付未知态恢复

E3（演练设计）：10000 笔支付请求中 80 笔超时，本地未知率为 80÷10000=0.8%。主动查单确认 52 笔成功、20 笔失败、8 笔仍未知；因此只允许 20 笔按原业务身份重试，52 笔补记成功，8 笔进入后续查单与对账。若把 80 笔全部重试，潜在重复支付暴露量是正确策略的 4 倍，这正是失败链路必须先裁决再补偿的原因。

4. 容量、数据演绎与成本：第七至第八分钟让方案可复算

4.1 从业务量推到峰值、实例、队列、存储和预算

热门面试题

1. 问题：容量估算最小闭环包含哪些输入？
   • 考点：业务量、峰值模型、服务能力和冗余。
   • 回答思路：从日量、峰值集中度、请求放大、突增、单实例能力推导。
   • 详细答案：先给日业务量和峰值集中时长，再计算每个业务动作放大出的请求、消息和存储写入；乘突增与安全系数得到目标负载，再用压测校准的单实例稳定能力计算实例数。最后检查下游、连接池、队列和存储是否同步扩容，防止只扩入口。
   • 进阶追问：没有压测数据时能报实例数吗？
   • 进阶回答：只能给带假设的 E3（演练设计）区间，并明确单实例能力是最敏感参数，上线前必须压测替换。
2. 问题：消息积压如何估算恢复时间？
   • 考点：生产速率、消费速率和净消化能力。
   • 回答思路：用积压量除以恢复阶段的净消费速率。
   • 详细答案：若正常生产速率为每秒 800 条，恢复后总消费速率为每秒 2000 条，净消化能力为每秒 1200 条。120 万条积压理论需要 1000 秒，仍要加重试、下游限额和热点倾斜系数，并设置恢复时的业务保护阈值。
   • 进阶追问：为什么不能把消费者无限扩容？
   • 进阶回答：数据库写入、外部接口、分区数和顺序要求形成上限，盲目扩容会把积压转化为下游雪崩。
3. 问题：成本评审如何避免只比较机器单价？
   • 考点：总拥有成本、复杂度和退出代价。
   • 回答思路：同时计算计算、存储、流量、软件、运维、迁移和故障成本。
   • 详细答案：直接资源只是账单的一部分，还要估算双写双读、数据保留、跨地域流量、值班、升级、审计、供应商锁定和退出迁移。便宜组件若需要更多人工、恢复慢或破坏资金正确性，总成本可能更高；成本必须与业务风险和团队能力一起评审。
   • 进阶追问：怎样设置降本门禁？
   • 进阶回答：先定义性能、可用性和正确性护栏，只有降本后护栏不退化且退出可逆，才允许逐步扩大。

flowchart LR
    A[日业务量] --> B[峰值集中度]
    B --> C[请求与消息放大]
    C --> D[突增和安全系数]
    D --> E[目标吞吐]
    E --> F[单实例稳定能力]
    F --> G[实例与分区数量]
    G --> H[队列和存储增长]
    H --> I[资源与人力成本]
    I --> J{是否满足预算和护栏}
    J -->|否| B
    J -->|是| K[形成容量基线]

图解读：容量不是从机器规格反推业务，而是从业务量逐层推到资源与成本。预算不满足时必须回查峰值、放大系数、保留策略和服务能力，不能直接削掉安全冗余而不说明风险。

数据演绎 4：跨境履约容量与月成本

E3（演练设计）：假设日订单 120 万，35% 集中在 2 小时，每单正常链路产生 5 次内部请求，则基础峰值约 1200000×35%×5÷7200≈292 次每秒。乘 2 倍突增和 1.5 倍安全系数，目标为 876 次每秒；单实例稳定承载 180 次每秒，至少需要 5 个实例。若每实例月资源成本 1200 元，基础计算成本约 6000 元；再计消息、存储、流量和观测 9000 元，总直接成本约 15000 元，尚未包含值班与迁移人力。

5. 治理、观测与决策门禁：第九分钟说明如何长期守住设计

5.1 把一次性评审转成指标、权限、变更和退出机制

热门面试题

1. 问题：架构治理为什么不是增加审批层级？
   • 考点：决策一致性、自动门禁和团队自治。
   • 回答思路：区分控制目标与审批形式，强调可自动验证的护栏。
   • 详细答案：治理目标是让关键不变量、接口契约、数据所有权、安全、成本和退出条件持续可见。优先把规则做成测试、发布门禁、指标告警和变更记录；只有高风险、不可逆或跨团队决策才需要人工评审，避免所有变更都排队等待架构师批准。
   • 进阶追问：哪些决策必须留下记录？
   • 进阶回答：改变数据所有权、一致性、故障域、供应商依赖、重大成本或不可逆迁移的决策必须记录背景、候选、取舍、触发条件和退出路径。
2. 问题：技术指标怎样与业务结果关联？
   • 考点：观测分层、领先信号和业务验收。
   • 回答思路：从资源、服务、链路到业务守恒建立对应关系。
   • 详细答案：处理器、内存和连接池用于解释资源压力；延迟、错误率和积压反映服务表现；状态停留、账实差、资金差异、重复交付和严重告警未达才反映业务影响。评审应给出从技术异常到业务损失的映射，避免只对资源告警负责。
   • 进阶追问：指标很多如何避免告警风暴？
   • 进阶回答：按用户影响聚合，设置持续窗口、依赖抑制和分级路由；保留原始事件用于回放，严重业务信号不参与普通聚合。
3. 问题：如何评审一个方案的退出能力？
   • 考点：可逆性、兼容和供应商风险。
   • 回答思路：检查数据可导出、接口隔离、双轨期、回滚门禁和责任预算。
   • 详细答案：要求核心数据使用可迁移格式，供应商能力通过适配边界接入，新旧协议保持兼容窗口，迁移期有双写或影子验证，回滚触发值和存量处理明确。退出不是写一句“可替换”，而是估算数据量、停机、重放、差异修复与团队投入。
   • 进阶追问：双写是否天然更安全？
   • 进阶回答：不是；双写引入顺序、部分成功和差异修复成本，必须有主事实、幂等、对账与停止条件。

flowchart TD
    A[架构决策] --> B[记录约束与候选]
    B --> C[定义业务和技术护栏]
    C --> D[自动测试与发布门禁]
    D --> E[灰度观测]
    E --> F{护栏是否通过}
    F -->|否| G[停止扩大或回滚]
    F -->|是| H[扩大范围]
    H --> I[成本与风险复核]
    I --> J{达到退出或演进阈值}
    J -->|否| E
    J -->|是| K[进入迁移评审]

图解读：治理把评审结论变成持续门禁。方案上线后仍需在灰度、成本和风险之间循环校验；未通过护栏就停止扩大，达到演进阈值才进入迁移，而不是按日历被动重构。

数据演绎 5：IoT（物联网）告警治理护栏

E3（演练设计）：一分钟收到 12000 条原始告警，按设备、类型和 30 秒窗口聚合后形成 420 条普通通知，压缩率为 1-420÷12000=96.5%；其中 35 条严重告警走独立通道并逐条确认。若普通通知送达率从 99.5% 降至 97%，但严重告警仍全部送达，应先限速回放普通积压；若任何严重告警未达，则立即停止聚合规则扩大并切换旁路。治理门禁由业务级别决定，不由总体压缩率单独决定。

6. 迁移、复盘与十分钟收束：第十分钟给出下一步

6.1 用分阶段迁移、业务验收和复盘行动完成评审闭环

热门面试题

1. 问题：迁移方案最少要包含哪几个阶段？
   • 考点：兼容、影子验证、灰度、切换和退场。
   • 回答思路：按准备、复制、校验、灰度、切换、观察、清理展开。
   • 详细答案：先建立兼容接口和回滚开关，再做存量复制与增量同步；通过影子读写或差异对账校验；按租户、仓库、渠道或任务类型灰度；满足门禁后切换主路径；保留观察窗和旧路径；最后才清理旧数据与代码。不可逆动作必须排在证据充分之后。
   • 进阶追问：灰度维度怎么选？
   • 进阶回答：选择业务可隔离、影响可统计、数据边界清晰且能独立回滚的维度，避免随机流量把同一业务实体拆到两套裁决路径。
2. 问题：架构复盘与事故复盘有什么区别？
   • 考点：决策质量、假设校准和系统改进。
   • 回答思路：说明架构复盘既覆盖事故，也覆盖未出事故但假设失效的决策。
   • 详细答案：事故复盘关注一次故障的时间线、影响、原因和改进；架构复盘还要检查原约束是否变化、容量假设是否准确、替代方案是否该启用、技术债利息是否上升，以及治理门禁是否真正执行。没有事故也可以因成本、增长或组织边界变化触发复盘。
   • 进阶追问：复盘行动如何避免长期挂起？
   • 进阶回答：每项行动绑定负责人、期限、验收信号和优先级；能自动化的进入门禁，不能立即解决的风险进入有到期日的风险账本。
3. 问题：十分钟结束时怎样让面试官愿意继续追问？
   • 考点：结论收束、事实边界和追问控制。
   • 回答思路：重申不变量、关键取舍、最大风险、验证状态和三个可展开入口。
   • 详细答案：最后用二十到三十秒说明方案守住什么、为此牺牲什么、哪个风险尚未关闭、上线或演练如何验收，并明确数字和职责的证据等级。随后提供容量推导、故障恢复、迁移治理三个可验证入口，停下来等待追问，不继续堆技术名词。
   • 进阶追问：方案仍有未知项会减分吗？
   • 进阶回答：不会天然减分；准确标注未知、说明影响和取证路径，比给出无法验证的确定答案更体现评审判断。

flowchart LR
    A[兼容准备] --> B[存量复制与增量同步]
    B --> C[影子验证与差异对账]
    C --> D[按业务边界灰度]
    D --> E{业务门禁通过}
    E -->|否| F[回滚并修复差异]
    F --> C
    E -->|是| G[切换主路径]
    G --> H[观察窗与旧路径保留]
    H --> I[清理旧实现]
    I --> J[复盘假设、成本与风险]

图解读：迁移的核心是把不可逆动作后置。影子验证和灰度都必须按业务边界进行，门禁失败可回到校验阶段；旧路径只在观察窗完成、差异清零和复盘通过后退场。

数据演绎 6：Runner（执行器）调度迁移

E3（演练设计）：现有 5000 个周期任务，先选 5% 的低风险任务进入新调度，共 250 个；观察 24 小时产生 12000 次执行，发现 6 次新旧结果差异，差异率为 6÷12000=0.05%，高于零差异门禁，因此不扩大。修复代次校验后再观察 24000 次执行，差异为零，才扩到 25%。若接管时长从 20 秒升到 75 秒并超过 60 秒门禁，即使结果正确也应回滚，因为可用性假设尚未成立。

7. 十分钟架构评审综合题库

1. 问题：请完整演示一次十分钟架构评审，你会怎样分配时间并保证结论可验证？

   • 考点：时间盒、需求约束、正常链路、失败恢复、容量成本和收束。
   • 回答思路：按一分钟澄清、三分钟正常流、两分钟失败、两分钟容量成本、一分钟治理、一分钟迁移复盘展开。
   • 详细答案：十分钟不是逐页念图，而是围绕一个业务不变量完成从约束到验收的决策闭环。每段都要给出输入、判断、风险和证据，数字必须区分生产事实与 E3（演练设计）。
   • 进阶追问：面试官中途打断怎么办？
   • 进阶回答：先直接回答当前问题，再用一句话回到原主线；若剩余时间不足，优先保留失败恢复和业务验收。
   • 口述答案：我会先用一句话定题，例如“本次评审要在峰值波动和依赖故障下守住库存数量或资金可对平”。第一分钟只澄清参与者、范围、核心不变量、峰值量级、允许延迟、故障退化和验收口径，同时把未知数字标成 E3（演练设计）或 E0（待核对）。第二到第四分钟看总图：先划系统内外边界，再沿唯一业务身份经过入口、领域裁决、权威存储、异步传播和下游幂等，明确谁能改变最终状态，缓存和 MQ（消息队列）为什么不是权威事实。第五到第六分钟主动注入一个最高成本故障，按发现、止血、定位、修复、小批恢复、业务守恒验收展开；其他故障只列追问入口。第七到第八分钟从日量、峰值集中度、请求放大、突增系数推到目标吞吐，再用单实例稳定能力计算副本，并补积压恢复、存储增长和总成本，强调上线前由压测替换假设。第九分钟讲治理，把数据所有权、接口兼容、发布门禁、业务指标、成本预算和退出条件固化，而不是增加无差别审批。第十分钟给迁移阶段、回滚阈值和复盘动作，最后重申方案守住什么、牺牲什么、最大未知是什么，并邀请继续追问容量、故障或迁移。这样即使被打断，前六分钟也已经形成最小完整闭环，后四分钟只是补可复算与长期治理证据。 现场口述时我还会补一句：这里给出的数字、阈值和归因都要按 E1（直接证据）、E2（材料映射）、E3（演练设计）或 E0（待核对）分级，能证明的才说成项目事实，不能证明的只作为设计推导；如果面试官继续追问，我会优先展开最能证明判断力的主链路、失败恢复和业务验收，而不是临时堆更多组件名。
   • 追问/直答（4 组）：①图太复杂怎么办？只保留改变所有权、故障域和一致性的节点；②数字不确定怎么办？给区间、公式和核对路径；③为什么失败段优先？它最能检验边界和恢复；④如何防超时？每段录音计时，超时先删背景和组件枚举。
   • 详细链接：架构项目口述与综合题库

2. 问题：面对一句“做一个高可用订单系统”，你如何在一分钟内完成需求澄清？

   • 考点：模糊需求拆解、质量场景、量级假设和范围控制。
   • 回答思路：先问业务不变量，再问规模、时效、故障退化、上下游和验收。
   • 详细答案：高可用必须落到具体业务场景，不能只报可用率。评审要把触发者、负载、响应、异常环境和验收指标补齐，并明确本次不解决的范围。
   • 进阶追问：业务方只说“越快越好”怎么办？
   • 进阶回答：用用户等待、依赖时限和失败成本反问，形成分级时效，而不是承诺没有成本边界的最低延迟。
   • 口述答案：我不会先问用什么框架，而会把“高可用订单系统”改写成可验证场景。先确认订单是什么业务意图，创建成功的权威标志是数据库记录、外部受理号还是资金结果；再问哪些错误绝不能发生，例如重复下单、库存超卖、重复支付或取消后继续履约。范围上确认本次覆盖创建、支付、履约中的哪一段，哪些外部渠道只作为依赖。规模上询问日订单、峰值集中时段、热点租户、单订单放大的同步调用和异步事件；没有数字时给低中高三档 E3（演练设计），并标出会影响分片和副本的敏感项。时效上把“快”拆成受理时限、最终完成时限和人工介入时限。故障上问数据库、MQ（消息队列）、支付渠道或承运商不可用时，系统允许拒绝、排队、降级还是继续接受请求，以及最多可丢多少数据、多久恢复。上下游方面确认唯一业务身份由谁生成，重试责任属于谁，状态回写和对账由谁裁决。最后定义验收：接口成功率只是技术信号，业务还要看订单唯一、状态不倒退、库存与资金守恒、积压在时限内收敛。若一分钟只够三个问题，我会问“什么绝不能错、峰值多大、依赖失败后允许怎样退化”。输出是一张约束与未知清单，而不是假装需求已经完全确定。 现场口述时我还会补一句：这里给出的数字、阈值和归因都要按 E1（直接证据）、E2（材料映射）、E3（演练设计）或 E0（待核对）分级，能证明的才说成项目事实，不能证明的只作为设计推导；如果面试官继续追问，我会优先展开最能证明判断力的主链路、失败恢复和业务验收，而不是临时堆更多组件名。
   • 追问/直答（4 组）：①可用率怎么问？问具体业务窗口和允许失败次数；②范围冲突怎么办？以核心不变量和本次验收切边界；③未知项能开工吗？可逆设计可先行，不可逆决策必须等取证；④谁批准降级？业务与技术共同指定权限人。
   • 详细链接：需求约束与量级澄清

3. 问题：请按十分钟模板评审 WMS（仓储管理系统）库存防超卖方案。

   • 考点：库存守恒、并发裁决、热点容量、补偿对账和灰度。
   • 回答思路：以数量不变量为主线，讲正常扣减、重复与超时、容量、治理和迁移。
   • 详细答案：缓存和锁可以优化性能，但数据库条件更新、库存流水和对账才构成最终正确性底线。取消释放必须关联原扣减并保持幂等。
   • 进阶追问：有 Redis（远程字典服务）锁为什么还会超卖？
   • 进阶回答：锁可能超时、失效、覆盖范围不全或主从切换，数据库条件更新仍需做最终裁决。
   • 口述答案：这次评审的核心不变量是可售、冻结、已出库与实物能够守恒，不能因为并发、重复请求或补偿把库存凭空增加。范围先限定为订单预占到取消释放，不展开仓内盘点。正常链路中，入口为每次预占生成稳定业务键，热点库存可在 Redis（远程字典服务）做预检查和削峰，但权威事实仍在 MySQL（关系型数据库）；库存服务通过“可售数量足够且版本匹配”的条件更新完成最终裁决，并在同一事务写预占流水，提交后再通过 MQ（消息队列）传播结果。消费者按业务键和版本幂等，取消时必须引用原预占流水，只释放尚未释放的数量。最高成本故障是请求超时后上游重试，同时旧请求已经成功，或者取消消息重复造成多次释放。止血时限制热点流量、暂停自动释放；定位时核对业务键、库存版本、预占流水和消费记录；恢复后复算数量守恒。E3（演练设计）假设日订单 100 万，40% 集中两小时，每单两次库存操作，基础峰值约 111 次每秒，乘突增和冗余后按 400 次每秒准备，再用压测确定实例和数据库写入能力。治理上监控热点库存冲突率、预占超时、消息积压和账实差。迁移按仓库灰度，新旧路径影子对账，数量差异必须为零才能扩大；回滚时保留新流水，不允许直接删除事实。最终我会说明缓存用于性能、数据库用于裁决、流水用于恢复、对账用于证明闭环。 现场口述时我还会补一句：这里给出的数字、阈值和归因都要按 E1（直接证据）、E2（材料映射）、E3（演练设计）或 E0（待核对）分级，能证明的才说成项目事实，不能证明的只作为设计推导；如果面试官继续追问，我会优先展开最能证明判断力的主链路、失败恢复和业务验收，而不是临时堆更多组件名。
   • 追问/直答（4 组）：①缓存挂了怎么办？限流后走受控数据库路径；②消息丢了怎么办？提交后事件表或日志可重放；③何时分片？单库写入、数据量和维护窗口持续越线时；④恢复验收？按库存单位复算可售、冻结、出库和实物。
   • 详细链接：库存预占与对账方案

4. 问题：请口述跨境物流面单与轨迹链路的架构图，并解释正常链路如何防重和防乱序。

   • 考点：外部依赖、业务身份、状态机、版本、隔离和人工裁决。
   • 回答思路：从订单意图到承运商适配、面单权威记录、轨迹事件和异常队列展开。
   • 详细答案：同一业务意图只能有一个有效面单；外部超时不能直接重建。轨迹按事件时间、状态序和版本推进，异常进入隔离而不是覆盖新状态。
   • 进阶追问：承运商没有幂等接口怎么办？
   • 进阶回答：本地先锁定业务键与请求记录，超时后优先查单；必须重试时复用外部参考号，并设置重复面单裁决流程。
   • 口述答案：我会先在图上划清本系统、海外仓和承运商边界，核心不变量是一个订单履约意图只有一个有效下游结果，取消后不能被迟到事件重新激活。入口接收订单、仓库、线路和地址信息，先做合规与完整性校验，再生成稳定业务键。履约服务创建本地请求记录和状态版本，通过承运商适配层调用外部接口；适配层负责协议、签名、限额和错误分类，但不拥有业务状态。外部成功后，本地保存面单号、标签地址和原始响应摘要，再发布履约事件。若调用超时，状态进入“结果未知”，不能立刻创建第二张面单，而是按业务键和外部参考号查单；确认失败后才允许重试。轨迹回调先验签和防重放，再按面单、事件时间、状态序和版本处理，旧事件进入审计记录但不倒退主状态。正常查询优先读本地投影，关键裁决回到履约主记录。容量上按订单峰值、每单承运商调用和轨迹放大估算，外部限额往往比本地实例更早成为瓶颈，因此要有按承运商隔离的队列与限速。故障时保护未决请求，暂停自动重建，恢复靠查单、回调和账单交叉确认。迁移按承运商或国家线路灰度，门禁是重复面单率为零、未知态在时限内收敛、轨迹延迟可接受。这样架构图讲的是所有权和裁决，不是接口罗列。 现场口述时我还会补一句：这里给出的数字、阈值和归因都要按 E1（直接证据）、E2（材料映射）、E3（演练设计）或 E0（待核对）分级，能证明的才说成项目事实，不能证明的只作为设计推导；如果面试官继续追问，我会优先展开最能证明判断力的主链路、失败恢复和业务验收，而不是临时堆更多组件名。
   • 追问/直答（4 组）：①轨迹永久乱序怎么办？状态序不倒退，原始事件可审计；②标签下载失败怎么办？面单成功与文件交付分状态恢复；③外部限流怎么办？分承运商排队并按剩余额度调度；④人工何时介入？未知态超过业务时限或多源冲突时。
   • 详细链接：跨境履约与异常恢复

5. 问题：请评审支付资金一致性方案，重点讲渠道超时未知的失败链路。

   • 考点：支付身份、验签回调、主动查单、账务流水、对账和补偿。
   • 回答思路：以资金可对平为不变量，区分本地状态、渠道状态和账务结果。
   • 详细答案：超时未知不能等同失败。系统必须复用支付业务身份，通过查单、验签回调和渠道账单裁决，再由幂等账务分录完成资金确认。
   • 进阶追问：为什么回调成功还要对账？
   • 进阶回答：回调可能丢失、重复、延迟或被错误处理，渠道账单是发现长期单边差异的独立证据。
   • 口述答案：支付评审先声明不变量：支付本金、手续费、退款、账户分录和渠道结果最终可对平，同一支付意图不能重复扣款或重复入账。正常链路中，业务先创建内部支付单和唯一支付身份，本地状态机校验可支付后调用渠道；请求签名、密钥和重放防护由渠道适配层处理。渠道明确成功时，本地以支付身份和渠道流水做幂等确认，在本地事务写支付状态与账务分录，再发布后续事件。真正危险的是网络超时：渠道可能已经扣款，本地却没有结果，所以状态必须进入处理中或未知，禁止换新身份盲重试。恢复链路先按原身份主动查单，同时接收经过验签、防重放和版本校验的回调；两者冲突时依据渠道协议、交易号和最终账单裁决，无法确认的进入隔离与人工复核。E3（演练设计）中，10000 笔请求有 80 笔超时，查单确认 52 笔成功、20 笔失败、8 笔仍未知，只能重试确认失败的 20 笔。容量不仅看入口吞吐，还要看渠道限额、查单速率、回调波峰和对账窗口。治理指标包括未知态数量与停留时长、重复回调、账务分录冲突和渠道差异。迁移按支付渠道或商户灰度，资金差异必须为零，旧路径保留到完整对账周期结束。最终验收不是接口恢复，而是支付单、渠道账单和资金流水三方闭环。 现场口述时我还会补一句：这里给出的数字、阈值和归因都要按 E1（直接证据）、E2（材料映射）、E3（演练设计）或 E0（待核对）分级，能证明的才说成项目事实，不能证明的只作为设计推导；如果面试官继续追问，我会优先展开最能证明判断力的主链路、失败恢复和业务验收，而不是临时堆更多组件名。
   • 追问/直答（4 组）：①回调先于同步响应？按同一支付身份幂等裁决；②查单也超时？保持未知并退避，不改变资金结论；③重复入账怎么防？业务唯一约束加分录幂等；④退款如何处理？独立退款单与分录，对原支付可追溯。
   • 详细链接：支付正确性与对账恢复

6. 问题：请评审大文件异步导出方案，如何同时控制内存、重复执行和交付成本？

   • 考点：任务快照、分片流式处理、资源隔离、幂等交付和过期清理。
   • 回答思路：从同步转异步的约束讲到任务状态、分片执行、对象存储、通知与恢复。
   • 详细答案：任务受理与文件生成分离，查询条件需要固化为快照语义；执行采用分片与流式写出，结果按任务版本唯一发布，资源与在线请求隔离。
   • 进阶追问：为什么不能直接增加 JVM（Java 虚拟机）内存？
   • 进阶回答：更大堆只推迟内存溢出并增加垃圾回收停顿，无法解决无界数据、并发导出和下游写入背压。
   • 口述答案：异步导出评审的目标不是“把接口改成任务”，而是确保大数据量下在线服务不被拖垮、同一任务只交付一个有效结果、用户看到的内容具有明确快照语义。入口校验查询范围、权限和预计数据量，生成任务号与请求指纹，重复请求可复用未过期任务。任务记录保存条件、数据截止点、状态和版本；调度后按主键范围或时间范围分片，工作进程用游标分页和流式写出，避免把全部数据放进 JVM（Java 虚拟机）堆。分片结果进入临时区域，只有全部分片完成且行数、校验值通过，才合并或发布最终对象，并以条件更新把任务状态切成成功。最高成本故障是工作进程重启导致重复分片、旧执行者迟到覆盖新结果，或临时文件泄漏。处理方式是分片幂等、任务版本与结果路径绑定、发布前条件校验，失败文件由延迟清理回收。容量按并发任务、单任务扫描速率、数据库读取上限、文件写入和网络带宽联合估算；排队时间超过目标时优先按租户配额和任务优先级治理，而不是无限扩消费者。成本要计存储保留、下载流量、重复结果和清理任务。迁移按任务类型灰度，门禁是在线查询延迟不退化、结果行数正确、同一任务只有一个可下载文件，回滚只停止新任务进入新路径，已生成结果继续按版本交付。 现场口述时我还会补一句：这里给出的数字、阈值和归因都要按 E1（直接证据）、E2（材料映射）、E3（演练设计）或 E0（待核对）分级，能证明的才说成项目事实，不能证明的只作为设计推导；如果面试官继续追问，我会优先展开最能证明判断力的主链路、失败恢复和业务验收，而不是临时堆更多组件名。
   • 追问/直答（4 组）：①数据期间变化怎么办？固定截止点或数据库快照语义；②分片顺序重要吗？按最终排序要求合并；③下载链接如何安全？短时授权并校验任务所有者；④何时拒绝任务？超范围、资源配额耗尽或预计无法在时限完成时。
   • 详细链接：异步导出与内存隔离

7. 问题：请评审 Runner（执行器）调度方案，如何防止旧持有者迟到提交？

   • 考点：租约、代次栅栏、心跳、接管、幂等结果和迁移。
   • 回答思路：以当前代次才能提交为不变量，说明分派、续租、失联接管和结果裁决。
   • 详细答案：租约只证明一段时间内的持有权，无法阻止暂停后的旧进程恢复。每次接管必须增加代次，结果写入比较代次并拒绝旧提交。
   • 进阶追问：有分布式锁还需要代次吗？
   • 进阶回答：需要；锁过期后旧持有者可能继续运行，代次在最终资源写入点阻止它产生副作用。
   • 口述答案：Runner（执行器）调度的核心不变量是同一任务的当前代次只有一个有效持有者能够提交结果，至少一次执行可以接受，但旧持有者的副作用不能被接受。正常链路中，调度中心按任务约束选择执行器，原子写入租约、到期时间和递增代次；Runner（执行器）领取后携带任务号与代次执行，周期心跳只续当前代次。结果提交时，任务表或下游资源必须比较代次和状态，只有当前代次可以从运行中切到成功。故障链路中，执行器可能经历长暂停或网络隔离，租约到期后新执行器以更高代次接管；旧执行器恢复并提交时会被栅栏拒绝。止血可暂停新分派、缩短问题执行器的任务范围；定位要查租约变化、心跳、接管记录和结果版本；恢复后确认没有旧代次成功写入。容量按任务到达率、平均执行时长和并发槽位估算，并区分处理器密集、输入输出密集和外部限额任务，避免统一队列相互阻塞。治理包括租约过期率、接管时长、重复执行率、旧代次拒绝数和任务停留时长。迁移按执行器池或任务组灰度，先影子比较分派结果；E3（演练设计）中 5000 个任务先迁 250 个，任何结果差异或接管超过门禁都停止扩大。代次不是只存在调度表里，它必须传到真正发生副作用的写入边界才有效。 现场口述时我还会补一句：这里给出的数字、阈值和归因都要按 E1（直接证据）、E2（材料映射）、E3（演练设计）或 E0（待核对）分级，能证明的才说成项目事实，不能证明的只作为设计推导；如果面试官继续追问，我会优先展开最能证明判断力的主链路、失败恢复和业务验收，而不是临时堆更多组件名。
   • 追问/直答（4 组）：①时钟漂移怎么办？由中心存储裁决到期并保留安全余量；②任务不可幂等怎么办？外部副作用前检查代次并设计人工补偿；③心跳多频繁？小于租期且结合负载与误判成本；④调度中心故障？多副本但共享一致裁决存储。
   • 详细链接：调度租约与恢复方案

8. 问题：请评审 IoT（物联网）报警风暴治理，如何降噪又不漏严重事件？

   • 考点：事件身份、分级通道、窗口聚合、背压、回放和反馈抑制。
   • 回答思路：先区分严重与普通事件，再讲接入、聚合、通知、处置和恢复。
   • 详细答案：严重告警走独立低延迟通道并逐条确认；普通告警可按设备、类型和窗口聚合。原始事件保留，聚合结果可解释、可回放。
   • 进阶追问：聚合率越高越好吗？
   • 进阶回答：不是；压缩率必须受严重告警零漏达、通知时延和处置效果护栏约束。
   • 口述答案：IoT（物联网）报警治理的核心不变量是降噪不能牺牲严重事件可达性，也不能让聚合掩盖持续恶化。入口先为事件生成设备、类型、发生时间和序列组成的稳定身份，完成鉴权、时间校正和基础去重。事件按等级分流：严重级进入独立通道，逐条通知、确认和升级；普通级进入按设备、类型、区域和时间窗的聚合，输出首发、持续、恢复和计数摘要。原始事件写入可回放存储，聚合状态保存窗口版本，迟到事件按规则更新但不能把已恢复状态错误复活。风暴发生时，系统优先保护接入和严重通道，对普通通知限流、合并并施加背压；若下游不可用，先积压可恢复事件，不让同步重试拖垮入口。E3（演练设计）中，一分钟 12000 条原始事件聚合为 420 条普通通知，压缩率 96.5%，另有 35 条严重告警逐条送达。评审不能只展示压缩率，还要看严重告警漏达、通知时延、积压年龄、聚合误抑制和人工处置量。恢复时按事件等级和发生时间限速回放，避免第二次风暴；治理规则按设备组灰度，任何严重漏达立即停止扩大。成本既包括消息、存储和通知通道，也包括值班人员被无效告警打断的时间。最终通过原始事件、聚合通知和处置记录三者关联，证明降噪过程可解释。 现场口述时我还会补一句：这里给出的数字、阈值和归因都要按 E1（直接证据）、E2（材料映射）、E3（演练设计）或 E0（待核对）分级，能证明的才说成项目事实，不能证明的只作为设计推导；如果面试官继续追问，我会优先展开最能证明判断力的主链路、失败恢复和业务验收，而不是临时堆更多组件名。
   • 追问/直答（4 组）：①设备时间不准？使用接收时间辅助并记录偏差；②重复事件怎么识别？稳定身份加窗口内去重；③恢复通知重要吗？重要，它关闭事件生命周期并防持续误报；④规则误抑制怎么办？停用规则、回放原始事件并复盘样本。
   • 详细链接：告警风暴与恢复方案