答え。

マイクロサービス間のインタラクションを設計する際には、分散トランザクションの実装がしばしば問題となります。モノリスでは組み込みメカニズムで管理できますが、マイクロサービスでは異なるデータベース、技術、データ交換形式のため状況が複雑になります。重要なルールは、長い分散トランザクションを避けることです。これはスケーラビリティが悪く、パフォーマンスの低下リスクを伴います。

従来のACIDプロトコルの代わりに、SAGAパターンを使用することが推奨されます。これは、各マイクロサービスが自分の変更を記録し、ロールバックが必要な場合に、責任範囲内で補償操作を送信するローカルトランザクションのチェーンです。

Node.jsとRESTでのサガ管理の簡略化された実装例:

// ExpressのSagaオーケストレーター
app.post('/saga', async (req, res) => {
  try {
    await serviceA.transaction();
    await serviceB.transaction();
    res.send('ok');
  } catch (err) {
    await serviceA.rollback();
    res.status(500).send('rollback performed');
  }
});

主な特徴:

SAGAはサービス間の長期ロックを最小限に抑えます
拡張性 — 新しいステップや補償アクションを追加可能
「各サービスはそれぞれのストレージ」というアーキテクチャに適しています

隠れた質問。

マイクロサービス間でトランザクションをサポートするために従来の二相コミット（2PC）を使用できますか？

可能ですが、マイクロサービスアーキテクチャには推奨されません。2PCはスケーリングを妨げ、サービス間の技術的および組織的な結びつきを強めます。

すべてのSAGAシナリオは財務取引に適していますか？

いいえ。ACIDの厳密さが重要なシナリオ、たとえば1つの口座の残高の再計算の場合、SAGAは正しく実装するのが難しくなります。ここではリスクを評価し、妥協点を選ぶことが重要です。

マイクロサービスがロールバックできない場合、中間ステップの失敗をどのように処理しますか？

このような場合、手動または自動の補償プロトコルを実装する必要があります。おそらく、別のイベントログを使用して行うことになります。

マイクロサービス間のトランザクションのサポートを考慮したインターフェース層をどのように正しく構成するか？

答え。

隠れた質問。