架構風格與通訊模式

在 AWS 上開發應用程式

Ricardo Sueiras

Principal Technologist

你的講師

什麼是架構模式？

 

 

 

• 可重複套用的常見問題解法。
• 模式協助你拼接 AWS 服務。
• 架構決定系統在負載下的表現。
• 幾種必懂的架構模式。

單體（Monolith）

 

 

 

 

• 單一、緊密耦合的單元。
• 一個程式碼庫，一次部署。
• 初期開發簡單。
• 擴充痛苦：必須整體一起擴充。

微服務（Microservices）

 

 

• 小而獨立的服務：各自負責一項業務能力。
• 各服務可獨立部署、擴充與更新。
• 取捨：營運更複雜，需管理服務間通訊。

無伺服器（Serverless）

• 無需管理基礎架構，只管程式碼與設定。
• 以組合託管的 AWS 服務來建置。
• AWS 負責佈建、擴充與維護。
• 取捨：執行時間限制、冷啟動、供應商綁定。
• 幾乎零營運負擔且自動擴充。

 

事件驅動架構（EDA）

• 元件以產生與消費事件溝通，而非直接呼叫。
• 事件記錄發生的事（下單、收款、出貨）。
• 生產者發出事件。
• 消費者訂閱所關注的事件。

 

緊耦合與鬆耦合系統

• 現代雲端應用由多個服務組成。
• 服務須通訊與協調才能完成工作。
• 同步通訊是緊耦合。
• 非同步通訊是鬆耦合。

同步通訊

 

• 一個服務送出請求並等待回應。
• 呼叫端在回應或逾時前會被阻塞。
• 實作與理解皆直觀。
• 緊耦合：下游變慢或失敗會連鎖影響。
• 以逾時、重試、斷路器來緩解。

模式：請求/回應

• 多數應用介面的骨幹。
• 行為可預期。
• 使用者得到即時回饋。

非同步通訊

 

• 傳送端不等待回應。
• 傳送訊息或事件後繼續處理。
• 接收端獨立處理訊息。
• 鬆耦合：更佳的擴充性與容錯性。
• 能平順處理流量高峰與部分故障。
• 挑戰：重複訊息、排序、最終一致性。

模式：佇列式解耦

• 生產者將訊息送到佇列。
• 消費者自行拉取並處理訊息。
• 防止失敗連鎖擴散。
• 生產者與消費者可各自擴充。

 

模式：工作者佇列

• 多個工作者從同一佇列拉取訊息。
• 訊息可平行處理。
• 支援水平擴充與更高吞吐。
• 不保證訊息順序。

模式：發佈/訂閱

• 發佈者將訊息送到 SNS 主題。
• 多個訂閱者接收相同訊息。
• 即時廣播給多個消費者。

 

模式：扇出（Fan-out）

• 一則訊息同時傳遞給多個消費者。
• 在事件驅動架構中廣泛使用。
• 當多個服務需對同一事件做出反應時很實用。

訊息排序

• 有些工作負載必須依正確順序處理訊息。
• Amazon SQS FIFO 與 Kinesis 支援有序處理。
• 嚴格排序會降低吞吐量。
• 在正確性與可擴充性間取平衡。

一起來練習吧！

在 AWS 上開發應用程式