需求、约束、质量场景与量级澄清
本册定位:架构设计先回答“要解决什么问题、不能违反什么、如何证明达成”,再讨论技术。文中 WMS(仓储管理系统)、支付、跨境物流、Runner(执行器)和 IoT(物联网)均为 E2(已有材料映射);没有生产测量证据的数值均为 E3(演练证据),不可表述为已上线事实。
1. 先问题后技术:把业务语言变成设计输入
1.1 目标、角色、用例与成败边界
架构师先问业务目标的受益者、可观察结果和截止时间。角色不只包括发起人,还包括仓库操作员、客服、财务、审计、运维和外部合作方;每个角色都有正常路径、拒绝路径与人工兜底。成功不是“接口返回成功”,而是业务事实在约定时间内可被正确消费;失败则要明确谁发现、谁止损、谁恢复。
| 角色 | 用例 | 成功证据 | 失败边界 | 验收人 |
|---|---|---|---|---|
| 仓库操作员 | 提交拣货确认 | 库存与作业状态一致 | 重复扫描不重复扣减 | 仓储负责人 |
| 买家 | 发起支付 | 支付单可追溯到账务 | 回调未知态不可误判成功 | 财务负责人 |
| 客服 | 查询轨迹 | 状态来源与更新时间可解释 | 外部延迟不得伪造完成 | 客服负责人 |
| 审计人员 | 导出记录 | 操作、授权、版本可还原 | 越权与篡改可发现 | 合规负责人 |
sequenceDiagram
participant 业 as 业务负责人
participant 架 as 架构师
participant 仓 as 仓库角色
participant 财 as 财务角色
业->>架: 目标、期限、损失
架->>仓: 正常与例外用例
架->>财: 成功事实与失败止损
仓-->>架: 重扫、撤销、人工处理
财-->>架: 未知态、对账、审计
架-->>业: 可验收的结果清单数据演绎 1:把“高峰不卡”改成验收目标
E3(演练证据):若仓库 30 个工位在交班前 10 分钟各完成 25 次确认,则请求量为 30 × 25 = 750 次,均匀每秒为 750 / 600 = 1.25 次;但操作常集中在最后 90 秒,演练峰值按 750 / 90 = 8.34 次/秒估算。验收不能写“不卡”,应写“8.34 次/秒输入下,合法确认 99% 在 1 秒内得到可解释结果,拒绝也有明确原因”。
热门面试题
- 问题:为什么不能一听到需求就先选技术?
- 考点:问题定义。
- 回答思路:先定义价值、角色、事实和边界。
- 详细答案:技术只能实现约束,不能替业务做取舍。先将谁要完成什么、什么算完成、失败损失是什么写成用例,才能判断同步还是异步、强校验还是事后补偿;否则“用了缓存或消息队列”没有正确性语义。
- 进阶追问:目标彼此矛盾怎么办?
- 进阶回答:把冲突显式升级给业务负责人,记录优先级、牺牲项和验收阈值,不由技术人员暗中决定。
- 问题:接口成功与业务成功有什么区别?
- 考点:事实边界。
- 回答思路:接口仅表示本地处理完成。
- 详细答案:支付受理成功不等于资金入账,轨迹接收成功不等于承运商已履约。业务成功必须落在可核验状态与责任主体上,并定义未知态的查询、对账或人工路径。
- 进阶追问:如何验收未知态?
- 进阶回答:验收其进入可查询状态、自动查证时限、人工队列和最终对账闭环,而非强行要求立刻给成功或失败。
- 问题:角色分析为什么是架构输入?
- 考点:权限与例外。
- 回答思路:角色决定操作、数据和恢复权。
- 详细答案:同一订单对仓库、客服和财务展示不同事实与权限。遗漏审计或客服角色会使异常只能查库处理,最终把业务恢复能力变成开发人员个人经验。
- 进阶追问:外部合作方算角色吗?
- 进阶回答:算。其超时、重复、乱序和不可用都是系统边界条件,必须写到契约和失败路径中。
1.2 业务不变量与状态机
不变量是无论重试、并发、延迟、故障还是人工操作都不能被突破的业务事实。WMS(仓储管理系统)的可售库存不得小于零;支付的一笔外部交易不得对应两笔成功入账;跨境物流的状态不可倒退到已经失效的状态。先写不变量,才知道哪些操作必须串行、幂等或对账。
| 领域 | 不变量 | 允许的暂时不一致 | 不允许的错误 | 证明方式 |
|---|---|---|---|---|
| 库存 | 已确认扣减不超过可用量 | 查询投影短暂滞后 | 负库存与重复扣减 | 条件更新、流水对账 |
| 支付 | 一笔支付唯一入账 | 通知稍后到达 | 重复记账、金额错配 | 幂等键、账务核对 |
| 物流 | 状态转移符合规则 | 轨迹展示延迟 | 无来源的完成状态 | 来源、版本、状态机 |
| 调度 | 同一租约仅一名执行者生效 | 心跳观测延迟 | 并发副作用重复提交 | 栅栏、执行记录 |
sequenceDiagram
participant 客 as 客户端
participant 库 as 库存服务
participant 账 as 库存流水
participant 对 as 对账任务
客->>库: 确认扣减(请求标识)
库->>库: 校验可用量与状态
alt 条件满足
库->>账: 写唯一流水
库-->>客: 已确认
else 不满足或重复
库-->>客: 拒绝或返回既有结果
end
对->>账: 比对库存余额与流水数据演绎 2:库存不变量的并发验算
E3(演练证据):可用量为 100,两个请求各扣 60。若先读后写,两个请求都读到 100,结果可能写成 40 且已承诺 120;若条件更新为 available >= 60 才扣减,第一个后余 40,第二个条件失败,承诺量为 60 ≤ 100。这里证明的是约束,不证明某产品的真实吞吐。
热门面试题
- 问题:如何从需求中找不变量?
- 考点:领域建模。
- 回答思路:追问“绝不能发生什么”。
- 详细答案:把正常、重试、并发、超时、人工补单都代入业务规则;任何场景都不能突破的量、状态或唯一性就是不变量。它应由数据约束、状态转换和对账共同证明。
- 进阶追问:不变量能只放在前端吗?
- 进阶回答:不能。前端只能改善体验,可信边界必须在服务或权威数据侧,并可被离线核验。
- 问题:为什么幂等不是不变量的全部?
- 考点:重复与正确。
- 回答思路:幂等只抑制同一请求的重复副作用。
- 详细答案:不同请求仍可能同时突破库存或金额边界;幂等键还可能错误复用。因此还需状态校验、条件更新、唯一约束和对账来共同守住业务事实。
- 进阶追问:对账能替代在线校验吗?
- 进阶回答:不能。对账擅长发现并补偿已发生差异,在线校验负责阻止不可接受的错误承诺。
- 问题:状态机的价值是什么?
- 考点:合法转移。
- 回答思路:限制状态与事件组合。
- 详细答案:状态机把“是否允许”变成可审计规则,处理乱序、重复与撤销时能说明原因;没有它,多个接口会以临时条件互相改写状态。
- 进阶追问:外部状态乱序如何处理?
- 进阶回答:保存来源事件标识和版本,只接受合法的前向转移;无法判定的进入待核验队列。
1.3 功能、非功能与验收口径
功能需求描述系统做什么,非功能需求描述在什么条件下以何种质量做成。后者不能只写“高可用、低延迟、安全”,而应落为可测的质量属性场景:刺激源、刺激、环境、受影响物、响应、响应度量六要素。
| 类型 | 模糊说法 | 可验证改写 | 证据 | | --- | --- | --- | | 功能 | 支持取消导出 | 已开始分片的任务可停止后续分片并标记清理范围 | 状态记录与演练 | | 性能 | 查询要快 | 峰值输入下 95% 查询在 300 毫秒内返回 | 压测报告 | | 可用性 | 不能挂 | 单节点失效时合法写入进入受控拒绝或切换路径 | 故障演练 | | 安全 | 数据要保密 | 导出前校验主体、字段权限、审计记录 | 权限测试 |
sequenceDiagram
participant 产 as 生产者
participant 系 as 系统
participant 监 as 监控
participant 值 as 值班人员
产->>系: 峰值请求或节点故障
系->>系: 执行受控响应
系->>监: 记录延迟、错误、队列
监-->>值: 阈值越界告警
值->>系: 验证降级或恢复
值-->>产: 验收结果与证据数据演绎 3:质量场景的六要素验算
E3(演练证据):刺激源为“承运商”,刺激为“连续 5 分钟超时”,环境为“订单高峰”,受影响物为“轨迹同步”,响应为“切换重试队列并展示延迟”,度量为“10 分钟内未确认轨迹进入人工可见列表”。六项缺任一项,就无法设计测试或确认责任。
热门面试题
- 问题:功能需求和质量属性为什么要分开?
- 考点:验收边界。
- 回答思路:一个定义能力,一个定义能力在压力下的表现。
- 详细答案:功能“能下单”并不说明高峰、故障或越权下仍正确。分开后才可将同一功能映射到性能、恢复、安全与成本验收,不会把质量承诺藏在口头描述里。
- 进阶追问:非功能需求谁负责?
- 进阶回答:业务负责人确认损失与优先级,架构与交付团队把它转为可测试场景,运维和安全共同确认观测与控制证据。
- 问题:质量属性场景六要素是什么?
- 考点:可验证性。
- 回答思路:依次给出源、刺激、环境、对象、响应、度量。
- 详细答案:六要素迫使“高可用”落地为一个可复现事件与阈值,也能区分正常容量与灾难恢复,避免用一条泛泛的服务目标覆盖所有业务链路。
- 进阶追问:度量缺失会怎样?
- 进阶回答:团队无法判断达标、告警和回退时机,最后只能靠主观感受宣布上线成功。
- 问题:验收为什么要包含失败路径?
- 考点:可靠性设计。
- 回答思路:生产故障必然发生。
- 详细答案:只验正常路径会掩盖超时重试、重复消息、权限失效和恢复缺口。失败验收应检查系统是否保护不变量、留下证据并可回退或补偿。
- 进阶追问:失败测试会影响业务吗?
- 进阶回答:先在隔离环境演练,再通过小范围、可撤销和受监控的方式进入生产,不以无控制的故障注入替代验证。
2. 把量级与质量属性变成可复算的边界
2.1 流量峰谷、读写比例与并发
平均值会掩盖交班、促销、批处理和外部回调的尖峰。澄清时分别记录入口请求、有效业务请求、重试放大、读写比例、连接并发与异步积压;每个值都要有时间窗口、来源、置信等级和复算式。
| 指标 | 必问问题 | 复算式 | 常见误判 |
|---|---|---|---|
| 峰值输入 | 峰持续多久、是否同一热点 | 总量除以集中窗口 | 用日均值代替峰值 |
| 写入量 | 一次动作写几份事实 | 请求量乘写放大倍数 | 忽略流水与审计 |
| 读取量 | 列表、轮询、重试各多少 | 用户数乘频率 | 把缓存命中当源库读 |
| 并发 | 请求停留多久 | 到达率乘停留时间 | 只看线程数 |
sequenceDiagram
participant 业 as 业务方
participant 架 as 架构师
participant 运 as 运行团队
participant 数 as 数据负责人
业->>架: 峰谷、活动、截止时间
架->>运: 当前连接、队列、资源水位
架->>数: 历史量、增长、保留期
运-->>架: 监测口径与缺口
数-->>架: 来源与抽样范围
架-->>业: E3演练假设和待核对项数据演绎 4:读写与重试放大
E3(演练证据):某库存活动入口峰值为 120 次/秒,平均每次读取商品与库存各一次,读量为 120 × 2 = 240 次/秒;成功写入占 70%,每笔写主记录、流水、事件三份,写操作为 120 × 0.7 × 3 = 252 次/秒。若 5% 超时且只重试一次,额外入口为 120 × 0.05 = 6 次/秒;不可把它悄悄并入成功吞吐。
热门面试题
- 问题:为什么日订单量不能直接推出峰值?
- 考点:时间分布。
- 回答思路:订单并不均匀到达。
- 详细答案:活动、交班与截止时间会把一天的量压缩到短窗口。设计应采用明确窗口的峰值和安全余量,并说明该值是观测、预测还是 E3(演练证据)。
- 进阶追问:没有历史数据怎么办?
- 进阶回答:用业务人数、操作频率和最短集中窗口建立可复算假设,标出待补采的日志、埋点和压测证据。
- 问题:读写比例为什么不够?
- 考点:放大效应。
- 回答思路:一次业务动作可能触发多次读写。
- 详细答案:还需区分主事实、索引、流水、审计、缓存失效和重试。把所有读写归成一个比例会掩盖权威存储的写压力与异步副本的积压风险。
- 进阶追问:重试为何要单列?
- 进阶回答:超时期间重试会在系统最脆弱时放大负载,单列才能设计限次、退避、幂等与熔断阈值。
- 问题:如何解释并发与吞吐的关系?
- 考点:排队直觉。
- 回答思路:并发约等于到达率乘停留时间。
- 详细答案:吞吐不变时,尾延迟上升会抬高在途请求,进而耗尽连接与线程;因此不能仅以每秒请求数证明容量充足。
- 进阶追问:高并发一定是坏事吗?
- 进阶回答:不是。可控的异步排队是容量缓冲;失去上限、优先级和恢复估算的排队才会转为业务延迟与雪崩。
2.2 数据量、增长、保留与地域
数据规模要按实体、字段大小、索引、副本、审计、备份和保留期拆开。地域不是部署名词,而是用户位置、数据驻留、网络抖动、灾备目标和运营时区的共同约束;未知的数据分类或跨境规则必须标为未知,不能假设“上云即可解决”。
| 维度 | 澄清字段 | 设计影响 | 未知时动作 |
|---|---|---|---|
| 主数据 | 日增、峰增、字段大小 | 分区、索引、归档 | 抽样测量 |
| 审计数据 | 事件数、保留期 | 存储成本、检索期限 | 合规确认 |
| 副本 | 搜索、分析、备份份数 | 写放大、恢复时间 | 明确责任源 |
| 地域 | 驻留、访问地、恢复地 | 延迟、复制、安全 | 法务评审 |
sequenceDiagram
participant 产 as 业务系统
participant 主 as 权威数据
participant 副 as 查询副本
participant 归 as 归档库
participant 审 as 审计人员
产->>主: 写入业务事实
主->>副: 投递可重放变更
主->>归: 按保留规则归档
审->>主: 核验事实与版本
审->>归: 调阅历史证据
副-->>产: 提供可延迟查询数据演绎 5:存储增长的下界与副本放大
E3(演练证据):每日 200 万条轨迹,每条原始记录 1 千字节,原始日增约 2,000,000 × 1KB = 2GB;保留 365 天为 730GB。若主存、查询副本、备份各一份且索引额外按原文 40% 估算,容量下界为 730 × (3 + 0.4) = 2,482GB,尚未包含压缩差异与恢复临时空间。
热门面试题
- 问题:数据量估算为什么要包括副本和索引?
- 考点:全链路成本。
- 回答思路:业务记录不是唯一占用。
- 详细答案:查询、审计、备份和恢复都依赖额外副本,索引还会引入写放大。只报原始表容量会让成本、迁移窗口和恢复资源在上线后才暴露。
- 进阶追问:压缩率可以当确定值吗?
- 进阶回答:不能。压缩依赖字段分布和实现,演练中必须写为假设并用样本验证。
- 问题:如何处理数据保留与业务查询冲突?
- 考点:生命周期。
- 回答思路:区分在线、归档和删除。
- 详细答案:先确认法律、审计、客服与分析的最长期限,再定义热数据查询、归档调阅和可证明删除路径。保留不是“永不删除”,删除也不能破坏账务证据。
- 进阶追问:地域复制的主要风险是什么?
- 进阶回答:除延迟外,还包括数据驻留、复制滞后、冲突处理、密钥管理与恢复演练,需共同进入约束矩阵。
- 问题:权威数据与查询副本如何区分?
- 考点:数据责任。
- 回答思路:能否改变业务事实是分界。
- 详细答案:权威数据承担不变量与审计,副本服务查询或分析且可重建。副本延迟、丢失或重建时不能反向覆盖权威状态。
- 进阶追问:副本差异如何发现?
- 进阶回答:使用可追溯序号、总量比对、抽样字段比对和重放范围记录,而不是仅检查复制进程是否存活。
2.3 延迟、吞吐、尾延迟与恢复窗口
平均延迟会隐藏少量长请求造成的排队与用户失败。澄清应同时写响应目标、吞吐、并发、超时、队列上限、恢复点目标和恢复时间目标,并说明业务可接受的受控拒绝、排队或降级。容量与排队的公式可在后续 53/02(容量估算、排队论与 Little 定律)复用;业务指标口径可在 54/01(指标树与北极星)复用。
| 指标 | 含义 | 必须绑定 | 反例 |
|---|---|---|---|
| 吞吐 | 单位时间完成量 | 成功语义与窗口 | 返回受理不等于完成 |
| 尾延迟 | 慢请求边界 | 分位、链路、超时 | 平均值掩盖排队 |
| 并发 | 在途工作量 | 停留时间与资源 | 线程数不是并发承诺 |
| 恢复窗口 | 允许丢失和恢复时限 | 数据与业务优先级 | 备份存在不等于可恢复 |
sequenceDiagram
participant 用 as 用户
participant 网 as 网关
participant 服 as 服务
participant 队 as 队列
participant 工 as 工作器
用->>网: 高峰请求
网->>服: 受理或受控拒绝
服->>队: 可异步工作入队
队->>工: 按配额消费
alt 队列超过上限
队-->>服: 返回排队或拒绝信号
服-->>用: 可解释的稍后处理
else 正常
工-->>用: 可查询的完成结果
end数据演绎 6:尾延迟导致的在途放大
E3(演练证据):入口稳定在 80 次/秒,通常停留 0.2 秒,估算在途量 80 × 0.2 = 16;外部依赖抖动后 5% 请求停留 5 秒,其余 95% 停留 0.2 秒,加权停留为 0.95 × 0.2 + 0.05 × 5 = 0.44 秒,在途量升到 80 × 0.44 = 35.2。吞吐未变,连接与线程压力已超过两倍。
热门面试题
- 问题:为什么架构评审要看尾延迟?
- 考点:排队与体验。
- 回答思路:慢请求占用资源并触发重试。
- 详细答案:尾部请求会堆积连接、线程和队列,随后超时重试将局部抖动放大为全链路故障。评审需按关键链路分别定义分位目标、超时和受控拒绝策略。
- 进阶追问:如何降低尾延迟?
- 进阶回答:先定位依赖、锁、慢查询和资源争用,再设置超时、隔离、限流、缓存或异步;不能只盲目增加机器。
- 问题:吞吐高就代表系统快吗?
- 考点:完成语义。
- 回答思路:区分接收、处理和业务完成。
- 详细答案:高吞吐可能只是把工作堆到队列中。必须同时看积压、完成延迟、失败率和恢复时长,特别是支付与库存不能把未完成假装成成功。
- 进阶追问:队列可以无限长吗?
- 进阶回答:不可以。无上限队列会吞掉内存和恢复窗口;要定义容量、优先级、丢弃或拒绝语义以及积压清理策略。
- 问题:恢复目标怎样进入需求?
- 考点:故障成本。
- 回答思路:先问允许损失和最长不可用。
- 详细答案:不同链路的恢复点和恢复时限不同,支付账务通常优先可追溯,报表可接受延迟。把目标落到备份、复制、回放和演练证据,才能验证承诺。
- 进阶追问:备份成功能证明恢复吗?
- 进阶回答:不能。必须验证恢复后的数据完整性、权限、依赖和业务校验,且测量实际恢复时长。
3. 约束驱动设计与冲突决策
3.1 硬约束、偏好、假设与未知
四类信息不能混写。硬约束违反即不可用,例如监管数据驻留或资金不可重复入账;偏好可用成本、效率换取;假设必须可验证;未知则是风险清单,不是默认允许。每条约束要有来源、所有者、有效期和验证动作。
| 分类 | 定义 | 示例 | 决策规则 |
|---|---|---|---|
| 硬约束 | 违反即淘汰 | 支付金额不得重复入账 | 先过滤候选方案 |
| 偏好 | 可权衡 | 希望复用现有监控 | 写明收益与代价 |
| 假设 | 可复算但未证实 | 峰值 120 次/秒 | 设验证日期与阈值 |
| 未知 | 不能推断 | 跨境数据是否可复制 | 阻塞或降级范围 |
sequenceDiagram
participant 架 as 架构师
participant 业 as 业务负责人
participant 合 as 合规负责人
participant 团 as 交付团队
架->>业: 标注目标、偏好、未知
架->>合: 确认硬约束与审计
架->>团: 确认存量与期限
团-->>架: 能力缺口与风险
架-->>业: 约束矩阵与待决项
业->>架: 批准优先级或补证据数据演绎 7:硬约束不能被加权分抵消
E3(演练证据):方案甲成本 90 分、性能 85 分但不能满足数据驻留;方案乙成本 70 分、性能 75 分且满足驻留。无论权重如何,甲在硬约束过滤后得分为“不可选”,不是用成本分与性能分平均后获胜。该演练用于说明决策顺序。
热门面试题
- 问题:为什么要区分硬约束和偏好?
- 考点:决策纪律。
- 回答思路:硬约束不可交换,偏好可以。
- 详细答案:混在同一评分表会让团队用低成本抵消合规或资金正确性。先淘汰违反硬约束的方案,再对可选方案比较偏好,决策才可审计。
- 进阶追问:期限是硬约束吗?
- 进阶回答:取决于业务后果。法定日期或合同窗口可能是硬约束,普通期待应作为偏好并允许调整范围。
- 问题:假设如何避免变成“伪事实”?
- 考点:证据边界。
- 回答思路:标注等级、来源、复算式和验证计划。
- 详细答案:所有 E3(演练证据)数值附带输入、公式、适用窗口和待采集证据;评审时以此决定保守余量,而不是把它写成线上现状。
- 进阶追问:未知项太多怎么办?
- 进阶回答:按对不变量、合规、期限和成本的影响排序,关键未知未关闭前缩小范围或暂停不可逆决策。
- 问题:团队能力为什么是架构约束?
- 考点:可维护性。
- 回答思路:系统要被长期运营。
- 详细答案:缺少运行、排障和升级能力的复杂组件会把风险推迟到生产。方案要包含培训、值班、可观测性、外部支持和降级路径,而非只比较功能清单。
- 进阶追问:是否因此永远不能引入新技术?
- 进阶回答:不是。可以通过小范围验证、并行运行、明确退出条件和能力建设降低引入风险。
3.2 一致性、可用性、恢复、安全与成本冲突
约束冲突不是“技术选型题”,而是失败成本排序题。支付要以唯一入账、可审计与可恢复为先,宁可进入未知态;WMS(仓储管理系统)在交班高峰常优先让作业连续,但绝不允许确认扣减超过可用量。两者都要正确,却对可用性、同步等待和人工介入的容忍度不同。
| 场景 | 第一优先级 | 可牺牲项 | 不变量 | 受控降级 |
|---|---|---|---|---|
| WMS(仓储管理系统)拣货 | 作业连续与库存正确 | 部分查询实时性 | 确认不超卖 | 排队确认、稍后同步 |
| 支付回调 | 资金正确与可追溯 | 立即展示最终结果 | 唯一金额入账 | 未知态、主动查单 |
| IoT(物联网)告警 | 关键告警可达 | 低级告警实时性 | 高危事件不静默丢失 | 聚合、分级、背压 |
| Runner(执行器)任务 | 副作用唯一 | 任务立即完成 | 同一租约单执行 | 延后、暂停、重放 |
sequenceDiagram
participant 支 as 支付平台
participant 服 as 支付服务
participant 账 as 账务事实
participant 查 as 查单任务
participant 人 as 人工处理
支->>服: 回调超时或重复
服->>账: 校验幂等与金额
alt 无法确认外部结果
服->>查: 进入未知态并查单
查-->>人: 超时后待核验
else 可确认
服->>账: 写唯一入账事实
end数据演绎 8:WMS(仓储管理系统)与支付的相反权衡
E3(演练证据):WMS(仓储管理系统)交班峰值 8.34 次/秒,若外部报表不可用,可先记录权威作业事实、延迟展示;支付回调每秒仅 2 次但单笔错误损失高,外部状态不明时不得因追求“秒级完成率”直接记成功。前者允许读模型延迟,后者允许用户看到未知态;共同底线是不能破坏库存或账务不变量。
热门面试题
- 问题:为什么 WMS(仓储管理系统)和支付不能套同一可用性策略?
- 考点:业务失败成本。
- 回答思路:比较错误后果与可逆性。
- 详细答案:仓内作业受时间窗口约束,可将非关键查询异步化来保持流动;支付一旦错记资金,后续纠正成本和审计风险更高。策略应由不变量与失败成本决定,而不是由同一个中间件模板决定。
- 进阶追问:支付是否必须全同步?
- 进阶回答:不必。可以异步查单和对账,但最终入账必须有唯一、可追溯的权威判定,未知态不可伪造成功。
- 问题:安全与性能冲突怎么处理?
- 考点:风险分层。
- 回答思路:按数据和动作敏感度分级。
- 详细答案:对资金、导出和管理动作采用强鉴权、审计与更严格限流;对公开低风险查询可使用缓存与较宽松路径。不能以全局关闭审计来换取局部性能。
- 进阶追问:加密会增加延迟怎么办?
- 进阶回答:测量关键链路影响,采用密钥托管、连接复用与分层保护;若仍不达标,调整非敏感数据路径而非降低敏感数据保护线。
- 问题:成本为什么要在需求阶段讨论?
- 考点:持续可行性。
- 回答思路:成本由保留、峰值、冗余和团队共同决定。
- 详细答案:晚讨论成本会让高副本、长保留和跨地域复制变成不可退出承诺。需求阶段就要写预算边界、增长触发器、归档和降级方案。
- 进阶追问:低成本是否等于少副本?
- 进阶回答:不是。应比较事故损失、恢复时间和维护成本,关键事实的冗余可能反而降低总成本。
3.3 存量系统、期限与方案输入
存量约束包括既有数据模型、接口契约、发布窗口、团队技能、监控缺口与历史债务。它们不是“不能改”的借口,而是决定迁移策略、兼容期、双写验证和退出方案的输入。未经批准的需求变更不得绕过这份基线。
| 存量约束 | 影响 | 需要的方案输入 | 验收或退出 |
|---|---|---|---|
| 老接口无幂等标识 | 重复副作用 | 兼容键与灰度策略 | 重放演练、旧接口下线 |
| 只能夜间发布 | 变更窗口短 | 回滚包与数据修复脚本 | 窗口内可回退 |
| 监控无链路关联 | 难定位尾延迟 | 观测补齐计划 | 关键链路可关联 |
| 团队未维护过新组件 | 运行风险 | 培训、值班、支持 | 故障演练通过 |
flowchart LR
A[目标与不变量] --> B[量级与质量场景]
B --> C[硬约束、偏好、假设、未知]
C --> D{冲突已决?}
D -- 是 --> E[方案输入:边界、容量、安全、恢复、成本]
D -- 否 --> F[升级业务决策并记录风险]
E --> G[验收用例与回退]flowchart TD
A[存量接口与数据] --> B[兼容范围]
B --> C[小范围验证]
C --> D{不变量与质量阈值达标?}
D -- 是 --> E[扩大灰度并保留回退]
D -- 否 --> F[停止切换、对账、修复]
F --> B
E --> G[达成退出条件后下线旧路径]数据演绎 9:期限倒推验证窗口
E3(演练证据):距离法定上线 20 个工作日,设计澄清 4 天、实现 8 天、联调 3 天、压测与故障演练 3 天、回退预留 2 天,总计 4 + 8 + 3 + 3 + 2 = 20 天。任何新增硬约束都会挤占回退或验证;因此变更必须重新估算,不能把测试期默默压缩。
热门面试题
- 问题:存量系统约束如何影响架构?
- 考点:演进设计。
- 回答思路:从兼容、迁移、观测与退出回答。
- 详细答案:新方案必须说明与旧接口、旧数据和旧运行方式如何共存,何时切换、如何对账、失败如何回退。忽略存量只会把“新架构正确”变成“无法落地”。
- 进阶追问:什么时候应该拒绝兼容?
- 进阶回答:当兼容路径突破安全、资金或数据正确性底线时,应明确停止条件、迁移窗口和人工方案,而不是永久双轨运行。
- 问题:期限紧张时优先砍什么?
- 考点:范围控制。
- 回答思路:不砍不变量与恢复证据。
- 详细答案:可以缩小非关键角色、报表范围和自动化程度,但不能省略权限、幂等、审计、回退和关键质量场景验证。把不可接受风险写给决策人选择。
- 进阶追问:谁有权接受风险?
- 进阶回答:由拥有业务与合规后果的负责人批准,技术团队负责说明风险、替代项和剩余暴露。
- 问题:方案输入最容易漏什么?
- 考点:全生命周期。
- 回答思路:漏失败、恢复和运行责任。
- 详细答案:许多方案只有正常流程和组件图,却没有观测、告警、数据修复、权限、成本和退出。评审应强制每项约束映射到设计、测试和责任人。
- 进阶追问:如何防止评审流于形式?
- 进阶回答:以具体质量场景、量级公式和失败演练为输入,不能回答证据和阈值的项不得通过。
4. 从澄清到验收:风险前置与变更控制
4.1 澄清遗漏、模糊量级与隐含不变量的排障
线上出现“慢、错、贵、无法恢复”时,不应只调参数;先回看需求基线:当时是否把峰值当平均、把受理当完成、遗漏外部重试、未写出不变量,或把未知当成了假设。排障的产物应反哺约束矩阵与验收用例。
| 线上信号 | 常见遗漏 | 排查问题 | 修复输出 |
|---|---|---|---|
| 积压持续增长 | 未定义队列上限与恢复量 | 到达率是否大于处理率 | 限流、配额、恢复演练 |
| 重复扣减 | 幂等与不变量混淆 | 唯一键覆盖哪些请求 | 条件更新、流水核对 |
| 尾延迟升高 | 只验平均值 | 慢请求在哪一段停留 | 隔离、超时、观测 |
| 审计缺口 | 角色遗漏 | 谁在何时以何权限操作 | 审计事件与访问控制 |
flowchart TD
A[线上异常] --> B{违反不变量?}
B -- 是 --> C[止损、冻结危险动作、对账]
B -- 否 --> D{超过质量阈值?}
D -- 是 --> E[查峰值、依赖、队列、尾延迟]
D -- 否 --> F[查验收口径与观测盲区]
C --> G[更新约束与恢复用例]
E --> G
F --> G数据演绎 10:积压恢复是否可完成
E3(演练证据):故障 30 分钟,进入队列速率 20 条/秒,积压为 30 × 60 × 20 = 36,000 条;恢复后处理能力 50 条/秒且新流量仍为 20 条/秒,净清理速率为 50 - 20 = 30 条/秒,清理时间约 36,000 / 30 = 1,200 秒,即 20 分钟。若业务要求 10 分钟恢复,现有假设不满足,不能只写“自动扩容”。
热门面试题
- 问题:为什么线上问题要回溯需求澄清?
- 考点:根因层级。
- 回答思路:参数问题常是遗漏约束的表现。
- 详细答案:若未定义峰值、队列上限或不变量,系统按错误目标构建,局部调优只能缓解症状。回溯能把故障转化为可复用的质量场景和验收规则。
- 进阶追问:每次故障都要改架构吗?
- 进阶回答:不一定。先判定是实现缺陷、运行参数、容量假设还是约束冲突;只有设计假设失效时才进入架构变更。
- 问题:如何识别隐含不变量?
- 考点:异常推理。
- 回答思路:从“绝不能错”的事故后果反推。
- 详细答案:例如重复退款、负库存、跨租户导出都说明存在未被显式建模的唯一性、数量或权限边界。应把它们写进数据、接口与对账规则。
- 进阶追问:日志能证明不变量吗?
- 进阶回答:日志可提供线索,真正证明仍需权威数据约束、可追溯流水和定期核验。
- 问题:量级估错后怎样修正?
- 考点:证据迭代。
- 回答思路:保留旧假设,补充观测并重新验算。
- 详细答案:不能悄悄覆盖原估算;记录偏差来源、实际窗口、变化因素和新阈值,重新检查容量、成本、恢复和回退,保证决策可追溯。
- 进阶追问:何时需要立即限流?
- 进阶回答:当继续接收会突破不变量、恢复窗口或关键依赖容量时,优先受控拒绝低优先级工作并保护核心事实。
4.2 验收、需求基线与变更控制
验收把“我以为”改为“有证据”。基线至少包含目标、角色、用例、不变量、量级、质量场景、约束分类、冲突决策、方案输入与回退。变更必须说明触发原因、影响范围、重新验证项和批准人;绕过基线的“顺手改一下”是需求变更失败,而不是敏捷。
| 变更类型 | 示例 | 必做影响分析 | 批准后动作 |
|---|---|---|---|
| 目标变更 | 新增当日达承诺 | 峰值、成本、角色 | 更新验收与容量 |
| 约束变更 | 新增数据驻留 | 地域、复制、供应商 | 重审候选方案 |
| 量级变更 | 峰值翻倍 | 队列、尾延迟、恢复 | 重压测、更新阈值 |
| 不变量变更 | 允许部分退款 | 状态机、账务、审计 | 补充对账与回退 |
flowchart LR
A[需求澄清] --> B[需求基线]
B --> C[方案与验收]
C --> D[上线证据]
D --> E{提出变更}
E -- 无 --> F[持续观测]
E -- 有 --> G[影响分析:不变量、量级、质量、成本]
G --> H{批准且可验证?}
H -- 是 --> B
H -- 否 --> I[拒绝或保持原基线]数据演绎 11:变更触发重新验收的判断
E3(演练证据):原假设峰值 120 次/秒、处理上限 160 次/秒,安全余量为 160 / 120 - 1 = 33.3%。若活动范围变更为 180 次/秒,余量变为 160 / 180 - 1 = -11.1%,即使代码完全未改也必须重新验收限流、队列和恢复,不能沿用旧压测结论。
热门面试题
- 问题:什么是好的架构验收?
- 考点:可证明性。
- 回答思路:目标、阈值、场景、证据、责任、回退。
- 详细答案:好的验收覆盖正常与失败路径,明确输入条件、预期响应、度量、证据位置和不通过后的回退。它验证的是业务约束是否被实现,不只是接口是否返回二百。
- 进阶追问:谁签字才有效?
- 进阶回答:业务、技术、运行和合规分别对其拥有的结果签字;跨领域承诺不能由单一角色代签。
- 问题:为什么变更控制不是流程负担?
- 考点:风险管理。
- 回答思路:变更会使旧证据失效。
- 详细答案:需求、量级或合规变化会影响不变量、容量和成本。控制的价值是找出哪些结论需要重算和重验,而不是阻止合理变化。
- 进阶追问:紧急变更怎么做?
- 进阶回答:可走简化审批以先止损,但仍需记录决策、限制范围、可回退措施,并在事后补齐影响分析与验收。
- 问题:如何把架构风险前置?
- 考点:设计方法。
- 回答思路:先验证高损失且高不确定项。
- 详细答案:在实现前将合规、资金不变量、峰值、外部依赖和恢复列入风险清单,用演练、原型或证据采集关闭它们;低风险界面细节不应挤占这段窗口。
- 进阶追问:如何判断风险已关闭?
- 进阶回答:不是“讨论过”,而是有明确假设、验证证据、剩余风险、责任人和触发复审的阈值。
4.3 可复述的架构澄清话术与复习清单
项目话术:“我不会先说用了什么组件。我先和业务确认目标、角色和成功事实,把库存不能超卖或资金不能重复入账写成不变量;再把峰谷、读写、数据增长、尾延迟、恢复、安全、地域、成本、团队与期限拆成硬约束、偏好、假设和未知。没有证据的数字我标为 E3(演练证据)并给出复算式。随后用六要素质量场景定义验收与失败路径,冲突由业务失败成本排序,例如 WMS(仓储管理系统)可允许读模型延迟来保护作业连续,支付宁可未知也不猜测入账。上线后以观测验证基线,任何变更都重新分析不变量、量级和回退。“
| 复习项 | 能否复述 | 核对问题 |
|---|---|---|
| 先问题后技术 | 是/否 | 目标、角色、成功和失败是否明确? |
| 业务不变量 | 是/否 | 重试、并发、乱序下是否仍成立? |
| 量级演算 | 是/否 | 峰值、放大、增长、恢复能否复算? |
| 质量场景 | 是/否 | 六要素和验收阈值是否齐全? |
| 约束冲突 | 是/否 | 硬约束、偏好、未知是否分开? |
| 变更控制 | 是/否 | 哪些旧证据会因变更失效? |
flowchart TD
A[业务目标] --> B[角色与用例]
B --> C[不变量与失败成本]
C --> D[量级与质量场景]
D --> E[约束分类与冲突决策]
E --> F[方案、验收、回退]
F --> G[观测与变更控制]
G --> A5. 综合题库
综合题 01:如何澄清库存防超卖需求?
- 口述答案:先确认库存单位、预占与确认的业务事实,定义“已确认扣减不超过可用量”不变量;把交班峰值、重扫、撤销和人工补单转为质量场景。用条件更新、唯一流水与对账分别阻止、记录和发现差异,所有量级无生产证据时标 E3(演练证据)。
- 追问 1:读模型延迟能接受吗?直答:可接受前提是权威扣减已完成且界面标注更新时间。追问 2:重试怎样处理?直答:以请求标识返回既有结果,不重复扣减。追问 3:验收什么?直答:并发扣减、重复提交、异常恢复与账实核对。
综合题 02:支付回调未知态怎么设计?
- 口述答案:不把超时推断成成功或失败,先用外部交易标识与金额校验幂等,再进入未知态查单;最终入账必须唯一、可审计,对账和人工处理承接超时边界。
- 追问 1:为什么不立即重试入账?直答:外部状态未知会造成重复资金事实。追问 2:用户看什么?直答:可解释的处理中与查询时限。追问 3:成功证据?直答:权威回执、唯一账务记录与对账一致。
综合题 03:业务说“系统要快”如何追问?
- 口述答案:分角色、链路和峰谷问清响应目标、尾延迟、完成语义与受控拒绝;再给出刺激源、环境、响应和度量,拒绝把“平均快”当验收。
- 追问 1:看哪个分位?直答:关键链路按业务损失选择并写入验收。追问 2:超时后怎样?直答:明确重试、查询或失败语义。追问 3:无数据怎么办?直答:建立可复算 E3(演练证据)并补采集计划。
综合题 04:如何估算一次促销峰值?
- 口述答案:从参与人数、单人操作频率和最短集中窗口计算入口峰值,拆出读写、日志、事件和重试放大;再检查并发、队列上限与恢复时间,不用日均量替代峰值。
- 追问 1:峰值翻倍?直答:重新验算所有旧结论。追问 2:缓存命中算源库读吗?直答:分别记录,不能混算。追问 3:谁确认假设?直答:业务、运行与数据责任人共同确认来源。
综合题 05:怎样估算轨迹存储成本?
- 口述答案:按日增、单条大小、索引、副本、备份、保留期和恢复空间拆解,明确权威数据与查询副本;压缩率只作待验证假设。
- 追问 1:能直接删历史吗?直答:先确认审计与合规期限。追问 2:副本能写回吗?直答:不能替代权威事实。追问 3:地域影响?直答:同时评估驻留、延迟、复制和恢复。
综合题 06:如何写一个可用性质量场景?
- 口述答案:完整写刺激源、刺激、环境、受影响物、响应和度量,例如单节点在高峰失效后系统如何保护不变量、切换或受控拒绝,以及多久给出可解释结果。
- 追问 1:只有目标可行吗?直答:不行,无法测试。追问 2:谁验收?直答:业务和运行共同验。追问 3:失败怎么办?直答:按回退与恢复用例处理。
综合题 07:硬约束与偏好冲突怎么决策?
- 口述答案:先把监管、资金正确性等硬约束做淘汰条件,再在剩余方案中比较成本和效率偏好;不允许加权评分抵消违反硬约束。
- 追问 1:期限属于哪类?直答:按后果判定,法定窗口可能是硬约束。追问 2:未知项呢?直答:进入风险清单,不默认放行。追问 3:谁拍板?直答:承担业务后果的负责人批准。
综合题 08:WMS(仓储管理系统)与支付的权衡有何不同?
- 口述答案:两者都守住正确性,但 WMS(仓储管理系统)可让非关键展示延迟以维持作业连续,支付外部状态未知时宁可等待查证,也不能猜测资金结果。
- 追问 1:共同底线?直答:库存和账务不变量。追问 2:都能异步吗?直答:能,但权威确认语义不同。追问 3:如何验收?直答:分别演练高峰作业与未知回调。
综合题 09:安全与性能冲突怎么处理?
- 口述答案:按动作和数据敏感度分层,资金、导出与管理动作保持强鉴权和审计,低风险查询再优化缓存;以测量和分层改造解决,而非关闭安全控制。
- 追问 1:审计影响延迟?直答:异步记录但不得丢失关键关联。追问 2:越权如何验?直答:角色、字段、租户与审计联测。追问 3:密钥故障?直答:定义受控拒绝和恢复责任。
综合题 10:跨境地域要求如何进入设计?
- 口述答案:确认数据分类、驻留地、访问地、复制地、密钥和恢复地,再将其作为硬约束过滤方案;网络延迟只是其中一个维度。
- 追问 1:副本在海外可行吗?直答:需先确认数据与法规边界。追问 2:灾备呢?直答:同样受驻留限制。追问 3:未知怎么办?直答:法务未确认前限制范围。
综合题 11:遗留接口没有幂等键怎么办?
- 口述答案:先界定重复副作用风险,设计兼容标识、唯一流水、灰度和重放验证;若无法安全兼容,限制旧接口并给出迁移窗口。
- 追问 1:能只靠缓存吗?直答:不能作为权威唯一性。追问 2:怎么回退?直答:保留旧路径与数据对账。追问 3:何时下线?直答:兼容指标和迁移验收满足后。
综合题 12:上线期限只有二十天怎么排?
- 口述答案:倒推澄清、实现、联调、压测、故障演练和回退窗口;若新增约束挤占验证期,缩小非关键范围而不削弱不变量与回退。
- 追问 1:谁接受剩余风险?直答:业务与合规责任人。追问 2:能砍测试吗?直答:不能砍关键失败路径。追问 3:紧急变更?直答:限范围、可回退、事后补证据。
综合题 13:队列积压如何判断能否恢复?
- 口述答案:用故障时长乘进入速率得积压,用恢复处理速率减新流量得净清理速率,二者相除得到恢复时间;结果必须小于业务恢复窗口。
- 追问 1:处理能力只看峰值?直答:还要扣除持续新流量。追问 2:队列无限长?直答:会拖垮资源和恢复。追问 3:保护谁?直答:按业务优先级与不变量分级。
综合题 14:尾延迟升高先查什么?
- 口述答案:从请求分位、链路段、依赖、连接、线程、锁和队列逐层定位,并检查超时重试是否放大在途量;平均值正常不能排除问题。
- 追问 1:先扩容吗?直答:先确认瓶颈与放大点。追问 2:如何止损?直答:隔离、限流和受控拒绝。追问 3:如何回写?直答:补质量场景和阈值。
综合题 15:业务提出“永不丢数据”怎么澄清?
- 口述答案:追问数据范围、故障域、允许损失、保留期和恢复时限,把绝对口号拆成恢复点、恢复时间、校验和责任;不同事实不能共用一个承诺。
- 追问 1:备份足够吗?直答:必须演练恢复与校验。追问 2:日志算事实吗?直答:需明确权威性与可追溯性。追问 3:成本谁评估?直答:业务与技术共同评估长期成本。
综合题 16:如何评审一个“高可用”方案?
- 口述答案:要求它给出失效刺激、环境、检测、受控响应、数据边界、恢复时间和验证证据;没有具体质量场景的多副本描述不构成高可用方案。
- 追问 1:切换即成功吗?直答:还要核验数据与业务可用。追问 2:单点在哪里?直答:含配置、密钥与人工流程。追问 3:恢复如何量?直答:从故障开始到业务验收结束。
综合题 17:IoT(物联网)报警风暴的需求怎么写?
- 口述答案:区分高危与低危事件,定义不允许丢失的告警事实、聚合窗口、背压、静默、通知和人工确认;目标是关键可达而非每条原样实时推送。
- 追问 1:聚合会漏告警吗?直答:高危规则不可被低优先级聚合吞没。追问 2:积压怎么办?直答:优先级、上限和恢复估算。追问 3:如何验?直答:注入突发事件并核验关键通知。
综合题 18:Runner(执行器)重复执行如何处理?
- 口述答案:明确副作用唯一性不变量,用租约、栅栏、幂等记录和可追溯执行状态协同保障;心跳延迟只影响观测,不能让旧执行者继续提交副作用。
- 追问 1:任务可重试吗?直答:需按副作用定义重试语义。追问 2:租约过期?直答:校验栅栏再提交。追问 3:恢复?直答:依据执行记录重放或人工处理。
综合题 19:如何处理客服要求“立刻看到物流状态”?
- 口述答案:先定义状态来源与可接受延迟;外部承运商未确认时展示更新时间和处理中,不以本地受理伪造送达事实,并提供查证与人工路径。
- 追问 1:乱序事件?直答:用版本和合法转移过滤。追问 2:外部超时?直答:重试与待核验分流。追问 3:验收?直答:来源、延迟和异常展示可解释。
综合题 20:发现成本飙升如何从需求回溯?
- 口述答案:检查原基线是否漏算副本、索引、保留、重试、跨地域与团队运行成本;再确认增长假设是否失效,形成归档、限额或方案复审输入。
- 追问 1:先删数据?直答:先核对合规与审计。追问 2:缓存能解决吗?直答:仅改善部分读取成本。追问 3:何时复审?直答:触发预算或增长阈值时。
综合题 21:如何把模糊需求变成验收清单?
- 口述答案:按角色列正常与失败用例,补不变量、量级和六要素质量场景,为每项写输入、阈值、证据、责任人与不通过后的回退。
- 追问 1:谁写?直答:多角色共写,架构师收敛。追问 2:如何防遗漏?直答:用约束矩阵逐项检查。追问 3:怎么维护?直答:变更后版本化更新。
综合题 22:架构方案出现冲突但业务不决策怎么办?
- 口述答案:把冲突、候选项、各自损失、不可逆性和截止日书面化并升级;技术团队可提供受控默认方案,但不得把偏好伪装成业务结论。
- 追问 1:能先做吗?直答:仅做可逆且不碰硬约束的部分。追问 2:如何避免拖延?直答:给出决策期限和默认风险。追问 3:记录什么?直答:依据、批准人和复审触发器。
综合题 23:真实指标没有证据时如何面试表达?
- 口述答案:明确说没有可追溯生产证据,使用 E3(演练证据)说明输入、公式、结论边界和待验证动作;展示方法论,不虚构数值或事故。
- 追问 1:会显得弱吗?直答:诚实边界体现工程判断。追问 2:演练有什么用?直答:暴露缺口并指导采集。追问 3:何时变事实?直答:有可追溯测量后。
综合题 24:需求变更为何会导致事故?
- 口述答案:因为目标、量级、地域或不变量改变会让原容量、权限、恢复和回退证据失效;绕过影响分析的改动把风险藏到了上线后。
- 追问 1:小改也要评估?直答:按影响分级,但不跳过。追问 2:如何止损?直答:限范围、回退、观测。追问 3:如何复盘?直答:补基线与验收缺口。
综合题 25:如何设计一次架构需求评审会?
- 口述答案:按目标角色、用例成败、不变量、量级、质量场景、约束分类、冲突、方案输入、验收和变更依次过一遍;无法给出来源或验证动作的项保留为风险。
- 追问 1:谁必须参加?直答:业务、技术、运行、安全或合规相关责任人。追问 2:会议产物?直答:版本化约束基线。追问 3:评审通过条件?直答:硬约束和关键未知已决或有批准风险。
综合题 26:请完整讲一次架构设计起点。
- 口述答案:我从业务问题而非技术名词开始,确认角色、用例、成功失败和不变量;将峰谷、读写、数据增长、尾延迟、恢复、安全、地域、成本、期限和存量系统归类为硬约束、偏好、假设与未知。然后用六要素质量场景把取舍变成验收,优先验证高损失高不确定风险。WMS(仓储管理系统)与支付按各自失败成本取舍,上线后用观测和变更控制持续校正基线。
- 追问 1:核心原则?直答:先问题后技术、约束驱动和可验证。追问 2:怎么保证诚实?直答:真实与演练证据分级。追问 3:怎么闭环?直答:验收、观测、复盘和批准变更回写基线。
6. 结构审计清单
- 知识小节与六字段题:11 / 33。
- Mermaid(图表语法):13 张,其中 7 张时序图。
- 表格:12 张;数据演绎:11 个,均为 E3(演练证据)。
- 综合题:26 道;正式图:PlantUML(开源建模工具)与 PNG(便携式网络图形)文件位于
assets/architecture-requirement-constraints.*。
图形的正式链路覆盖干系人、目标、用例、不变量、量级、质量场景、约束冲突、方案输入、验收,以及未经控制的需求变更如何走向失败。后续容量细化使用 53/02(容量估算、排队论与 Little 定律),后续业务指标语义使用 54/01(指标树与北极星);两个分册尚未创建,故此处保留代码路径而不建立失效链接。
