本文包含軟件架構的重要性、定義及其常見模式，架構對系統成功的影響，五種主要的架構模式及其最佳應用場景，評估優秀架構的關鍵質量屬性。

關注 TechLead，復旦博士，分享雲服務領域全維度開發技術。擁有 10 + 年互聯網服務架構、AI 產品研發經驗、團隊管理經驗，復旦機器人智能實驗室成員，國家級大學生賽事評審專家，發表多篇 SCI 核心期刊學術論文，阿里雲認證的資深架構師，上億營收 AI 產品研發負責人。

一個堅實的軟件架構基礎，是開發創新且複雜的軟件的關鍵，這些軟件不僅要符合市場需求，還要爲用戶解決實際問題。你是否曾參與過一些項目，這些項目在最初的幾輪開發後似乎就無法繼續迭代了？這正是軟件架構發揮作用的地方，它的重要性顯而易見。

在軟件行業中，當人們談論 “軟件” 時，他們通常指的是軟件系統內部設計中最關鍵的部分。然而，這一基礎的構建取決於多個因素，如軟件架構師與設計師之間的相互理解、正確的設計決策以及易於理解的代碼。

什麼是軟件架構？

從使用智能手機到發送電子郵件，我們日常生活中的許多方面都嚴重依賴於我們使用的系統的軟件架構。沒有它，我們所使用和了解的許多事物將根本無法實現。軟件架構帶來了組織的創新。

定義

**軟件架構（Software Architecture）**的定義長期以來一直存在爭議。對某些人來說，它是基本組件的連接方式，或系統的基礎組織結構。在這方面，伊利諾伊大學副教授 Ralph Johnson 提出的抽象概念值得注意：

“架構是關於重要的事情，無論那是什麼。”

乍一聽，這可能顯得平淡無奇，但它實際上蘊含了豐富的內涵。軟件架構是指軟件系統的最高級別框架，即系統骨架。它是系統基礎的最初選擇之一，這一選擇會顯著影響工作流程、代碼質量、維護、部署和開發的難易度。

軟件架構主要基於一系列與軟件開發相關的關鍵決策。這些決策對最終產品的整體成功和性能有重大影響。這些決策包括：

• 選擇結構組件及其接口

• 組件之間的協作行爲

• 將這些結構和行爲組件配置爲一個實質性的子系統

• 基於業務需求做出架構決策

軟件架構與軟件系統設計是否相同？

儘管大多數人認爲軟件架構和軟件設計不同，但從根本上講，它們是一樣的。這一區別源於軟件系統設計被認爲是低級別的細節，而軟件架構是高級別的細節。

沒有高級別細節的知識，開發人員可能仍能處理低級別細節，但反之則不行。系統架構師需要完全瞭解他們的高級決策如何影響低級別的細節。

此外，軟件設計是軟件開發週期（SDLC）的初始階段之一，它爲開發人員提供了詳細的數據以實現兼容的軟件。

另一方面，軟件架構是一個計劃，約束了軟件系統設計以避免常見的錯誤。它爲組織實現技術和業務戰略。

簡而言之，如何構建是軟件設計，而構建什麼則是軟件架構。

爲什麼軟件架構如此重要？

軟件架構是爲特定的目標而設計的——它的全部意義在於識別那些直接關係到系統成敗的組件，並構建一個服務和保護這些重要組件的系統。一個有組織的系統架構設計有助於保持內部質量，從而進一步改善軟件。

以 Netflix 爲例，它的 微服務架構 使他們能夠管理可用性，而在 Salesforce 或 Google 中，則是 領域驅動設計 幫助他們處理 領域邏輯的複雜性。

讓我們通過以下例子來理解這一點。

假設有兩個類似的產品在一個月的時間差內發佈。三個月後，它們都需要新增功能。

現在有兩種情境。

1. 發佈——5 月 31 日：代碼混亂且糾結。用戶對此沒有意見，但追蹤變更範圍並加以整合變得非常困難。

2. 發佈——6 月 30 日：代碼完美有序。用戶對此也沒有意見，但軟件開發團隊可以輕鬆處理並實施變更。

在這種情況下，軟件開發公司會怎麼選擇？

通常，即便代碼混亂，團隊也會選擇提前發佈，因爲在當時最重要的是儘快上線——越早發佈，越有機會佔領市場。

