AWS 的應用架構樣式

在 AWS 上部署應用程式

Dunieski Otano

Amazon Web Services Solutions Architect

認識你的講師

課程講師 Dunieski Otano，AWS Solutions Architect，約 10 年雲端經驗

在 AWS 上部署應用程式

為何正確架構很重要

淺色主題決策圖：一個架構選擇節點分支為三個要素：耦合、狀態與通訊，上方有代表取捨的天秤圖示

  • 架構是取捨的組合，沒有唯一答案
    • 三個問題決定每次選擇：
      • 元件之間有多緊密耦合？
      • 狀態放在哪裡？
      • 通訊是同步或非同步？
    • 依工作負載選樣式，不追流行
在 AWS 上部署應用程式

週五晚上的連鎖效應

  • 緩慢的付款 API 讓整個結帳卡住
  • 所有服務都同步等待它
  • 解法在於架構，不是更快的 API

並排比較：緊密耦合導致整體停滯 vs 以訊息佇列解耦後持續運作

在 AWS 上部署應用程式

架構選擇為何決定部署結果

比較：脆弱的緊密耦合架構中單一失敗服務引發連鎖故障，對比以佇列緩衝、故障被隔離、其他服務持續提供服務的設計

  • 你選的樣式決定應用如何擴展與失敗
    • 緊密耦合設計在高負載下會崩潰
  • 正確樣式讓部署可預期
    • 同一份程式碼，線上行為可能大不同
在 AWS 上部署應用程式

核心架構樣式

  • 單體（Monolithic）：一個可部署單元，起步簡單
  • 微服務（Microservices）：獨立服務，各自部署
  • 事件導向（Event-driven）：以事件觸發，不是直接呼叫
    • 扇出（Fanout）：一事件傳遞到多個消費者

 

三種應用架構樣式並列：單體為單一堆疊方塊，微服務為獨立可部署服務，事件導向含事件匯流排，面板內標示扇出為一事件發布至多個消費者

在 AWS 上部署應用程式

有狀態 vs 無狀態

  • 無狀態（Stateless）：請求間不保留用戶端資料
    • 任何實例都可處理任何請求
  • 有狀態（Stateful）：實例會記住先前互動
  • 無狀態讓你可水平擴展
    • 將共享狀態放到 DynamoDB 或 ElastiCache

左：無狀態函式實例，任何請求都能抵達；右：綁定單一用戶端工作階段的有狀態實例

在 AWS 上部署應用程式

緊密 vs 鬆散耦合

左：緊密耦合，呼叫端被慢速被叫端阻塞；右：以 SQS 佇列鬆散耦合，訊息緩衝，生產者持續運作

  • 緊密耦合：呼叫端等待被叫端回應
  • 一個慢服務會拖住整條鏈
  • 鬆散耦合：服務之間放入 Amazon SQS 佇列
  • 即使消費者當機，生產者仍可繼續工作
在 AWS 上部署應用程式

同步 vs 非同步

  • 同步（Synchronous）：呼叫端被阻塞並等待結果
  • 當呼叫端需要即時答案時使用
  • 非同步（Asynchronous）：交付工作後立即返回
  • 適合較慢、突發或非緊急的工作

 

左：同步呼叫，呼叫端阻塞至回應到達；右：非同步交付後立即返回，背景處理

在 AWS 上部署應用程式

第三方呼叫的韌性樣式

  • 指數退避重試：每次嘗試間隔越等越久
  • 斷路器：暫停呼叫失敗的服務一段時間
  • 死信佇列：存放屢次失敗的訊息
  • 合併運用；一味重試會讓故障更嚴重

三種韌性樣式：指數退避重試曲線、斷路器暫停呼叫失敗服務、死信佇列收納用盡重試的訊息

在 AWS 上部署應用程式

一起來練習吧！

在 AWS 上部署應用程式

Preparing Video For Download...