Grokking the System Design Interview 系統(tǒng)設(shè)計面試：一步步得指導(dǎo) -- （一）起步

翻譯自 Grokking the System Design Interview

許多軟件工程師，在系統(tǒng)設(shè)計面試(SDIs)是會很頭疼，主要有三個原因：

• SDIs 的非固定性，面試者往往被要求處理一個開放性、沒有標準答案的問題；
• 缺少大型系統(tǒng)的開發(fā)經(jīng)驗；
• 沒有為系統(tǒng)設(shè)計面試做好充分的準備。

和編寫面試代碼一樣，沒有特地為 SDI 做準備的面試者大多表現(xiàn)不佳。尤其是在谷歌、Facebook、亞馬遜和微軟這些頂級公司。在這些公司的面試，如果沒有表現(xiàn)得超過平均水平，就很少有機會能夠拿到 offer 了。另一方面，表現(xiàn)得出色往往能拿到一個更好的 offer（更高的職位和更多的薪資），因為這展示了面試者應(yīng)付復(fù)雜系統(tǒng)的能力。

在本節(jié)課程中，我們將一步步地解決多個系統(tǒng)設(shè)計問題。首先來瀏覽一下步驟：

第一步：明確需求

首先詢問我們要解決的問題的確切范圍總是好的。系統(tǒng)設(shè)計的問題大多是開放的，沒有標準的正確答案，因此在面試中對模糊的問題沒有明確是很危險的。

愿意花多一些時間來明確系統(tǒng)的目標的候選人是更有可能在面試中成功的。一次面試中往往只有 35 到 40 分鐘留給我們來設(shè)計一個復(fù)雜的系統(tǒng)，所以需要明確系統(tǒng)的哪一部分是需要更加關(guān)注的。

讓我們根據(jù)一個實際案例來進行擴展--設(shè)計一個類似「推特」的系統(tǒng)。在開始下一步之前，這里有一些設(shè)計「推特」相關(guān)的問題需要回答：

• 我們系統(tǒng)的用戶可以發(fā)布推文或者關(guān)注其他用戶嗎？
• 需要創(chuàng)建或者展示用戶的時間線嗎？
• 推文可能包含圖片和視頻嗎？
• 我們只關(guān)注后端開發(fā)，還是說前端也要呢？
• 用戶可以搜索推文嗎？
• 需要展示熱門話題嗎？
• 對于新的（或者重要的）推文，需要有推送能力嗎？

諸如此類的問題將會決定我們的系統(tǒng)設(shè)計會是什么樣子的。

第二步：系統(tǒng)接口定義

定義系統(tǒng)的 API 接口。這個過程不僅僅明確了系統(tǒng)需要的交互方式，同時也確保了需求沒有被錯誤的理解?！竿铺亍狗?wù)的 API 接口示例如下：

postTweet(user_id, tweet_data, tweet_location, user_location, timestamp, ...) // 發(fā)布推文
generateTimeline(user_id, current_time, user_location, ...) // 用戶時間線
markTweetFavorite(user_id, tweet_id, timestamp, ...) // 喜歡推文

第三步：預(yù)估背后的資源

評估將要設(shè)計系統(tǒng)的規(guī)模總是一個好主意。同時也將為后面要做的事情提供幫助，比如擴展、分區(qū)、負載均衡以及緩存等。

• 系統(tǒng)預(yù)期的規(guī)模是多少（比如推文的產(chǎn)生量、推文的展示量、時間線的生成速度）
• 需要多少存儲？如果推文包含圖片和視頻，這個數(shù)字可能會有很大差異
• 需要多少網(wǎng)絡(luò)帶寬？在控管理流量和負載均衡的過程中，這會是至關(guān)重要的因素。

第四步：定義數(shù)據(jù)模型

