通常，軟件工程師在處理系統(tǒng)設計任務時遇到困難的主要原因有三個：

1. 系統(tǒng)設計任務往往沒有固定的結構，工程師需要處理一個開放性的設計問題，這些問題并沒有標準的解決方案。例如，在開發(fā)一個新的電商平臺時，可能需要從零開始設計整個后臺架構，而這個問題沒有唯一正確的答案。
2. 工程師在開發(fā)復雜和大規(guī)模系統(tǒng)方面的經(jīng)驗不足。例如，他們可能曾經(jīng)在小型項目中充當過主要的開發(fā)者，但在處理一個全球分布式的大型數(shù)據(jù)系統(tǒng)時，他們可能會感到力不從心。
3. 工程師沒有花足夠的時間來研究和準備如何解決系統(tǒng)設計的問題。例如，他們可能會對編碼技術有深入的了解，但卻沒有投入足夠的時間來學習和理解大規(guī)模系統(tǒng)設計的原則和模式。

在阿里、騰訊、百度和字節(jié)這樣的知名公司，如果一個工程師在系統(tǒng)設計上的表現(xiàn)不超過平均水平，他可能會發(fā)現(xiàn)自己在項目中的影響力有限。相反，表現(xiàn)良好的工程師總會得到更多的機會和認可，因為他們展示出了處理復雜系統(tǒng)的能力。

在這個課程中，我們將通過實際例子，按步驟解決多個設計問題。首先，讓我們來看看這些步驟：

步驟1：明確需求

我們在試圖解決問題時，首先要做的是詢問有關問題準確范圍的問題。設計問題通常是開放性的，并且沒有唯一正確的答案。這就是為什么在項目初期澄清模糊性至關重要?；ㄗ銐驎r間定義系統(tǒng)終極目標的參與者，總是更有可能在項目中取得成功。此外，由于我們只有35-40分鐘的時間來設計一個（可能）大型的系統(tǒng)，我們應該明確我們將關注系統(tǒng)的哪些部分。

讓我們用設計一個類似微博的服務的實際例子來擴展這一點。在進行下一步之前，設計微博應該回答的一些問題包括：

• 我們的服務用戶能夠發(fā)布微博并關注其他人嗎？
• 我們是否也需要設計創(chuàng)建和展示用戶的時間線？
• 微博中是否會包含照片和視頻？
• 我們是否只關注后端，還是也要開發(fā)前端？
• 用戶能否搜索微博？
• 我們需要展示熱門趨勢話題嗎？
• 是否會有新的（或重要的）微博的推送通知？

所有這些問題都將決定我們的最終設計會是什么樣子。

步驟2：規(guī)模預估

對我們即將設計的系統(tǒng)規(guī)模進行預估總是一個好的做法。這將有助于我們后續(xù)關注系統(tǒng)的擴展性、數(shù)據(jù)分區(qū)、負載均衡以及緩存策略。

系統(tǒng)預期的規(guī)模是什么（例如，新的微博數(shù)量，微博的閱讀數(shù)量，每秒生成時間線的次數(shù)等）？ 我們需要多少存儲空間？如果用戶可以在他們的微博中上傳照片和視頻，我們的存儲需求將有所不同。 我們預計將使用多少網(wǎng)絡帶寬？這將對我們?nèi)绾喂芾砹髁?、在服務器之間實現(xiàn)負載均衡至關重要。

步驟3：定義系統(tǒng)接口

需要明確系統(tǒng)所需的API。這將明確系統(tǒng)預期的具體協(xié)議，并確保我們對需求的理解沒有出錯。對于微博服務，API示例將會是：

postTweet(user_id, tweet_data, tweet_location, user_location, timestamp, …)

generateTimeline(user_id, current_time, user_location, …)

markTweetFavorite(user_id, tweet_id, timestamp, …)

步驟4：定義數(shù)據(jù)模型

在項目初期確定數(shù)據(jù)模型能夠明確數(shù)據(jù)如何在各個系統(tǒng)組件之間流動。隨后，它將成為數(shù)據(jù)分區(qū)和管理的指導。參與者需要確定各種系統(tǒng)實體，它們?nèi)绾蜗嗷ソ换?，以及?shù)據(jù)管理的各個方面，例如存儲、傳輸、加密等。對于微博系統(tǒng)的設計，以下是一些實體：

• 用戶：UserID, Name, Email, DoB, CreationDate, LastLogin等。
• 微博：TweetID, Content, TweetLocation, NumberOfLikes, TimeStamp等。
• 用戶關注：UserID1, UserID2。
• 喜歡的微博：UserID, TweetID, TimeStamp。

我們應該選擇哪種數(shù)據(jù)庫系統(tǒng)？我們是否應該選擇類似Cassandra這樣的NoSQL來滿足我們的需求，或者我們應該使用像MySQL這樣的解決方案？存儲照片和視頻應該使用哪種類型的塊存儲？

步驟5：高級設計

繪制一個包含5-6個表示我們系統(tǒng)核心組件的方框圖。我們需要確定足夠的組件，以便端到端地解決實際問題。

對于微博，從高層次來看，我們需要多個應用服務器來處理所有讀寫請求，同時在它們前面使用負載均衡器進行流量分配。如果我們預測讀取流量（相比寫入）會較大，我們可以決定使用單獨的服務器來處理這些情況。在后端，我們需要一個能夠存儲所有微博并支持大量讀取的高效數(shù)據(jù)庫。我們還需要一個分布式文件存儲系統(tǒng)來存儲照片和視頻。

步驟6：詳細設計

深入研究兩到三個主要組件；團隊成員的反饋應始終指導我們，系統(tǒng)的哪些部分需要進一步討論。我們應該提出不同的方法，它們的優(yōu)點和缺點，并解釋我們?yōu)楹螘靡环N方法而非另一種。記住，沒有唯一的答案；最重要的是在保持系統(tǒng)約束的同時，權衡不同選項之間的利弊。

由于我們將存儲大量的數(shù)據(jù)，我們應該如何對我們的數(shù)據(jù)進行分區(qū)，以將其分布到多個數(shù)據(jù)庫？我們是否應該嘗試將用戶的所有數(shù)據(jù)存儲在同一個數(shù)據(jù)庫中？這會引起什么問題？ 我們將如何處理那些頻繁發(fā)微博或者關注很多人的活躍用戶？ 由于用戶的時間線將包含最新的（和相關的）微博，我們是否應嘗試以優(yōu)化掃描最新微博的方式來存儲我們的數(shù)據(jù)？ 我們在哪個層次以及何時引入緩存以提速？ 哪些組件需要更好的負載均衡？

步驟7：識別和解決瓶頸

嘗試討論盡可能多的瓶頸，以及緩解這些瓶頸的不同方法。

我們的系統(tǒng)中有沒有任何單點故障？我們正在采取什么措施來減輕它？ 我們是否擁有足夠的數(shù)據(jù)副本，以便在失去一部分服務器的情況下，仍然能夠為用戶提供服務？ 同樣，我們是否有足夠的不同服務的副本在運行，以便幾個失敗不會導致系統(tǒng)完全停機？ 我們?nèi)绾伪O(jiān)控我們服務的性能？當關鍵組件失效或性能下降時，我們是否會得到警報？

總結

簡而言之，在項目設計階段的準備和組織是系統(tǒng)設計成功的關鍵。上述步驟應該指導你在設計系統(tǒng)時保持正確的方向，并覆蓋所有不同的方面。