使用 AWS 訊息服務實現解耦

在 AWS 上開發應用程式

Ricardo Sueiras

Principal Technologist

Amazon SQS 基礎

 

• 可獨立於生產者處理突發流量。

• 受管的非同步訊息佇列。
• 生產者將訊息送入佇列。
• 消費者從佇列取回訊息。
• 訊息會保留，直到被消費者取走。
• 保留時間：預設 4 天，最長 14 天。
• 消費者輪詢佇列，依自身速率處理。

訊息可見度

• 訊息一旦被消費者讀取即變為不可見。
• 可見度逾時控制其隱藏時長。
• 若處理失敗且未刪除訊息：
  • 會再次變為可見。
  • 可被重新處理。
• 可見度逾時：預設 30 秒。
• 最長可見度逾時為 12 小時。

 

訊息大小

 

• 單則訊息大小上限為 256KB。
• 使用 SQS Extended Client 函式庫可支援更大訊息。
• 將大型負載儲存在 Amazon S3。
• 在訊息負載中傳送指向 S3 的指標。

短輪詢

• 輪詢策略影響成本與效率。
• 短輪詢為預設。
• 查詢部分 SQS 伺服器，立即回應。
• 即使有訊息也可能回傳空結果。
• 造成更多 API 呼叫與更高成本。

 

長輪詢

• 長輪詢會查詢所有 SQS 伺服器。
• 最長等待 20 秒以取得訊息。
• 消除不必要的空回應。
• 減少 API 呼叫並降低成本。

 

標準佇列

• SQS 提供兩種類型的佇列。
• 標準佇列：
  • 至少一次送達。
  • 盡力維持順序。
  • 幾乎無限的輸送量。

 

FIFO 佇列

 

• FIFO 佇列：
  • 僅處理一次。
  • 嚴格訊息順序。
  • 內建重複資料刪除。
• 預設 300 TPS。
  • 透過批次可升至 3,000，或啟用高輸送模式更高。
• 依情境選擇佇列類型：
  • 規模與輸送量選標準佇列。
  • 順序與去重選 FIFO。

處理毒性訊息

 

• 失敗訊息會存入死信佇列（DLQ）。
• 訊息超過 maxReceiveCount 後移至 DLQ。
• 避免對毒性訊息無限重試。
• DLQ 類型需與來源佇列相同。
• 可將訊息移回來源佇列重新處理。

佇列安全性

 

• 傳輸中預設以 HTTPS 加密。
• 靜態資料以 AWS KMS 進行伺服端加密。
• 可用 AWS Encryption SDK 在用戶端加密負載。
• 使用 IAM 權限政策管理 SQS 佇列存取。
• 以資源為基礎的政策提供細緻、佇列層級控管。

Amazon SNS 基礎

• 受管的發布-訂閱（pub/sub）服務。
• 採用推送模型。
• 發布者將訊息送至主題（topic）。
  • 訊息大小上限 256KB。
• 消費者訂閱主題。
• 訂閱者被動接收訊息。

 

擴展性

• 每個主題最多支援 1,250 萬個訂閱。
• 不保留訊息：
  • 若訂閱者不可用，訊息會遺失。
  • 為避免遺失，請用 DLQ 或具持久性的訂閱者（SQS 佇列）。
• 將單一事件分送給多個消費者（扇出）。

 

訊息篩選

• SNS 支援訊息篩選政策。
• 訂閱僅接收關注的訊息。
• 無篩選時，訂閱會接收所有訊息。
• 篩選政策套用在訂閱層級，而非主題。

 

篩選邏輯與評估

 

• 以 JSON 定義篩選條件。
• 與訊息屬性比對。
• 多個條件以 AND 評估。
• 同一條件內多個值以 OR 評估。
• 支援多種篩選操作：
  • 精確字串、數值、前綴、排除與範圍比對。

SNS 安全性

 

• 傳輸中預設以 HTTPS 加密。
• 靜態資料以 AWS KMS 進行伺服端加密。
  • 授權 SNS 使用該 KMS 金鑰。
• 以 IAM 政策實作存取控制。
  • 管理誰可發布到主題或從主題訂閱。

一起來練習吧！

在 AWS 上開發應用程式