サーガパターン

モノリシック アーキテクチャでは、電子商取引の注文の処理など、複雑なビジネス トランザクションの実行が簡単になります。すべてのデータは単一のリレーショナル データベースに存在するため、開発者は在庫、支払い、配送にわたる複数のデータベースへの書き込みを単一の ACID トランザクション内でラップできます。どこかの時点でエラーが発生した場合、SQL ROLLBACK によってシステムの一貫性が即座に復元されます。 ただし、最新のクラウドネイティブ システムは マイクロサービス アーキテクチャ を採用しており、各サービスがデータを所有し、明確な API 境界を公開しています。この分散パラダイムでは、単一のエンドツーエンドのビジネス操作が複数の独立したマイクロサービスとデータベース エンジンにまたがります。 2 フェーズ コミット (2PC) プロトコルはクラウド ネットワーク全体で遅く、ブロックされ、脆弱であるため、分散システムは 最終整合性を維持しながらワークフローを非同期に調整する必要があります。 これにより、ソフトウェア アーキテクトは、次のような基本的な設計上の決定を迫られます。 分散マイクロサービス ワークフローを管理するには、コレオグラフィーとオーケストレーションを使用する必要がありますか? この包括的なガイドでは、両方のアーキテクチャ パターンを分析し、現実世界の類似性を探り、アーキテクチャのトレードオフを分析し、Go と Java での実稼働コードの実装を詳しく説明し、インフラストラクチャに適切なパターンを選択するためのフレームワークを確立します。 現実世界の例え: フラッシュ モブ vs. 交響楽団 両方のパターンの直感的なメンタル モデルを構築するには、人間のパフォーマーのグループが自分たちの行動をどのように調整するかを検討してください。 振り付けのたとえ: フラッシュモブ ダンサー ネットワーク プロのストリート ダンサーのグループがフラッシュ モブ ルーチンを実行しているところを想像してください。ステージに立って個々のダンサーを指差して次の動きを指示するインストラクターはいません。代わりに、各ダンサーは中央の音楽トラックを聴き、隣のダンサーの動きにダイナミックに反応します。 ダンサー A がフリップを完了すると、ダンサー B はその視覚的な合図を認識し、回転を開始します。 ※ダンサーBが回転し終わるとダンサーCが前に出ます。 主な特徴: 分散型、事後対応型、自律型。すべての参加者は、中心的な指示がなくても、自分自身の責任を理解しています。 オーケストレーションのたとえ: 交響楽団 ここで、70 人編成のクラシック交響楽団を想像してください。ヴァイオリニスト、打楽器奏者、チェロ奏者は、ステージ上のお互いの手を見て合図することはありません。代わりに、全員が指揮者を直接見ます。