本文包含軟體架構的重要性、定義及其常見模式，架構對系統成功的影響，五種主要的架構模式及其最佳應用場景，評估優秀架構的關鍵質量屬性。
關注TechLead，復旦博士，分享雲服務領域全維度開發技術。擁有10+年網際網路服務架構、AI產品研發經驗、團隊管理經驗，復旦機器人智慧實驗室成員，國家級大學生賽事評審專家，發表多篇SCI核心期刊學術論文，阿里雲認證的資深架構師，上億營收AI產品研發負責人。
一個堅實的軟體架構基礎，是開發創新且複雜的軟體的關鍵，這些軟體不僅要符合市場需求，還要為使用者解決實際問題。你是否曾參與過一些專案，這些專案在最初的幾輪開發後似乎就無法繼續迭代了？這正是軟體架構發揮作用的地方，它的重要性顯而易見。
在軟體行業中，當人們談論“軟體”時，他們通常指的是軟體系統內部設計中最關鍵的部分。然而，這一基礎的構建取決於多個因素，如軟體架構師與設計師之間的相互理解、正確的設計決策以及易於理解的程式碼。
什麼是軟體架構？
從使用智慧手機到傳送電子郵件，我們日常生活中的許多方面都嚴重依賴於我們使用的系統的軟體架構。沒有它，我們所使用和了解的許多事物將根本無法實現。軟體架構帶來了組織的創新。
定義
軟體架構（Software Architecture）的定義長期以來一直存在爭議。對某些人來說，它是基本元件的連線方式，或系統的基礎組織結構。在這方面，伊利諾伊大學副教授 Ralph Johnson 提出的抽象概念值得注意：
** “架構是關於重要的事情，無論那是什麼。”
乍一聽，這可能顯得平淡無奇，但它實際上蘊含了豐富的內涵。軟體架構是指軟體系統的最高階別框架，即系統骨架。它是系統基礎的最初選擇之一，這一選擇會顯著影響工作流程、程式碼質量、維護、部署和開發的難易度。
軟體架構主要基於一系列與軟體開發相關的關鍵決策。這些決策對最終產品的整體成功和效能有重大影響。這些決策包括：
- 選擇結構元件及其介面
- 元件之間的協作行為
- 將這些結構和行為元件配置為一個實質性的子系統
- 基於業務需求做出架構決策
軟體架構與軟體系統設計是否相同？
儘管大多數人認為軟體架構和軟體設計不同，但從根本上講，它們是一樣的。這一區別源於軟體系統設計被認為是低階別的細節，而軟體架構是高階別的細節。
沒有高階別細節的知識，開發人員可能仍能處理低階別細節，但反之則不行。系統架構師需要完全瞭解他們的高階決策如何影響低階別的細節。
此外，軟體設計是軟體開發週期（SDLC）的初始階段之一，它為開發人員提供了詳細的資料以實現相容的軟體。
另一方面，軟體架構是一個計劃，約束了軟體系統設計以避免常見的錯誤。它為組織實現技術和業務戰略。
簡而言之，如何構建是軟體設計，而構建什麼則是軟體架構。
為什麼軟體架構如此重要？
軟體架構是為特定的目標而設計的——它的全部意義在於識別那些直接關係到系統成敗的元件，並構建一個服務和保護這些重要元件的系統。一個有組織的系統架構設計有助於保持內部質量，從而進一步改善軟體。
以 ** Netflix ** 為例，它的 ** 微服務架構 ** 使他們能夠管理可用性，而在** Salesforce ** 或** Google ** 中，則是** 領域驅動設計 ** 幫助他們處理 領域邏輯的複雜性。
讓我們透過以下例子來理解這一點。
假設有兩個類似的產品在一個月的時間差內釋出。三個月後，它們都需要新增功能。
現在有兩種情境。
- 釋出——5月31日：程式碼混亂且糾結。使用者對此沒有意見，但追蹤變更範圍並加以整合變得非常困難。
- 釋出——6月30日：程式碼完美有序。使用者對此也沒有意見，但軟體開發團隊可以輕鬆處理並實施變更。
在這種情況下，軟體開發公司會怎麼選擇？
通常，即便程式碼混亂，團隊也會選擇提前釋出，因為在當時最重要的是儘快上線——越早釋出，越有機會佔領市場。
然而，在第二種情境中，由於質量效能和程式碼質量被同等重視，變更需要更多時間，這將不利於市場投放時間。
但一個設計良好的微服務架構將有助於更輕鬆地進行維護。這樣不僅能節省時間，還能透過快速且定期的更新滿足使用者需求。
** 混亂的程式碼可能使產品更早進入市場，但在包含新變更時會要求付出更多代價。相反，有序的程式碼可能導致釋出延期，但最終會提供準確且及時的更新。
軟體架構模式
在設計一個線上購物應用的軟體開發專案時，最重要的是定義其程式設計架構和設計。這些是構建應用的基礎。例如，產品推薦的演算法將如何工作？購物車將如何運作？這一系列問題不斷延伸。
軟體架構模式可以被定義為解決主流和重複出現的軟體工程問題的方案。接下來，我們將介紹五種常見的軟體架構模式：
1. 分層架構模式
這種模式因其易於開發和維護的特點而被廣泛使用。它採用分層的方法，將程式碼按層次組織。典型的資訊系統中，最常見的四個層次為：
- 表現層或 UI 層
- 應用層或服務層
- 業務邏輯層或領域層
- 資料訪問層或持久層
最佳使用場景
- 需要超過 CRUD 操作的常規業務應用
- 需要快速開發的標準應用
- 對測試和維護有嚴格標準的應用
2. 微核心架構模式
這種模式適用於需要適應不斷變化的系統需求的應用。它分為擴充套件功能（外掛Plugins）和最小功能核心。核心系統包括標準的業務邏輯，而外掛則是獨立的元件，透過自定義程式碼為核心系統提供特定的處理功能。
外掛由獨立的元件組成，透過自定義程式碼提供特定的處理功能來支援核心系統。微核心就像一個插座，用於連線這些外掛，從而增強其潛力和功能。
最佳使用場景
- 任務和作業排程應用
- 工作流應用
- 整合來自多個源資料並將其傳輸到不同目的地的應用
3. 微服務架構模式
這種模式透過構建多個小型且獨立的應用來構成一個完整的系統。每個應用（或微服務）各自負責不同的任務，彼此之間只需進行通訊。
作為單體架構模式的可行替代方案，微服務架構已獲得廣泛關注和重要性。它由多個鬆散耦合的服務組成，在使用微服務時，需要確保它們之間的訊息交換保持向後相容。
最佳使用場景
- 快速發展的 Web 和業務應用
- 具有明確邊界的企業資料中心
- 由分佈在全球各地的開發團隊維護的網站
4. 基於事件的架構模式
這種模式用於開發高度可擴充套件的系統，其非同步架構方式以處理定義的“事件”，如捲軸的移動、按鈕點選等。基於事件的模式包含單一用途的事件處理元素，這些元素構建了一箇中央單元。中央單元接收所有資料，並將其分配給處理特定型別的獨立模組。
最佳使用場景
- 使用者介面
- 具有非同步資料流的應用
- 需要無縫資料流且最終會擴充套件的複雜應用
5. 基於空間的架構模式
這種模式特別用於解決併發性和可擴充套件性問題，消除了中央資料庫的約束，並使用複製的記憶體資料網格。
這種模式透過將儲存和處理分佈在多個伺服器之間來減少高負載下功能崩潰的風險。
最佳使用場景
- 社交網路
- 高流量資料如使用者日誌和點選流
- 低價值資料
如何評估一個好的軟體架構？
一個高效的軟體架構應具有以下質量屬性：
- 功能性 Functionality：軟體可以提供滿足使用者需求的功能。
- 可用性 Usability：軟體使用的便利性。
- 可靠性 Reliability：在特定情況下提供所需功能的能力。
- 可遷移性/支援性 Supportability：開發者將軟體遷移到不同平臺的難易度。
- 效能 Performance：考慮資源利用、處理速度、響應時間、生產力和吞吐量的近似值。
- 獨立性 Self-Reliance：即使某些部分出現問題，仍能保持最佳效能的能力。
總結
綜上所述，軟體架構是高效軟體的根基，它有助於在整個生命週期內保持產品的質量和易於管理。最終，它在長期內證明是有利且必要的，因為它更易於修改，節省了開發人員的時間和精力。
本文由部落格一文多發平臺 OpenWrite 釋出！