深入解析 18 種軟件架構設計模式 （5）
架構模式通過提供可複用的設計方案，有助於解決常見的軟件設計挑戰，從而提升生產力。如果您從事軟件架構設計工作，可能會遇到重複的目標和問題。架構模式通過提供應對這些場景的可重複設計，幫助開發者更高效地解決這些問題。
架構模式捕獲了各類系統和軟件要素的設計結構，使其可以被複用。在編寫代碼的過程中，開發者往往在項目內、公司內乃至職業生涯中多次遇到類似問題。通過創建設計模式，工程師們可以藉助一種可複用的方法來解決問題，結構化地實現項目目標。
本篇介紹：事件驅動架構，基於流的架構，無服務器架構模式。
請關注博主，後續持續更新。
- 事件驅動架構 Event Driven Architecture
事件驅動架構（Event-Driven Architecture，簡稱 EDA）是一種設計軟件系統的方法，旨在實現系統不同組件或服務之間的快速、高效通信。在這種架構中，各軟件組件通過 “事件” 進行通信，而非傳統的直接請求與響應模式。
事件驅動架構的核心概念
- 事件（Events）
事件是某種重要情況發生的通知或信號。例如，用戶點擊按鈕的操作、系統生成的通知（如數據更新或錯誤提示）都可以視爲事件。
- 事件源（Event Sources/Producers）
系統中的組件或服務會生成事件並將其發佈到事件代理或中央事件總線上。這些組件被稱爲事件源。
- 事件消費者（Event Consumers/Subscribers）
對特定事件類型感興趣的組件或服務會訂閱這些事件，並通過事件總線或代理接收事件。
- 事件代理或事件總線（Event Broker/Event Bus）
事件代理是管理事件路由與交付的中間件組件，它將事件從生產者傳遞給消費者。事件代理解耦了事件生產者與消費者，使得系統架構更加靈活和可擴展。
示例：電商應用中的事件驅動架構
以一個簡單的電商應用爲例，當用戶下單時，訂單處理服務會生成一個 “訂單已創建” 的事件，並將該事件廣播給其他服務，如庫存管理、物流配送和賬單處理服務。每個服務會接收事件並對其各自的系統進行更新。
真實案例：Uber 的事件驅動架構
Uber 工程團隊的案例是事件驅動架構的典範，以下是 Uber 使用 EDA 的部分實現細節：
- 事件源
Uber 系統生成的事件包括：乘車請求、司機可用性更新、GPS 位置更新、支付交易等。
- 事件消費者
Uber 的不同服務會訂閱這些事件。例如：
司機匹配服務訂閱乘車請求事件以尋找可用司機。
賬單服務訂閱支付事件以處理交易。
- 事件總線
Uber 使用 Apache Kafka 作爲事件總線，支持高擴展性和可靠性的事件流轉。
事件驅動架構的優勢
- 解耦性
事件驅動架構的一個重要優勢是將系統不同組件解耦。通過事件通信而非直接調用，組件間的依賴性降低。這使得系統的各個部分可以獨立更新或更改，而不會對其他部分產生影響。
- 可擴展性
由於事件可以同時廣播到系統的多個組件，事件驅動架構可以支持大規模數據處理與事務處理的並行化。這種特性使得系統能夠輕鬆應對高流量和需求峯值。
事件驅動架構的挑戰
儘管事件驅動架構優勢顯著，但也面臨一些挑戰：
- 複雜性管理
事件驅動系統可能由許多組件生成和消費事件，這種複雜性增加了問題追蹤與調試的難度。
- 事件順序保障
由於事件的生成與處理可能是異步的，因此無法確保事件的順序性。這可能導致數據不一致或計算錯誤等問題。
- 基於流的架構 Stream Based Architecture
隨着軟件開發複雜性的提升和對高可擴展性需求的增加，傳統架構逐漸難以滿足現代需求。基於流的架構（Stream-Based Architecture）作爲一種新興的設計方法，爲開發者提供了處理海量數據並實現實時響應的能力。
基於流的架構是一種設計思路，它通過系統中的數據流（Data Streams）實現數據的連續處理。這些數據流由一系列數據記錄（事件或消息）組成，並以實時或接近實時的方式生成、傳輸和消費。此架構特別適用於需要處理大量數據、實現實時處理以及支持低延遲響應的應用場景。
核心思想與特點
基於流的架構本質上是基於事件驅動編程（Event-Driven Programming）的一種延伸。與傳統的批處理方式不同，流式系統可以實時處理數據變化，從而實現最低延遲的響應。
核心概念
- 數據流（Data Streams）
數據流是由各種數據源生成並被應用或服務消費的連續數據記錄流。
- 流處理（Stream Processing）
數據流在系統中流動的過程中被實時或接近實時地處理，進行計算和轉換。
- 事件時間處理（Event Time Processing）
基於事件發生的時間來處理數據，這是維護正確順序和時間一致性的關鍵。
- 有狀態處理（Stateful Processing）
在數據流中維護狀態，支持複雜分析、模式檢測和聚合操作。
示例：Twitter 的實時分析平臺
Twitter 的實時分析平臺是基於流架構的經典案例。每天，Twitter 需要處理數百萬條推文，並實時分析這些數據以獲取洞察。
- 數據流
用戶生成的每條推文都成爲數據流中的事件。
- 流處理
Twitter 使用 Apache Storm 或 Apache Flink 等技術對數據流進行實時處理，完成情感分析、趨勢檢測和用戶參與度分析等任務。
- 擴展性
Twitter 的架構可以通過水平擴展來應對日益增長的推文量和用戶需求，確保實時分析的高效性和響應能力。
爲什麼選擇基於流的架構？
- 實時洞察
基於流的架構使得應用可以在數據到達時即刻處理並分析，從而提供實時的洞察與響應。
- 可擴展性
流架構支持系統通過增加處理節點來橫向擴展，能夠處理海量數據。
- 低延遲
通過實時數據處理，流架構支持對即時響應有高要求的應用。
- 持續處理
流架構支持數據的持續處理，非常適合實時分析、欺詐檢測和物聯網數據處理等場景。
靈活性與成本效益
靈活性
實時處理數據的能力使得基於流的架構能夠快速響應數據的變化。例如，在電商平臺中，流架構可以實時追蹤用戶行爲，根據用戶的瀏覽與購買記錄提供個性化推薦與促銷。
成本效益
傳統的批處理方式通常需要昂貴的硬件和複雜的軟件基礎設施來管理數據處理。而基於流的系統可以構建在廉價的通用硬件上，擴展與維護更加簡單。
高容錯性與可靠性
基於流的架構具有高度的容錯性。實時處理的數據使得系統能夠在發生故障時自動恢復，無需人工干預。這種特性支持系統在大規模運行時保持高可靠性，同時降低數據丟失或系統停機的風險。
- 無服務器架構模式 Serverless Architecture Pattern
無服務器架構（Serverless Architecture Pattern）是一種雲計算執行模式，由雲服務提供商動態管理服務器的分配和資源調度。在這種模式下，開發人員專注於編寫代碼和部署單個函數或服務，而無需關注底層基礎設施的管理。
無服務器架構的關鍵特性
- 事件驅動（Event-Driven）
無服務器組件（函數）由事件觸發，例如 HTTP 請求、數據庫變化、文件上傳或定時任務。
- 自動伸縮（Auto-Scaling）
根據實際需求自動伸縮，無需手動干預。系統可以從每天幾次請求擴展到每秒處理數千次請求。
- 按需計費（Pay-Per-Use）
按實際使用的資源計費，而非基於預分配的服務器實例。只有在函數執行時纔會產生費用。
真實案例：基於無服務器架構的圖像處理服務
假設你正在開發一個應用，允許用戶上傳圖片、應用濾鏡並保存編輯後的版本。以下是如何使用無服務器架構來實現這一功能：
- 上傳事件觸發
用戶上傳圖片時，會觸發一個事件。可以使用雲服務提供商的無服務器功能（如 AWS Lambda、Google Cloud Functions 或 Azure Functions）來處理這個事件。
- 函數執行
響應上傳事件，觸發一個無服務器函數執行。此函數可以完成以下任務：
將圖片調整爲多種尺寸（如縮略圖、預覽圖和全分辨率版本）。
根據用戶需求對圖片應用濾鏡或轉換。
- 與服務集成
每個函數可以與其他雲服務集成，例如：
存儲服務：將處理後的圖片存儲到雲存儲（如 AWS S3、Azure Blob Storage）。
數據庫服務：將圖片的元數據存儲到數據庫（如 DynamoDB、Firestore）。
- 可擴展性
隨着更多用戶上傳圖片或請求處理，無服務器架構會自動擴展，通過啓動更多函數實例來處理增加的負載，無需手動調整服務器資源。
- 成本效率
只需支付每次函數執行的實際計算時間。如果在某些時段活動較少，由於沒有閒置的服務器消耗資源，成本會降至最低。
無服務器架構的優勢
- 簡化開發
開發者無需管理服務器或基礎設施，只需專注於應用功能的開發。
- 高擴展性
無需額外配置即可適應流量的突然增加或減少。
- 彈性計費
按實際使用計費，降低資源浪費和總體成本。
- 快速部署
函數可獨立部署和更新，縮短開發與發佈週期。
- 故障隔離
各函數獨立運行，單個函數的錯誤不會影響整個系統。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/pA-HRChs6pziwbYru9JudQ