在技術(shù)面試中，系統(tǒng)設(shè)計能力被認為是非常重要的一項技能，尤其是對于中高級工程師或架構(gòu)師職位。這種能力不僅僅是編寫代碼的技巧，還涉及到解決復雜問題、設(shè)計高效和可擴展系統(tǒng)的能力。那么，有沒有什么結(jié)構(gòu)化的方法，可以幫助我們更好地設(shè)計系統(tǒng)？這篇文章，我們來聊一聊。

 設(shè)計思想

在系統(tǒng)設(shè)計中，主要包括兩個關(guān)鍵階段：High Level（也稱宏觀設(shè)計）和 Low Level（也稱為詳細設(shè)計）。

宏觀設(shè)計是系統(tǒng)設(shè)計的初始階段，主要關(guān)注系統(tǒng)的整體架構(gòu)和主要組件的設(shè)計。這一階段的目標是定義系統(tǒng)的結(jié)構(gòu)、各組件之間的關(guān)系以及系統(tǒng)如何滿足高層次的需求。

微觀設(shè)計是系統(tǒng)設(shè)計的后續(xù)階段，關(guān)注具體組件和模塊的詳細實現(xiàn)。這一階段的目標是為每個組件和模塊提供詳細的設(shè)計，以指導開發(fā)工作。

為了更好地理解上面的設(shè)計思想，我們通過下面的 7個步驟來詳細說明系統(tǒng)設(shè)計過程。

第1步: 明確需求

不管是系統(tǒng)設(shè)計還是業(yè)務(wù)開發(fā)，都必須先弄清楚需求，這好比是回答別人的提問，如果連對方的問題都沒有弄清楚，后面所有的回答都可能是答非所問。

因此，系統(tǒng)設(shè)計的第一步是徹底理解需求，從實際工作經(jīng)驗來看，需求主要包括 2種類型：功能性需求和非功能性需求。

1() 功能性需求

功能性需求是指系統(tǒng)需要執(zhí)行的功能和行為，也就是系統(tǒng)實實在在要完成的功能，主要包含以下幾個點：

• 系統(tǒng)應(yīng)支持哪些核心功能？
• 是否有任何特定功能比其他功能更重要？
• 誰將使用這個系統(tǒng)（客戶、技術(shù)團隊、客服等）？
• 用戶應(yīng)該能夠在系統(tǒng)上執(zhí)行哪些特定操作？
• 用戶將如何與系統(tǒng)交互（Web、移動應(yīng)用程序、API 等）？
• 系統(tǒng)是否需要支持多語言？
• 系統(tǒng)必須處理哪些關(guān)鍵數(shù)據(jù)類型（文本、圖像、結(jié)構(gòu)化數(shù)據(jù)等）？
• 系統(tǒng)是否需要集成外部系統(tǒng)或三方服務(wù)？

(2) 非功能性需求

非功能性需求是指系統(tǒng)的質(zhì)量屬性和性能，主要包含以下幾個點：

• 系統(tǒng)的預(yù)期規(guī)模是多少？
• 系統(tǒng)預(yù)計要處理多少數(shù)據(jù)量？
• 系統(tǒng)的輸入和輸出是什么？
• 預(yù)期的讀寫比是多少？
• 系統(tǒng)是否可以停機，或者是否需要高可用性？
• 是否有任何特定的延遲要求？
• 數(shù)據(jù)一致性有多重要？為了可用性，是否可以容忍一些最終的一致性？
• 是否有任何特定的非功能性需求（性能、可伸縮性、可靠性）我們應(yīng)該關(guān)注？

需求是整個系統(tǒng)設(shè)計的風向標，因此，明確需求是整個系統(tǒng)設(shè)計的第一步，盡早地弄清楚需求，可以幫助我們更好的把握系統(tǒng)走向。

第2步: 系統(tǒng)容量預(yù)估

在明確了需求之后，第二步要完成的事情就是評估系統(tǒng)的容量，只有知道了系統(tǒng)的容量，才能更好的預(yù)算開發(fā)周期、人力投入、服務(wù)器投入以及其他的投入，幫助我們更好地做好后期決策。

系統(tǒng)容量預(yù)估，一般需要評估以下幾個指標：

• 用戶數(shù)：預(yù)估系統(tǒng)需要支撐的總用戶數(shù)以及高峰時段的活躍用戶數(shù)和最大并發(fā)用戶數(shù)。
• 流量：計算日常TPS/QPS，以及峰值時的TPS/QPS。
• 存儲：需要存儲的數(shù)據(jù)類型（結(jié)構(gòu)化、非結(jié)構(gòu)化等），以及所需的存儲總量（及其增長率）。
• 內(nèi)存：估計系統(tǒng)可能消耗的內(nèi)存總量。
• 網(wǎng)絡(luò)：根據(jù)估計的流量和數(shù)據(jù)傳輸大小估算帶寬需求。

另外，系統(tǒng)設(shè)計還需要做未來增長和可伸縮性要求考慮，比如支持數(shù)據(jù)幾倍的增長以及支撐幾年的數(shù)據(jù)增長，以確保系統(tǒng)能夠處理隨時間推移而增加的負載。

