架构设计口述模板

1. 通用 3 分钟模板

第一段：先讲背景和目标
这个系统主要解决什么业务问题，核心目标是什么。

第二段：讲约束和质量属性
当前规模、峰值、一致性、可用性、成本、团队能力。

第三段：讲核心架构
服务怎么拆，数据怎么流，核心组件怎么选。

第四段：讲异常和兜底
超时、重试、重复、失败、数据不一致怎么处理。

第五段：讲观测和演进
如何监控、灰度、回滚，后续怎么演进。

2. 技术选型模板

我会先明确业务目标和数据规模，再看一致性、性能、成本和团队运维能力。
这个场景下，A 方案的优势是 X，风险是 Y；B 方案的优势是 M，风险是 N。
如果是当前阶段，我会选择 A，因为它能满足核心目标且复杂度可控。
同时保留向 B 演进的接口，等数据规模或业务复杂度达到阈值后再升级。

示例：

对订单主数据，我会选 MySQL（关系型数据库），因为订单需要事务、约束、状态机和审计。Elasticsearch（搜索引擎）可以作为搜索读模型，但不能作为事实来源。这样既保证交易正确性，也能满足检索体验。

3. 分布式事务模板

我会先判断这个场景是否真的需要强一致。
如果是单服务内，优先本地事务。
如果是跨服务但允许最终一致，用可靠消息和补偿。
如果是强一致业务，用 TCC（Try Confirm Cancel，尝试确认取消）或事务框架，但要接受复杂度。
外部支付通道这类不可控系统，最终一定要靠对账兜底。

4. 高可用模板

高可用不是只做多副本。
我会从入口限流、服务熔断、线程池隔离、缓存降级、数据库主从、消息削峰、监控告警和应急开关几个层面设计。
同时要明确哪些功能可以降级，哪些链路必须保护，比如支付和库存。

5. 项目方案模板

5.1 库存防超卖

库存防超卖我会分成性能层和正确性层。
Redis（远程字典服务）做热点预扣和削峰，MySQL（关系型数据库）条件更新保证最终不超卖。
订单请求有幂等键，库存冻结有状态机，支付超时会释放库存。
异常情况下通过补偿任务和对账修正。

5.2 支付资金一致性

支付系统里我把资金正确性放在第一优先级。
支付流水号和通道事件 ID（标识）做幂等，Webhook（回调通知）必须验签和防重放。
订单状态通过状态机流转，下游通过 MQ（消息队列）最终一致。
最后用对账和补偿兜底，保证资金问题能被发现、修正和审计。

5.3 跨境物流履约

跨境物流链路长，外部接口不稳定，所以主链路要短，外部调用要隔离。
面单拉取和轨迹同步用独立线程池和 MQ（消息队列）异步化。
物流状态用状态机控制，重复轨迹用业务唯一键幂等。
失败进入重试和死信，必要时人工补偿。

5.4 IoT（物联网）报警风暴

报警风暴治理的目标不是简单丢弃报警，而是降低噪声同时保留重要报警。
接入层限流，MQ（消息队列）削峰，处理层按设备、报警类型和时间窗口聚合。
Redis（远程字典服务）做短期去重和计数，数据库保留最终记录。
严重报警穿透通知，普通重复报警降噪。

6. 稳定性与容量评估口述模板

6.1 你们系统能扛多少并发

我一般不会只用“并发用户数”回答，因为这个口径太模糊。
我会拆成入口 QPS（每秒查询率）、核心 TPS（每秒事务数）、平均 RT（响应时间）、P95（95 分位响应时间）、P99（99 分位响应时间）和错误率。

容量估算上，我会先从业务量倒推。
比如日订单量、峰值集中时间、峰值占比、活动突增倍率，再估算入口 TPS（每秒事务数）和内部 QPS（每秒查询率）。
然后通过压测得到单实例能力，再按目标峰值和冗余系数算实例数。

线上我还会持续看 CPU（中央处理器）、内存、GC（垃圾回收）、线程池、连接池、数据库慢 SQL（结构化查询语言）、Redis（远程字典服务）命中率和 MQ（消息队列）积压。
所以我回答容量时，一定会同时说明统计口径、压测依据和线上监控口径。

可接项目：

