參考資料

使用 Message Broker
  • 基於 broker 的架構
  • 基於 brokerless 的 messaging 架構

BROKERLESS MESSAGING
  • ZeroMQ：http:// zeromq.org
  • 優點
    • 更輕量的網路流量和更低的延遲，因為沒有中間的 broker
    • 不會有 broker 成為瓶頸
    • 較少的營運複雜度，因為沒有 broker
  • 缺點
    • 服務需要知道彼此的位置
    • 可用性降低，因為發送者和接收者都必須可用（跟使用同步 request/response 一樣）
    • 很難實作保證送達

基於 BROKER 的 MESSAGING 概觀
  • 範例
  • 優點
    • 發送者不需要知道消費者的位置
    • Broker 會緩衝訊息直到消費者可用
  • 選擇 MQ 的考量
    • 支援的程式語言
    • 支援的 messaging 標準，如 AMQP 或 STOMP
    • 訊息排序（低延遲的 broker 可能不支援排序）
    • 送達保證（高延遲）
    • 持久化（高延遲）
    • 耐久性：斷線時 broker 的行為是什麼？
    • 可擴展性
    • 延遲
    • 競爭消費者：broker 是否支援？

使用 MESSAGE BROKER 實作 MESSAGE CHANNEL

基於 BROKER 的 MESSAGING 的優缺點
  • 優點
    • 鬆耦合
    • 訊息緩衝
    • 靈活的溝通方式
    • 明確的行程間通訊
  • 缺點
    • 潛在的效能瓶頸
    • 潛在的單點故障
    • 額外的營運複雜度

競爭接收者與訊息排序
  • 如何在維持訊息排序的同時擴展訊息接收者 => 在 Kafka 中使用 sharded（partitioned）channel


處理重複訊息
  • 撰寫冪等的 message handler
    • 重複的訊息是無害的
  • 追蹤訊息並丟棄重複的。
交易式 Messaging
  • 分散式交易對現代應用程式來說不是好的選擇

使用資料庫表格作為 MESSAGE QUEUE

使用 POLLING PUBLISHER PATTERN 發佈事件
透過輪詢資料庫中的 outbox 來發佈訊息。參見 http://microservices.io/patterns/data/polling-publisher.html。

套用 TRANSACTION LOG TAILING PATTERN 發佈事件
Pattern: Transaction log tailing 透過追蹤 transaction log 來發佈對資料庫所做的變更。參見 http://microservices.io/patterns/data/transaction-log-tailing.html。





You May Also Enjoy