第3步: 架構(gòu)設(shè)計

在做完需求分析和容量評估這些準備工作之后，我們就可以進入真正的設(shè)計階段，系統(tǒng)設(shè)計（High-Level Design，HLD）是軟件開發(fā)生命周期中最重要也是最難的一個階段。

架構(gòu)設(shè)計是一個宏觀上的考慮，旨在定義系統(tǒng)的總體結(jié)構(gòu)和高層次的架構(gòu)，在這個階段需要完成系統(tǒng)整體設(shè)計的藍圖，幫助開發(fā)團隊理解和規(guī)劃系統(tǒng)的各個組件及其相互關(guān)系，下圖是 Google的一張系統(tǒng)設(shè)計藍圖：

通過上述的藍圖可以看出：系統(tǒng)設(shè)計藍圖中包含以下主要組件：

• DNS：DNS是一種分布式系統(tǒng)，由許多域名服務(wù)器和域名解析器組成，提供名稱解析服務(wù)，將域名轉(zhuǎn)換成IP。
• 客戶端應(yīng)用程序：表明用戶將如何與系統(tǒng)（Web 瀏覽器、移動應(yīng)用程序、桌面應(yīng)用程序等）進行交互。
• Web服務(wù)器：處理和響應(yīng)客戶端請求的服務(wù)器。
• 負載均衡器：用于將流量均勻地分配到服務(wù)器以處理大量流量。
• 應(yīng)用程序服務(wù)：實現(xiàn)系統(tǒng)核心功能的后端邏輯層。
• 數(shù)據(jù)庫：指定數(shù)據(jù)庫類型：SQL 與 NoSQL，并簡要說明原因。
• 緩存層：指定緩存（例如。Redis， Memcached），用于減少數(shù)據(jù)庫的負載。
• 消息隊列：如果系統(tǒng)需要使用異步通信。
• 外部服務(wù)：如果系統(tǒng)依賴于第三方 API（例如支付網(wǎng)關(guān)），請將其包括在內(nèi)。

對于每個組件，一定要考慮權(quán)衡取舍，并說明為什么選擇特定的技術(shù)或架構(gòu)，關(guān)于設(shè)計圖的繪制時，不要過度考慮小細節(jié)，而是更多站在宏觀的角度。小細節(jié)可以在每個組件的設(shè)計中去推敲。

第4步: 數(shù)據(jù)庫設(shè)計

絕大多數(shù)系統(tǒng)是需要和數(shù)據(jù)打交道的，因此數(shù)據(jù)庫的設(shè)計也就顯得至關(guān)重要，數(shù)據(jù)庫設(shè)計通常包括數(shù)據(jù)庫選型、數(shù)據(jù)建模、數(shù)據(jù)庫結(jié)構(gòu)設(shè)計等。

(1) 數(shù)據(jù)庫選型

數(shù)據(jù)庫選型通常是根據(jù)業(yè)務(wù)場景以確定最合適的數(shù)據(jù)庫類型，主要包含以下幾個考慮因素：

• 選擇何種數(shù)據(jù)庫，關(guān)系型數(shù)據(jù)庫、NoSQL、ES等？還是多種數(shù)據(jù)庫的組合？
• 是否需要考慮數(shù)據(jù)結(jié)構(gòu)、可伸縮性、性能、一致性和查詢模式等因素？
• 關(guān)系數(shù)據(jù)庫（例如，MySQL、PostgreSQL）適用于具有復雜關(guān)系和 ACID屬性的結(jié)構(gòu)化數(shù)據(jù)。
• NoSQL數(shù)據(jù)庫（例如 MongoDB、Cassandra）適用于非結(jié)構(gòu)化或半結(jié)構(gòu)化數(shù)據(jù)、高可擴展性和最終一致性。

(2) 數(shù)據(jù)建模

數(shù)據(jù)建模通常會考慮以下因素：

• 確定系統(tǒng)需要存儲和管理的主要數(shù)據(jù)實體或?qū)ο螅ɡ?，用戶、產(chǎn)品、訂單）。
• 考慮實體之間的關(guān)系以及它們之間的交互方式。
• 確定與每個實體關(guān)聯(lián)的屬性或?qū)傩裕ɡ纾脩艟哂须娮余]件、姓名、地址）。
• 標識每個實體的任何唯一標識符或主鍵。
• 考慮規(guī)范化技術(shù)，以確保數(shù)據(jù)完整性并最大程度地減少冗余。

(3) 數(shù)據(jù)庫結(jié)構(gòu)設(shè)計

數(shù)據(jù)庫結(jié)構(gòu)設(shè)計也就是真實的表結(jié)構(gòu)設(shè)計，主要需要考慮以下因素：

• 根據(jù)所選的數(shù)據(jù)庫類型定義表、列、數(shù)據(jù)類型和關(guān)系。
• 設(shè)計主鍵、外鍵等。
• 設(shè)置合理的索引以優(yōu)化查詢性能。

另外，在更宏觀的角度上，還需要考慮分庫分表，多活，災(zāi)備等問題。

第5步: API設(shè)計和通信協(xié)議

