在頂級(jí)互聯(lián)網(wǎng)公司面試中，光靠背模式、畫圖和記住技術(shù)名詞遠(yuǎn)遠(yuǎn)不夠。

本文作者通過一次 Google L7 面試，深刻體會(huì)到系統(tǒng)設(shè)計(jì)的真正考驗(yàn)——不是“能畫出漂亮架構(gòu)圖”，而是能否理解系統(tǒng)為何而生、如何應(yīng)對(duì)極端故障，以及在復(fù)雜權(quán)衡中做出合理決策。

從 URL 縮短器的小題目，到 Netflix Chaos Monkey 的極端案例，本文帶你透視高級(jí)工程師眼中的系統(tǒng)設(shè)計(jì)邏輯，理解“紙上建筑師”和真正實(shí)戰(zhàn)高手之間的差距。

原文鏈接：https://medium.com/expocomputing/google-l7-system-design-interview-lessons-0b3834fded07

作者 | Cloud With Azeem 責(zé)編 | 蘇宓

出品 | CSDN（ID：CSDNnews）

我走進(jìn)面試房間時(shí)，帶著一種“胸有成竹”的淡定自信。因?yàn)槲矣涀×怂兴{(lán)圖，知道 MongoDB 和 Cassandra 的區(qū)別，能閉著眼睛畫出內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）的架構(gòu)，Netflix 的技術(shù)棧就像圣經(jīng)一樣刻在我的腦海里。

我準(zhǔn)備好談?wù)撐⒎?wù)、分片和高可用性了。

然后，我見到了面試官——一位說話輕聲細(xì)語的 Google L7 級(jí)工程師。過去十年間，這位面試官一直在維護(hù)那些每秒處理流量比大多數(shù)應(yīng)用一年還多的系統(tǒng)。

他給我的題目看似簡(jiǎn)單：“設(shè)計(jì)一個(gè) URL 縮短器?！?/p>

看到這個(gè)題目，我輕笑了一下。

這不過就是系統(tǒng)設(shè)計(jì)的“Hello World”入門必備題目。于是，我拿起馬克筆，開始飛快地勾勒出系統(tǒng)的各種細(xì)節(jié)。這里放 API Gateway，那里放負(fù)載均衡器，一個(gè) NoSQL 數(shù)據(jù)庫存儲(chǔ)映射，再加一個(gè) Redis 緩存保證響應(yīng)迅速。我甚至還在面試時(shí)候提到了 O(1) 查找和 Base62 編碼。

到這里，我覺得自己的表現(xiàn)非常不錯(cuò)，感覺自己像個(gè)搖滾明星。

此時(shí)，他向前傾身，向我拋了一個(gè)問題：“這對(duì)一個(gè)只有幾千用戶的初創(chuàng)公司來說，確實(shí)不錯(cuò)。但如果寫入量達(dá)到每秒 1000 萬呢，你的架構(gòu)會(huì)發(fā)生什么變化？特別是，你選的數(shù)據(jù)庫在那個(gè)規(guī)模下如何處理預(yù)寫式日志（WAL）競(jìng)爭(zhēng)？”

因?yàn)檫@個(gè)問題，我的馬克筆懸在半空，冷汗順著背脊滑下。我懂模式，但不懂這些系統(tǒng)背后的物理邏輯。我意識(shí)到自己只是個(gè)“紙上建筑師”——一個(gè)能畫圖，但從沒真正走過實(shí)際的地形的人。

模式匹配的幻象

我們中的大多數(shù)人都會(huì)陷入模式陷阱。我們通過觀察“大公司”的做法學(xué)習(xí)系統(tǒng)設(shè)計(jì)?？吹?LinkedIn 放棄某些遺留系統(tǒng)，或者讀到他們 Kafka 替代方案和新的流處理系統(tǒng)，就會(huì)立刻想：“好吧，LinkedIn 都這樣做了，我也應(yīng)該這樣做?！?/p>

但 L7 面試官并不關(guān)心你能否復(fù)制 LinkedIn。他關(guān)心的是你是否理解 LinkedIn 為什么必須這么做。

大廚與學(xué)徒的類比

把系統(tǒng)設(shè)計(jì)比作烹飪。學(xué)徒廚師按食譜做事（模式）。食譜說“加鹽”，他們就加鹽。但大廚懂化學(xué)原理。如果今天的番茄更酸，他會(huì)調(diào)整糖量。他不會(huì)盲目照搬食譜，而是根據(jù)食材調(diào)整。

在系統(tǒng)設(shè)計(jì)中，你的“食材”是約束條件：