盡早的定義數(shù)據(jù)模型將會有助于明確數(shù)據(jù)在系統(tǒng)的多個組件內(nèi)的傳遞方式。稍后，這將知道如何做數(shù)據(jù)分區(qū)和治理。候選人需要能夠識別系統(tǒng)中的不同實體，這些實體之間怎么互相影響以及跟這些實體相關(guān)的各個方面，如存儲、傳輸、加密等。下面這些是類似「Tiwtter」系統(tǒng)服務(wù)的一些實體：

User: UserID, Name, Email, DoB, CreationData, LastLogin, etc.

Tweet: TweetID, Content, TweetLocation, NumberOfLikes, TimeStamp, etc. UserFollowo: UserdID1, UserID2 FavoriteTweets: UserID, TweetID, TimeStamp

我們要選擇使用哪種數(shù)據(jù)庫？像是 Cassandra 這種 NoSQL 是不是最能滿足我們的需求呢？還是要選擇類似 MySQL 的關(guān)系型數(shù)據(jù)庫呢？要使用哪種類型的塊存儲方案來存儲圖片和視頻呢？

第五步：上層設(shè)計

畫 5-6 個方框來展示系統(tǒng)的核心組件。我們需要明確需要哪些組件來端到端得解決實際的問題。
對于 Twitter，需要很多應(yīng)用服務(wù)來應(yīng)對所有的讀寫請求，同時在這些服務(wù)之前需要負載均衡。如果假定有更多的讀請求（相對于寫請求來說），可以設(shè)計很多分離的副本服務(wù)。在后端，需要一個高效的數(shù)據(jù)庫庫，可以存下所有的推文，同時可以支持大量的讀取。還需要一個分布式的文件存儲系統(tǒng)來存儲圖像和視頻。

第六步：細節(jié)設(shè)計

深入研究其中的兩到三個組件，面試官的反饋總是可以引導(dǎo)我們系統(tǒng)的哪些部分需要進行更深入得探討。我們需要針對不同的方案，分析各自的利弊，并且解釋為什么選擇其中的某個方案而不是其他的。
記住不是只有一個唯一的答案，最重要的是在考慮系統(tǒng)約束的同時，權(quán)衡不同方案的利弊。

• 由于我們要存儲很大量的數(shù)據(jù)，應(yīng)該怎么對數(shù)據(jù)進行分片從而存進多個數(shù)據(jù)庫？是否應(yīng)該將所有的用戶數(shù)據(jù)存在同一個數(shù)據(jù)庫里面呢？這可能導(dǎo)致什么問題？
• 應(yīng)該怎么處理某些特定的用戶數(shù)據(jù)呢，他們可能發(fā)布很多推文或者關(guān)注很多其他的用戶？
• 由于用戶的時間線將會包括最新的推文或者最相關(guān)的推文，是不是應(yīng)該考慮以某種特定的方式存儲用戶數(shù)據(jù)從而有利于獲取用戶最新推文呢？
• 應(yīng)該使用多少緩存來加速呢？在哪一個層次來加緩存呢？
• 哪個組件需要更好的負載均衡？

第七步：找出并解決瓶頸

嘗試找出盡可能多的系統(tǒng)瓶頸，并且考慮多種不同的方案來緩解。

• 系統(tǒng)是否存在單點問題？做什么可以緩解？
• 數(shù)據(jù)是否有副本，以至于如果其中的部分節(jié)點損壞仍然能對用戶提供服務(wù)？
• 同樣的，正在運行的服務(wù)是不是有足夠多的副本，其中的一部分失敗可能導(dǎo)致整個系統(tǒng)掛掉嗎？
• 怎么監(jiān)控系統(tǒng)的性能？當核心組件失敗或者性能下降，能收到監(jiān)控嗎？

總結(jié)

簡單地說，做好準備和面試中的條理性是 SDI（系統(tǒng)設(shè)計面試）中的取勝之匙。上述提到的步驟應(yīng)該指導(dǎo)面試者保持在正軌上，并且覆蓋所有的考慮面。
我們一起把上面的方法，用于下面幾個面試中常會問道的系統(tǒng)設(shè)計上面吧。