微服務的分散式事務模式比較 | RedHat

banq發表於2021-09-28
微服務分散式模式Redhat

作為 Red Hat 的一名諮詢架構師，我有幸參與了大量客戶專案。每個客戶都會帶來自己的挑戰，但我發現了一些共同點。大多數客戶想知道的一件事是如何協調對多個記錄系統的寫入。回答這個問題通常涉及對雙重寫入、分散式事務、現代替代方案以及每種方法可能的故障場景和缺點的詳細解釋。通常，此時客戶會意識到將單體應用程式拆分為微服務是一個漫長而複雜的過程，通常需要權衡取捨。（banq注：如果稍微懂一些業務DDD分析，這種純技術的分散式事務其實是一個偽概念，但是為了展示純技術人員如何在分散式事務上弄巧成拙，特大意翻譯這篇文章要義，詳細點選標題）
本文沒有深入討論事務，而是總結了協調寫入多個資源的主要方法和模式。我知道您過去可能對這些方法中的一種或多種有好的或壞的經驗。但實際上，在正確的上下文和正確的約束下，所有這些方法都可以正常工作。技術主管負責為他們的上下文選擇最佳方法。
正如您可能已經從本文中猜到的那樣，在微服務架構中處理分散式事務沒有正確或錯誤的模式。每種模式都有其優點和缺點。每個模式都解決了一些問題，同時又依次產生了其他問題。圖 12 中的圖表簡要總結了我討論過的雙寫入模式的主要特徵。

微服務的分散式事務模式比較 | RedHat
無論您選擇哪種方法，您都需要解釋和記錄決策背後的動機以及您選擇的持久架構後果。您還需要獲得將長期實施和維護系統的團隊的支援。我喜歡根據資料一致性和可擴充套件性屬性來組織和評估本文中描述的方法，如圖 13 所示。

微服務的分散式事務模式比較 | RedHat

作為一個很好的起點，我們可以評估各種方法，從最具可擴充套件性和高度可用的方法到最不具有可擴充套件性和可用性的方法。

  • 高：並行管道和編排

如果您的步驟暫時分離，那麼在並行管道方法中執行它們可能是有意義的。您可能可以將這種模式應用於系統的某些部分，但不能應用於所有部分。接下來，假設處理步驟之間存在時間耦合，並且某些操作和服務必須先於其他操作和服務發生，您可能會考慮編排方法。使用服務編排，可以建立一個可擴充套件的、事件驅動的架構，其中訊息透過分散的編排過程從一個服務流向另一個服務。在這種情況下，使用 Debezium 和 Apache Kafka 實現的發件箱模式（例如Red Hat OpenShift Streams for Apache Kafka）特別有趣並受到關注。
  • 中：編排和兩階段提交

如果編舞不合適，並且您需要一個負責協調和決策的中心點，那麼您可以考慮編排。這是一種流行的架構，提供基於標準和自定義的開源實現。雖然基於標準的實現可能會強制您使用某些事務語義，但自定義編排實現允許您在所需的資料一致性和可伸縮性之間進行權衡。
  • 低：模組化單體

如果您在頻譜中更進一步，很可能您對資料一致性有非常強烈的需求，並且您已經準備好以重大的權衡來支付它。在這種情況下，透過兩階段提交的分散式事務將適用於某些資料來源，但它們很難在為可擴充套件性和高可用性而設計的動態雲環境中可靠地實現。在這種情況下，您可以一直採用舊的模組化單體式方法，並伴隨著從微服務運動中學到的實踐。這種方法確保了最高的資料一致性，但以執行時和資料來源耦合為代價。
 

結論
在具有數十個服務的大型分散式系統中，不會有一種方法適用於所有服務，而是將其中一些方法組合起來並應用於不同的上下文。您可能在共享執行時部署了一些服務，以滿足有關資料一致性的特殊要求。您可以選擇兩階段提交以與支援 JTA 的遺留系統整合。您可能會編排複雜的業務流程，並對其餘服務使用編排和並行處理。最後，你選擇什麼策略並不重要；重要的是出於正確的原因故意選擇策略並執行它。

相關文章