• 延遲預(yù)算（有多快？）
  

• 吞吐量要求（處理多少？）

• 數(shù)據(jù)一致性（有多準(zhǔn)確？）

如果你無法告訴我為什么選擇某個(gè)工具——比如為什么可能放棄 Terraform，改用更可編程或狀態(tài)管理的方案——那么你不是在設(shè)計(jì)，你只是背誦。

橫向擴(kuò)展并非萬能解

那次面試中，最讓我豁然開朗的時(shí)刻之一是關(guān)于討論擴(kuò)展性時(shí)。我一直說：“我們只要增加節(jié)點(diǎn)就行了?！睓M向擴(kuò)展是初級(jí)到中級(jí)工程師常用的萬能辦法。

面試官打斷我：“你每加一個(gè)節(jié)點(diǎn)，就增加一次網(wǎng)絡(luò)跳轉(zhuǎn)。每次網(wǎng)絡(luò)跳轉(zhuǎn)都有故障概率。你的 1000 個(gè)節(jié)點(diǎn)的協(xié)調(diào)開銷什么時(shí)候會(huì)比單臺(tái)高度優(yōu)化的垂直機(jī)器更慢？”

案例研究：集群擠兌問題（Thundering Herd）

想象一下，一家世界聞名的面包店，每天 9 點(diǎn)免費(fèi)發(fā)杯子蛋糕。如果只有一扇門，大家都會(huì)擁到門口（垂直瓶頸）。如果加十扇門（橫向擴(kuò)展），人群會(huì)分散。但如果十扇門都通向同一盤蛋糕呢？現(xiàn)在，十倍的人同時(shí)沖向單點(diǎn)，造成擁擠。

在 URL 縮短器中，如果某條鏈接病毒式傳播（比如超級(jí)碗廣告），那么你的每個(gè)“橫向擴(kuò)展”的服務(wù)器都會(huì)同時(shí)擊打數(shù)據(jù)庫的同一行或緩存的同一 key。這就是 Hot Key 問題。加服務(wù)器反而更糟，因?yàn)樵黾恿送黄款i的并發(fā)請(qǐng)求。

解決方法不僅僅是“擴(kuò)展”。你可能需要請(qǐng)求合并（多個(gè)相同請(qǐng)求等待一次數(shù)據(jù)庫讀?。┗蜃赃m應(yīng)緩存。

這種思考方式區(qū)分了高級(jí)工程師和普通工程師。

失敗的架構(gòu)：從混亂中推理

Google 的 L7 工程師沒問我“這個(gè)是怎么工作的”，而是問“它怎么出問題的？”

他逼我思考極端情況：“你在 US-East 的主數(shù)據(jù)庫著火了，US-West 的故障切換啟動(dòng)，但網(wǎng)絡(luò)鏈路只開放 10% 帶寬。用戶會(huì)看到什么？”

我意識(shí)到我沒考慮狀態(tài)不一致。頭腦中，“failover”是個(gè)魔法按鈕，實(shí)際上如果處理不當(dāng)，這是數(shù)據(jù)丟失的災(zāi)難。這就是單體 vs 微服務(wù)爭(zhēng)論真正落地的地方。單體架構(gòu)中這是一次大失敗，微服務(wù)是成千上萬的小失敗，調(diào)試難度更大。

Netflix Chaos Monkey 案例

Netflix 就以這種做法而聞名。他們意識(shí)到，在分布式系統(tǒng)中，故障不是一種可能性，而是一種必然性。他們?cè)O(shè)計(jì)了 “Chaos Monkey”（混沌猴子），在生產(chǎn)環(huán)境中隨機(jī)關(guān)閉服務(wù)器。

為什么？

為了迫使他們的工程師設(shè)計(jì)出具有自我修復(fù)能力的系統(tǒng)。

如果我設(shè)計(jì)一個(gè)每秒 1000 萬寫的 URL 縮短器，我必須假設(shè)：

1. 緩存會(huì)宕機(jī)
   

2. 磁盤會(huì)滿

3. 短碼生成器會(huì)產(chǎn)生重復(fù)

如果你的設(shè)計(jì)沒有應(yīng)對(duì)“黑天鵝”事件的方案，那它只是幻想。

“無緩存”思維的力量

最讓我震撼的時(shí)刻，是面試官挑戰(zhàn)我對(duì) Redis 的依賴：“不使用分布式緩存，重新設(shè)計(jì)?！?/p>

我愣住：“但…延遲會(huì)很糟！”

