这是 AI 应用岗面试里最容易被问倒的压力题。它看着像考架构，其实考的是另一件事：你知不知道自己现在站在哪，以及什么时候该动。
背架构图的人会输，因为面试官会追问「那你现在为什么不做」。
一、先算清楚你现在有多少量
这一题的第一步不是画图，是算数。以我自己的站点为例：
周独立访客 8,461
周页面浏览 76,342
→ 平均 QPS = 76,342 ÷ (7 × 86,400) ≈ 0.13 请求/秒
→ 按峰值是均值 10–20 倍估 → 峰值约 1.5–3 QPS我距离「需要架构」还有两到三个数量级。
那面试官为什么还要问？因为他在筛两件事：
- 你知不知道你现在这套能撑到哪
- 你知不知道到哪一步该改，改成什么
二、我现在的架构（诚实版）
浏览器 ──HTTPS──> www.stylekit.top ──> Nginx ──> Next.js 单进程
(59.110.91.219，阿里云，一台 ECS)- 一台服务器，systemd 守护，
next start跑在一个端口上 - Nginx 做反向代理 + 静态资源缓存策略（图片/字体/视频给了 1 天浏览器缓存、30 天共享缓存 + stale-while-revalidate）
/_next/static/*标记为immutable, max-age=31536000- 没有 CDN，域名直接解析到源站
- 用户数据在托管服务（Supabase）上，业务侧的统计数据写本地 JSON 文件
- 部署方式：本地构建验证，只 rsync 产物上去，从不在生产机上 build——因为那台机器内存受限
最后一条不是洁癖，是血的教训：在生产机上跑构建会把内存吃满，把正在服务的进程一起拖下水。
三、按量级推演：谁先崩
不要说「我会怎么改」，要说「什么先崩」。
现在 × 10（均值约 1.3 QPS，峰值约 30 QPS）
先崩的是内存，然后是单核。
Next.js 单进程 + Node 单线程，意味着所有 SSR 渲染排在一个线程里。并发一上来，事件循环被渲染阻塞，请求开始排队，健康检查超时，systemd 判定服务不健康把它重启——越重启越糟。
同时那台机器内存本来就紧，每个并发渲染都在分配堆内存。
改法（成本几乎为零，且应该现在就做）：
- 静态资源上 CDN。这是第一件该做的事，收益最大：源站从此只处理 HTML 和 API，带宽成本和连接数同时下降。
- 给 systemd 加
MemoryMax。让进程在自己超限时被杀，而不是拖垮整台机器。 - Nginx 加连接限制和限流。让过载时的表现是「部分请求被拒绝」，而不是「所有人一起慢」。
现在 × 100（均值约 13 QPS，峰值约 300 QPS）
单机彻底不够，卡住你的是状态。
加第二台机器很容易——Nginx 加个 upstream 就行。难的是这些东西现在不在共享存储里：
- 统计数据写本地 JSON 文件：两台机器会各写各的，对不上
- 会话、限流计数器：进程内状态，重启即失
改法：先把状态挪进数据库（或缓存），再谈多实例。
顺序不能反。先加机器再挪状态，你会得到两台各说各话的服务器，比一台更难排查。
现在 × 1000（10 万并发）
到这一步才是教科书里的那套：
- 应用层完全无状态，可随时增减实例
- 静态资源全部走 CDN，源站只回源动态请求
- 数据库读写分离、热点缓存
- 可观测性——trace、慢查询、告警。没有这个，你会在故障时两眼一抹黑
四、但别只答技术：JD 问的是三个维度
题目原文往往写的是「技术 / 成本 / 合规」。只答技术会丢分。
成本：这条最容易被忽略，也最能体现判断力。
单机 → 多机的成本是线性增长的；但多机 → 容器编排平台，固定成本会跳一个台阶。这个台阶要到一定量级才划算。
CDN 同理：按流量计费看着贵，但它省下的源站带宽和连接数通常更值。
合规：用户数据不在我手上（托管服务），但一旦上了规模，这几件事跑不掉：
- 数据留存策略：哪些数据存多久、怎么删
- 删除请求响应：个人信息保护法给了用户删除权，你得能真的删干净
- 日志脱敏：别把用户标识写进明文日志
五、这道题的答案长什么样
把上面的东西压成四段，就是能说出口的回答：
① 先说清现状：我现在是单机 + Nginx，周访客 8,461、峰值约 3 QPS。我距离需要重构还有两到三个数量级。
② 说清先崩什么：如果涨 10 倍，先崩的是内存和单核——SSR 渲染全排在 Node 一个线程里，健康检查超时会导致 systemd 反复重启。这时我会先上 CDN 把静态资源挪走，再给 systemd 加内存上限。
③ 说清什么时候改：涨 100 倍时加机器很容易，但前提是先把状态从本地文件挪进共享存储——否则会得到两台各说各话的服务器。这个顺序不能反。
④ 主动提边界：CDN 的接入方案我已经写好了，应用层也准备好了（构建期可选的外部资源前缀
NEXT_PUBLIC_ASSET_PREFIX，/_next/static/*已经是 immutable）。但我还没执行，因为现在不是瓶颈，而改 DNS 会引入真实风险。
第 ④ 段是这段话里最值钱的部分。
因为它答的不是「我会不会改」，而是「我知道什么时候不该改」。绝大部分候选人会急着证明自己懂架构，把没做的优化说成做了、或者说不做就是不懂——这两样都是过度设计。
一句话版本
架构题不是考你会不会画图，是考你知不知道自己离问题还有多远——以及知不知道下一刀切在哪、什么时候切。
自测
- 你的系统现在平均 QPS 大概是多少？算得出来吗？
- 如果流量涨 10 倍，第一个崩的是什么？说得出具体现象吗？
- 为什么「先加机器」和「先挪状态」的顺序不能反？
- 「多机 → 容器编排」的成本台阶在哪里？什么时候才该跨？
- 你能说出一件你已经准备好、但故意还没做的优化吗？为什么不做？