然而，在第二種情境中，由於質量性能和代碼質量被同等重視，變更需要更多時間，這將不利於市場投放時間。

但一個設計良好的微服務架構將有助於更輕鬆地進行維護。這樣不僅能節省時間，還能通過快速且定期的更新滿足用戶需求。

混亂的代碼可能使產品更早進入市場，但在包含新變更時會要求付出更多代價。相反，有序的代碼可能導致發佈延期，但最終會提供準確且及時的更新。

軟件架構模式

在設計一個在線購物應用的軟件開發項目時，最重要的是定義其編程架構和設計。這些是構建應用的基礎。例如，產品推薦的算法將如何工作？購物車將如何運作？這一系列問題不斷延伸。

軟件架構模式可以被定義爲解決主流和重複出現的軟件工程問題的方案。接下來，我們將介紹五種常見的軟件架構模式：

1. 分層架構模式

這種模式因其易於開發和維護的特點而被廣泛使用。它採用分層的方法，將代碼按層次組織。典型的信息系統中，最常見的四個層次爲：

• 表現層或 UI 層

• 應用層或服務層

• 業務邏輯層或領域層

• 數據訪問層或持久層

最佳使用場景

• 需要超過 CRUD 操作的常規業務應用

• 需要快速開發的標準應用

• 對測試和維護有嚴格標準的應用

2. 微內核架構模式

這種模式適用於需要適應不斷變化的系統需求的應用。它分爲擴展功能（插件 Plugins）和最小功能核心。核心系統包括標準的業務邏輯，而插件則是獨立的組件，通過自定義代碼爲核心系統提供特定的處理功能。

插件由獨立的組件組成，通過自定義代碼提供特定的處理功能來支持核心系統。微內核就像一個插座，用於連接這些插件，從而增強其潛力和功能。

最佳使用場景

• 任務和作業調度應用

• 工作流應用

• 集成來自多個源數據並將其傳輸到不同目的地的應用

3. 微服務架構模式

這種模式通過構建多個小型且獨立的應用來構成一個完整的系統。每個應用（或微服務）各自負責不同的任務，彼此之間只需進行通信。

作爲單體架構模式的可行替代方案，微服務架構已獲得廣泛關注和重要性。它由多個鬆散耦合的服務組成，在使用微服務時，需要確保它們之間的消息交換保持向後兼容。

最佳使用場景

• 快速發展的 Web 和業務應用

• 具有明確邊界的企業數據中心

• 由分佈在全球各地的開發團隊維護的網站

4. 基於事件的架構模式

這種模式用於開發高度可擴展的系統，其異步架構方式以處理定義的 “事件”，如滾動條的移動、按鈕點擊等。基於事件的模式包含單一用途的事件處理元素，這些元素構建了一箇中央單元。中央單元接收所有數據，並將其分配給處理特定類型的獨立模塊。

最佳使用場景

• 用戶界面

• 具有異步數據流的應用

• 需要無縫數據流且最終會擴展的複雜應用

5. 基於空間的架構模式

這種模式特別用於解決併發性和可擴展性問題，消除了中央數據庫的約束，並使用複製的內存數據網格。

這種模式通過將存儲和處理分佈在多個服務器之間來減少高負載下功能崩潰的風險。

最佳使用場景

• 社交網絡

• 高流量數據如用戶日誌和點擊流

• 低價值數據

如何評估一個好的軟件架構？

一個高效的軟件架構應具有以下質量屬性：

1. 功能性 Functionality：軟件可以提供滿足用戶需求的功能。

2. 可用性 Usability：軟件使用的便利性。

3. 可靠性 Reliability：在特定情況下提供所需功能的能力。

4. 可遷移性 / 支持性 Supportability：開發者將軟件遷移到不同平臺的難易度。

5. 性能 Performance：考慮資源利用、處理速度、響應時間、生產力和吞吐量的近似值。

6. 獨立性 Self-Reliance：即使某些部分出現問題，仍能保持最佳性能的能力。

總結

綜上所述，軟件架構是高效軟件的根基，它有助於在整個生命週期內保持產品的質量和易於管理。最終，它在長期內證明是有利且必要的，因爲它更易於修改，節省了開發人員的時間和精力。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/wOueFSRJ72sd1Kizoa_SlQ