• WMS（仓储管理系统）：按出库波峰、拣货复核、库存扣减、面单获取和轨迹推送拆 TPS（每秒事务数）。
• 跨境物流：按轨迹 msg/s（每秒消息数）、第三方 API（应用程序接口） RT（响应时间）和 MQ（消息队列） consumer lag（消费者延迟）回答。
• 库存防超卖：按下单 TPS（每秒事务数）、热点 SKU（库存单位）比例、Redis（远程字典服务）预扣和 MySQL（关系型数据库）条件更新瓶颈回答。

6.2 P95（95 分位响应时间）和 P99（99 分位响应时间）怎么看

平均 RT（响应时间）只能代表整体平均体验，不能代表长尾稳定性。
我更关注 P95（95 分位响应时间）和 P99（99 分位响应时间），因为线上真正影响用户投诉和系统雪崩的，往往是少量慢请求。

如果 P99（99 分位响应时间）升高，我会先用 Trace（链路追踪）确认慢在哪一段：
是网关排队、业务线程池、数据库慢 SQL（结构化查询语言）、Redis（远程字典服务）热点 key（键）、GC（垃圾回收），还是第三方支付/物流接口。
不同原因处理方式不同，不能直接把所有慢请求都归因于服务器不够。

可以补一句：

对外部支付和物流这类慢依赖，我会把内部 RT（响应时间）和下游 RT（响应时间）分开统计，否则会误判内部服务能力。

6.3 服务器规格怎么选

服务器规格我会按服务画像选，不会一上来就给大机器。
普通 Java（编程语言）业务服务可以从 2C4G（2 核 CPU，4GB 内存）或 4C8G（4 核 CPU，8GB 内存）起步。
如果是高吞吐、连接数多或计算较重的服务，再考虑 8C16G（8 核 CPU，16GB 内存）。

关键不是规格本身，而是要通过压测得到单实例稳定能力。
比如单个 4C8G（4 核 CPU，8GB 内存）实例稳定 200 QPS（每秒查询率），目标峰值 600 QPS（每秒查询率），乘以 1.5 冗余系数，大概需要 5 个实例。
同时核心服务至少 2 个实例，避免单点，也要给滚动发布和故障切换留容量。

6.4 Docker（容器技术）和 Kubernetes（容器编排平台）资源怎么配

容器资源我会同时看 CPU request（CPU 请求）、CPU limit（CPU 限制）、memory request（内存请求）和 memory limit（内存限制）。
Java（编程语言）服务尤其要注意，Xmx（最大堆内存）不能贴满 memory limit（内存限制）。
因为 JVM（Java 虚拟机）除了 Heap（堆），还有 Metaspace（元空间）、Direct Memory（直接内存）、线程栈、JIT（即时编译）和本地库开销。

Kubernetes（容器编排平台）的 HPA（水平自动扩缩容）如果只看 CPU（中央处理器）也不够。
核心服务更适合结合 QPS（每秒查询率）、RT（响应时间）、线程池队列、连接池等待和 MQ（消息队列）积压这类业务指标做扩缩容判断。

6.5 CPU（中央处理器）打满怎么回答

CPU（中央处理器）打满时，我会先做止血，再做定位。
止血包括限流、扩容、关闭非核心任务、降级非核心接口。
定位上先看监控和 top（进程监控命令），再用 jstack（线程栈工具）看热点线程，必要时用 Arthas（Java 诊断工具）或火焰图定位热点方法。

同时要区分 CPU（中央处理器）计算打满、锁竞争、GC（垃圾回收）、死循环、线程过多上下文切换和 I/O（输入输出）等待。
如果瓶颈其实在数据库或第三方接口，盲目扩服务只会把下游打得更严重。

6.6 数据库、Redis（远程字典服务）和 MQ（消息队列）怎么扩容

数据库我不会第一步就分库分表。
我会先看慢 SQL（结构化查询语言）、索引、连接池、锁等待、归档和读写分离。
如果写入 TPS（每秒事务数）和数据量确实超过单库能力，再设计分片键、全局 ID（标识）、跨库查询、迁移和双写校验。

Redis（远程字典服务）扩容要看内存、CPU（中央处理器）、网络、big key（大键）、hot key（热键）和主从延迟。
MQ（消息队列）扩容要看 backlog（积压量）、consumer lag（消费者延迟）、Partition（分区）并行度、Consumer（消费者）数量、Broker（代理节点）磁盘和网络。

7. 业务指标与埋点口述模板