API和通信協(xié)議，它定義了系統(tǒng)內(nèi)不同的組件間該如何交互以及外部客戶端如何訪問系統(tǒng)的功能，通常會考慮以下因素：

(1) 明確 API要求

• 確定系統(tǒng)需要通過 API公開的主要功能和服務(wù)。
• 考慮與 API交互的客戶端類型（例如，Web、移動、第三方服務(wù)）。
• 確定每個 API的數(shù)據(jù)輸入、輸出和其他要求。

(2) 選擇 API類型

• 根據(jù)系統(tǒng)要求和客戶需求選擇合適的 API類型。
• RESTful API通常用于基于 Web 的系統(tǒng)，并為資源操作提供統(tǒng)一的接口。
• GraphQL API為客戶端查詢和檢索特定數(shù)據(jù)字段提供了一種靈活高效的方法。
• RPC（遠程過程調(diào)用）API適用于具有明確定義的過程或功能的系統(tǒng)。

(3) 定義API協(xié)議

• 根據(jù)系統(tǒng)的功能和數(shù)據(jù)模型設(shè)計清晰直觀的 API URL。
• 為API選擇適當?shù)?HTTP方法（例如，GET、POST、PUT、DELETE）。

第6步：細化組件設(shè)計

在第3步中，我們分析了架構(gòu)設(shè)計，但是它從宏觀上的一個把握，而不會過分的關(guān)注細節(jié)，因此在此步驟中，我們需要對第3步中的一些核心組件進行更詳細的設(shè)計，這里以 Java后端為例：

作為 Java后端，你需要了解自己業(yè)務(wù)的領(lǐng)域，比如金融，電商，財務(wù)，出行等，因為不同的領(lǐng)域會有一定的差異性。下面是組件細化的一些考慮點：

• 三高系統(tǒng)：是否是高可用，高性能，高擴展性的系統(tǒng)？如何保證三高？
• 微服務(wù)：是否采用微服務(wù)，微服務(wù)的框架是什么，SpringCloud還是 Dubbo？
• 架構(gòu)：是否需要使用DDD架構(gòu)？
• 數(shù)據(jù)庫：是否需要分庫分表？是否需要多活設(shè)計？是否需要定時備份？
• 負載均衡器：使用哪些負載均衡技術(shù)和算法？
• 緩存：使用什么緩存？緩存放在哪里？如何處理緩存失效？
• 單點故障：是否有單點問題？如何解決單點問題？
• 身份驗證/授權(quán)：如何安全地管理用戶訪問和權(quán)限？
• 速率限制：如何防止過度使用或濫用 API？
• 安全問題：如何保證系統(tǒng)安全和API安全？

以下都是在后端組件中需要考慮的問題，當然，我們需要根據(jù)自己所處的角色和領(lǐng)域，靈活的設(shè)計。

第7步: 解決關(guān)鍵問題

系統(tǒng)設(shè)計中難免會遇到一些技術(shù)難點以及核心挑戰(zhàn)，這些挑戰(zhàn)主要包括可擴展性和性能，以及可靠性、安全性和成本問題。為了更好地解決這些問題，下面也給出了具體的思路：

(1) 解決可擴展性和性能問題

• 增加節(jié)點進行水平擴展（橫向擴展）。
• 增加單個資源（例如 CPU、內(nèi)存、存儲）的容量進行垂直擴展（縱向擴展）。
• 增加緩存以減少數(shù)據(jù)庫壓力并縮短響應(yīng)時間。
• 優(yōu)化數(shù)據(jù)結(jié)構(gòu)和算法。
• 優(yōu)化數(shù)據(jù)庫查詢和索引。
• 數(shù)據(jù)庫分區(qū)和分庫分片可提高查詢性能。
• 增加CDN，加速靜態(tài)資源訪問。
• 利用異步編程模型高效處理并發(fā)請求。

(2) 解決可靠性問題

可靠性是指系統(tǒng)即使在出現(xiàn)故障或錯誤的情況下也能正確和一致地運行的能力。以下是系統(tǒng)在可靠性上的一些關(guān)鍵考慮因素：

• 識別系統(tǒng)架構(gòu)中的單點問題，通過集群等方式消除單點故障。
• 服務(wù)或者數(shù)據(jù)做多活，以防止區(qū)域故障或災(zāi)難。
• 數(shù)據(jù)備份，確保數(shù)據(jù)可用性和持久性。
• 限流和降級機制，以防止級聯(lián)故障并保護系統(tǒng)免受過載影響。
• 加強監(jiān)控和警報，以及時檢測故障、性能問題和異常情況。

總結(jié)

本文，我們詳細地分析了如何設(shè)計系統(tǒng)，從思想層面到具體實施過程，從宏觀角度到微觀落地，并且通過 7個步驟詳細地描述了系統(tǒng)設(shè)計的思路。

百種業(yè)務(wù)百種架構(gòu)，在現(xiàn)實工作中，很難存在適用于任何業(yè)務(wù)的萬精油設(shè)計，但是思維方式卻是相通的，因此，實際業(yè)務(wù)中采用什么架構(gòu)方式需要根據(jù)具體情況權(quán)衡。