他反問：“真的會(huì)嗎？如果 90% 的短鏈只被點(diǎn)擊一次（數(shù)據(jù)的‘長(zhǎng)尾’），你的緩存命中率只有 10%。這樣每個(gè)請(qǐng)求都要先查緩存、再落到數(shù)據(jù)庫，反而增加了延遲。你為 90% 的流量增加了 5ms 的開銷，卻毫無意義?！?/p>

這徹底顛覆了我的認(rèn)知。以前學(xué)到的“Cache = 快”，實(shí)際有效延遲公式是：

有效延遲 = (命中率 × 緩存延遲) + ((1 — 命中率) × 數(shù)據(jù)庫延遲)

當(dāng)命中率低時(shí)，管理分布式緩存的開銷（和陳舊數(shù)據(jù)風(fēng)險(xiǎn)）超過了收益。面試官想看到我是否有勇氣說：“這里暫時(shí)不需要緩存。”

工程是權(quán)衡的藝術(shù)

兩個(gè)小時(shí)后，我的白板布滿劃掉的框和重寫的邏輯。但這是第一次，我感覺設(shè)計(jì)真實(shí)存在。它不是教材里的圖，而是經(jīng)過戰(zhàn)火洗禮的計(jì)劃。

我學(xué)到了，系統(tǒng)設(shè)計(jì)不是找“正確答案”。沒有正確答案，只有權(quán)衡：

• 一致性 vs 可用性：是保證用戶看到精確數(shù)據(jù)，還是保證頁面能加載，即便數(shù)據(jù)滯后幾秒？
  

• 延遲 vs 成本：是追求 <10ms 延遲，還是控制預(yù)算？

• 復(fù)雜度 vs 可維護(hù)性：是構(gòu)建 50 個(gè)微服務(wù)的“完美”系統(tǒng)，還是一個(gè)三人團(tuán)隊(duì)能管理的可維護(hù)系統(tǒng)？

L7 面試該如何準(zhǔn)備

要超越“死記硬背模式”的局限，你需要改變學(xué)習(xí)方法：

1. 不只是畫框，而要解釋成本。每次加負(fù)載均衡或消息隊(duì)列，問自己：成本是多少？延遲是多少？維護(hù)成本是多少？
   

2. 從“裸機(jī)”開始。先設(shè)計(jì)只有一臺(tái)服務(wù)器和一個(gè)數(shù)據(jù)庫的系統(tǒng)，再根據(jù)數(shù)字證明需要增加復(fù)雜性。
   

3. 學(xué)會(huì)數(shù)學(xué)。無需成為數(shù)學(xué)家，但要能估算 QPS、5 年存儲(chǔ)需求、帶寬需求。
   

4. 研究真實(shí)的故障案例。讀 AWS、Cloudflare、Slack 等公司的事故分析報(bào)告，看看他們“完美”設(shè)計(jì)在現(xiàn)實(shí)中如何失敗。真正的學(xué)習(xí)就在那里。

停止像收集寶可夢(mèng)卡片一樣收集圖案了，開始理解每條設(shè)計(jì)背后的“為什么”。在現(xiàn)實(shí)世界——以及高級(jí)面試中——白板不在乎你的圖有多漂亮，它在乎你的邏輯。

【活動(dòng)分享】 "48 小時(shí)，與 50+ 位大廠技術(shù)決策者，共探 AI 落地真路徑。"

由 CSDN&奇點(diǎn)智能研究院聯(lián)合舉辦的「全球機(jī)器學(xué)習(xí)技術(shù)大會(huì)」正式升級(jí)為「奇點(diǎn)智能技術(shù)大會(huì)」。2026 奇點(diǎn)智能技術(shù)大會(huì)將于 4 月 17-18 日在上海環(huán)球港凱悅酒店正式召開，大會(huì)聚焦大模型技術(shù)演進(jìn)、智能體系統(tǒng)工程、OpenClaw 生態(tài)實(shí)踐及 AI 行業(yè)落地等十二大專題板塊，特邀來自BAT、京東、微軟、小紅書、美團(tuán)等頭部企業(yè)的 50+ 位技術(shù)決策者分享實(shí)戰(zhàn)案例。旨在幫助技術(shù)管理者與一線 AI 落地人員規(guī)避選型風(fēng)險(xiǎn)、降低試錯(cuò)成本、獲取可復(fù)用的工程方法論，真正實(shí)現(xiàn) AI 技術(shù)的規(guī)?；涞嘏c商業(yè)價(jià)值轉(zhuǎn)化。這不僅是一場(chǎng)技術(shù)的盛宴，更是決策者把握 2026 AI 拐點(diǎn)的戰(zhàn)略機(jī)會(huì)。