7.1 DAU（每日活跃用户数）和 MAU（月活跃用户数）怎么统计

我会先说明活跃口径。
DAU（每日活跃用户数）不是简单登录人数，而是在一天内发生有效业务行为的去重用户数。
MAU（月活跃用户数）是在一个自然月内发生有效业务行为的去重用户数。

如果是 C 端交易系统，有效行为可以是搜索、加购、下单、支付；
如果是 WMS（仓储管理系统）或跨境物流后台，有效行为应该是创建波次、拣货、复核、出库、处理异常、查询轨迹、更新运单状态。

统计上优先按 User ID（用户标识）去重，未登录场景可以用 Device ID（设备标识）或 Cookie ID（浏览器标识）近似，但要说明跨设备和清缓存会带来误差。

7.2 PV（页面浏览量）和 UV（独立访客数）怎么解释

PV（页面浏览量）是页面被浏览的次数，用户刷新多次会重复计数；
UV（独立访客数）是独立访问用户数，同一统计周期内要按 User ID（用户标识）或 Device ID（设备标识）去重。

我不会只用 PV（页面浏览量）判断业务好坏，因为 PV（页面浏览量）上涨可能是用户兴趣变高，也可能是页面异常刷新、路径变长、爬虫或埋点重复。
所以我会结合 UV（独立访客数）、Conversion Rate（转化率）、Bounce Rate（跳出率）、业务完成率和后端事实表一起看。

7.3 埋点怎么设计才可信

埋点我会按 Event（事件）模型设计。
每个 Event（事件）至少要有事件名称、事件时间、User ID（用户标识）、Device ID（设备标识）、Session ID（会话标识）、TraceId（链路标识）、业务属性和结果。

前端埋点适合记录曝光、点击、路径；
后端埋点适合记录订单、支付、库存、履约这类业务事实；
支付、库存和资金类指标不能以前端跳转为准，必须以后端事实和对账结果为准。

如果数据突然变化，我会先查口径、版本、埋点是否丢失或重复，再和订单表、支付流水、库存流水、任务表做对账。

7.4 业务指标如何反向指导架构

业务指标和技术指标要结合看。
比如支付 Conversion Rate（转化率）下降，可能暴露支付通道、Webhook（回调通知）、状态机或对账问题；
物流轨迹延迟升高，可能暴露第三方 API（应用程序接口）、MQ（消息队列）积压或消费者能力问题；
Runner（执行器）任务成功率下降，可能暴露重试、幂等、线程池隔离或下游依赖问题。

所以我会把 DAU（每日活跃用户数）、PV（页面浏览量）、Conversion Rate（转化率）、Retention Rate（留存率）这类业务指标，与 QPS（每秒查询率）、P99（99 分位响应时间）、错误率、MQ（消息队列）积压和 Trace（链路追踪）一起看。

8. 反问面试官模板

架构师面试最后可以反问：

1. 团队目前最核心的系统瓶颈是性能、稳定性还是交付效率？
2. 目前服务治理和可观测性建设到什么阶段？
3. 对架构师岗位更看重方案设计、技术治理还是团队协同？
4. 当前业务未来一年最大的技术挑战是什么？

9. 口述训练要求

• 每个方案控制在 3 分钟内。
• 先讲结论，再讲细节。
• 每个技术选择都说出“不选另一个方案”的原因。
• 每个方案都必须讲失败场景和兜底。
• 每个项目都必须讲可观测性和演进。

10. 精通级训练册入口

旧根模板保留为最短口述骨架，精通级训练册负责把它扩展成可审计、可追问、可复盘的现场表达体系。后续新对话继续补充时，优先阅读下面 5 篇，再决定要强化三分钟、五分钟、十分钟还是追问回收。

10.1 训练顺序

1. 先读 00，确认哪些内容是 E1（直接证据）、E2（材料映射）、E3（演练设计）和 E0（待核对）。
2. 再用 01 训练三分钟稿，做到不靠长背景也能讲出业务不变量。
3. 然后用 02 训练五分钟权衡，把候选方案、淘汰条件、容量成本和迁移回滚说清。
4. 接着用 03 训练十分钟评审，保证系统设计题能从需求进入架构，再从故障恢复回到业务验收。
5. 最后用 04 训练追问回收，所有未知数字、反例和压力问题都要能回到事实等级、证据链和恢复门禁。