一. 識別系統復雜度

架構設計的本質目的是為了解決軟件系統的復雜性，所以在我們設計架構時，首先就要分析系統的復雜性。只有正確分析出了系統的復雜性，后續的架構設計方案才不會偏離方向；否則，如果對系統的復雜性判斷錯誤，即使后續的架構設計方案再完美再先進，都是南轅北轍，做得越好，錯得越多、越離譜。架構的復雜度主要來源于“高性能”、“高可用”、“可擴展”等幾個方面，架構師在具體判斷復雜性的時候，不能生搬硬套，認為任何時候架構都必須同時滿足這三方面的要求。實際上大部分場景下，復雜度只是其中的某一個，少數情況下包含其中兩個，如果真的出現同時需要解決三個或者三個以上的復雜度，要么說明這個系統之前設計的有問題，要么可能就是架構師的判斷出現了失誤，即使真的認為要同時滿足這三方面的要求，也必須要進行優先級排序。

二. 設計備選方案

架構設計備選方案的工作更多的是從需求、團隊、技術、資源等綜合情況出發，對主流、成熟的架構模式進行選擇、組合、調整、創新。設計備選方案應注意的幾個事項：

①　備選方案不要過于詳細。備選階段解決的是技術選型問題，而不是技術細節。

②　備選方案的數量以 3~5個為最佳。

③　備選方案的技術差異要明顯。

④　備選方案不要只局限于已經熟悉的技術。

三. 評估和選擇備選方案

評估和選擇備選方案，需要重點關注質量屬性。質量屬性包括性能、可用性、安全性、可擴展性等。這些屬性在我往期的文章中有講過，大家可以查閱。在評估這些質量屬性時，需要遵循架構設計原則“合適原則”和“簡單原則”， 避免貪大求全，基本上某個質量屬性能夠滿足一定時期內業務發展就可以了。在評估和選擇備選方案時，常用的做法，可以列舉這些重要的質量屬性，然后一一把它放到每一個方案中進行打分，打分時要充分考慮到團隊目前的技術能力、資源分配、項目成本、外部風險等因素，最終把每一項分值加起來進行權衡，從而選出一個最優的方案。

四. 詳細方案設計

詳細方案設計就是將最終確定的備選方案進行細化，使得備選方案變成一個可以落地的設計方案。詳細方案設計包含以下幾個方面：

1. 數據存儲設計。需要根據業務評估一下5年內業務數據量，然后考慮數據庫技術選型、針對一些數據增加比較快的業務考慮是否采用分表分庫或大數據的方式進行處理。另外，需要考慮數據庫的備份及容災、高并發場景下的可用性、一致性解決方案。

2. 通信協議設計。通信協議設計，需要根據業務特點、業務性能要求、業務安全性來決定采用什么協議？比如一個物聯網系統，設備端與服務端通信通常采用MQTT或COAP協議，微服務架構中，服務間內部調用通常使用HTTP(S)或RPC協議等等。作為一名架構人員，這些協議的優缺點及原理一定要搞清楚。另外通信協議設計中，對于報文的設計也有要求，報文的大小、報文的數據結構都是要重點考慮的，因為在高并發下場景下，這些細節可能會影響到系統的整體性能。

3. 接口設計。接口設計主要體現在幾個方面，一是接口的友好性，指的是入參和返回值命名規范、接口參數說明、調用示例等；二是接口的隔離原則，記住一個接口只干一件事情；三是接口的安全性，這點很重要，一般會被很多人忽略掉。接口的安全性保障一般采取令牌訪問機制、數據簽名/驗簽、白名單訪問機制等。

4. 緩存和消息隊列設計。緩存和消息隊列設計時，一定要根據業務特點選取合適的組件，目前業界有很多這方面的開源組件，在選型時千萬不能盲從。另外緩存和消息隊列設計時，需要考慮緩存和消息隊列自身單點故障問題。

好了，這篇文章就講這么多，大家好對架構設計流程有個初步的認識。大家有問題可以在評論區留言，陸續分享更多架構方面的知識，感興趣的同學別忘了加關注喲！

總結

以上是生活随笔為你收集整理的软件系统架构设计必须掌握的4步流程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。