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

第1步: 明確需求

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

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

(1) 功能性需求

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

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

(2) 非功能性需求

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

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

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

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

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

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

• 用戶數(shù)：預估系統(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)絡：根據(jù)估計的流量和數(shù)據(jù)傳輸大小估算帶寬需求。

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

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

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

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

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

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

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

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

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

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

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

• 選擇何種數(shù)據(jù)庫，關系型數(shù)據(jù)庫、NoSQL、ES等？還是多種數(shù)據(jù)庫的組合？
• 是否需要考慮數(shù)據(jù)結(jié)構(gòu)、可伸縮性、性能、一致性和查詢模式等因素？
• 關系數(shù)據(jù)庫（例如，MySQL、PostgreSQL）適用于具有復雜關系和 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)品、訂單）。
• 考慮實體之間的關系以及它們之間的交互方式。
• 確定與每個實體關聯(lián)的屬性或?qū)傩裕ɡ纾脩艟哂须娮余]件、姓名、地址）。
• 標識每個實體的任何唯一標識符或主鍵。
• 考慮規(guī)范化技術(shù)，以確保數(shù)據(jù)完整性并最大程度地減少冗余。

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

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

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

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

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

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

(1) 明確 API要求

• 確定系統(tǒng)需要通過 API公開的主要功能和服務。
• 考慮與 API交互的客戶端類型（例如，Web、移動、第三方服務）。
• 確定每個 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ù)模型設計清晰直觀的 API URL。
• 為API選擇適當?shù)?HTTP方法（例如，GET、POST、PUT、DELETE）。

第6步：細化組件設計

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

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

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

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

第7步: 解決關鍵問題

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

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

• 增加節(jié)點進行水平擴展（橫向擴展）。
• 增加單個資源（例如 CPU、內(nèi)存、存儲）的容量進行垂直擴展（縱向擴展）。
• 增加緩存以減少數(shù)據(jù)庫壓力并縮短響應時間。
• 優(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)在可靠性上的一些關鍵考慮因素：

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

總結(jié)

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

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

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