不管是技術(shù)面試，還是日常開發(fā)，系統(tǒng)設(shè)計(jì)都是一個(gè)非常具備挑戰(zhàn)性的技術(shù)點(diǎn)，特別是往技術(shù)管理崗或者高P崗位發(fā)展時(shí)，系統(tǒng)設(shè)計(jì)能力更是一個(gè)必備技能，因此，有沒有什么結(jié)構(gòu)化的方法，可以幫助我們更好地駕馭它呢？這篇文章，我們將通過 7個(gè)步驟詳細(xì)分析如何設(shè)計(jì)系統(tǒng)。

第1步: 明確需求

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

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

(1) 功能性需求

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

• 系統(tǒng)應(yīng)支持哪些核心功能？
• 是否有任何特定功能比其他功能更重要？
• 誰將使用這個(gè)系統(tǒng)（客戶、技術(shù)團(tuán)隊(duì)、客服等）？
• 用戶應(yīng)該能夠在系統(tǒng)上執(zhí)行哪些特定操作？
• 用戶將如何與系統(tǒng)交互（Web、移動(dòng)應(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ì)量屬性和性能，主要包含以下幾個(gè)點(diǎn)：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(1) 明確 API要求

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

(2) 選擇 API類型

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

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

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

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

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

作為 Java后端，你需要了解自己業(yè)務(wù)的領(lǐng)域，比如金融，電商，財(cái)務(wù)，出行等，因?yàn)椴煌念I(lǐng)域會(huì)有一定的差異性。下面是組件細(xì)化的一些考慮點(diǎn)：

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

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

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

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

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

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

(2) 解決可靠性問題

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

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

總結(jié)

最后，我們再總結(jié)下系統(tǒng)設(shè)計(jì)的 7個(gè)步驟：

• 第1步: 明確需求
• 第2步: 系統(tǒng)容量預(yù)估
• 第3步: 架構(gòu)設(shè)計(jì)
• 第4步: 數(shù)據(jù)庫設(shè)計(jì)
• 第5步: API設(shè)計(jì)和通信協(xié)議
• 第6步: 細(xì)化組件設(shè)計(jì)
• 第7步: 解決關(guān)鍵問題

有了上述 7個(gè)步驟，在做系統(tǒng)設(shè)計(jì)時(shí)就有一個(gè)清晰的思路，最終方案如何實(shí)施還需要結(jié)合實(shí)際的業(yè)務(wù)以及最終的權(quán)衡來定。另外，上述 7個(gè)步驟也可以幫助我們輕松的應(yīng)對面試中的各種系統(tǒng)設(shè)計(jì)問題。