マイクロサービスのサガ パターン

マイクロサービスの問題を解決するには?サーガモードを試してみる

こんな状況に遭遇したことはありませんか。注文処理プロセスでは、支払い、在庫、物流などの複数のサービスを呼び出す必要があります。リンクの 1 つがスタックし、プロセス全体が混乱に陥りました。お金が差し引かれましたが在庫が更新されなかったり、商品は発送されましたが支払いが成功しなかったりするため、手動による検証とロールバックを待つ混乱が生じます。頭が痛くなりますか？

マイクロサービス アーキテクチャでは、この種の問題は非常に一般的です。各サービスは独自の土地を管理し、データは共有されません。一連の操作が成功するか失敗するかを確認するにはどうすればよいでしょうか?従来のパッケージトランザクション（ACIDトランザクション）は、単一のアプリケーションでは使いやすいですが、サービスがバラバラに分散している分散環境では少し不十分です。このとき、考え方を変える必要があります。

サーガモードとは何ですか？ 「コーディネーター」のようなものです。

簡単に言えば、Saga モデルは、大規模なビジネス トランザクションを一連の小規模で独立したローカル トランザクションに分割することです。各サービスは独自のステップを完了するだけで、次のサービス アクションをトリガーします。途中の特定のステップが失敗すると、Saga は映画のショットが壊れたかのように一連の「補償操作」を開始し、インシデントが発生する前のシステム状態に戻すことができるように、以前に撮影された関連部分を順番に再調整または削除する必要があります。

すべてのリソースをロックするための大きなロックに依存するのではなく、イベントとメッセージによって駆動され、サービス間の「チャット コラボレーション」が可能になります。たとえば、注文が正常に作成されると、「1 品目を差し引いてください」というメッセージが在庫サービスに送信されます。在庫が正常に差し引かれると、物流部門に「出荷の準備ができました」と通知されます。出荷が失敗した場合、在庫サービスは「差し引かれた商品を再度追加してください」と認識する必要があり、注文サービスもステータスを「処理待ち」に変更する必要がある場合があります。

誰かが「これはただのプランBではないですか？」と尋ねました。はい、完全に正しいわけではありません。補償は単なるロールバックではなく、ビジネス ロジックの逆オーケストレーションです。重要なのは、設計時に、すべてのステップが失敗した場合に「正常に終了する」方法を明確に考える必要があるということです。

なぜこれを気にする必要があるのでしょうか?罠にかかる回数を減らして、より多くの睡眠をとりましょう

夜中の 3 時に目覚ましのテキスト メッセージで目が覚めることを想像してみてください。注文ステータスが滞っているため、上流と下流のすべてのデータが不整合になります...そのような日を誰が想像したことがありますか? Saga のようなモデルを採用する主な利点は、最終的な整合性とシステムの復元力が向上することです。サービスは疎結合です。 1 つのサービスが一時的にハングアップしても、他のサービスが独自の作業を行うことには影響しません。回復すると、補償メカニズムがデータに追いつくのに役立ちます。

さらに、複雑なプロセスを可視化し、管理しやすくします。漠然とした「分散トランザクションのブラックボックス」に直面する必要はなくなり、問題がどこにあるのか、どこから補い始めればよいのかを明確な一連のステップで確認できるようになります。これにより、トラブルシューティングと証跡の監査がはるかに簡単になります。

もちろん、それも特効薬ではありません。それぞれの前進操作と対応する補償アクションを慎重に定義する必要があるため、設計はより頭を使います。補償自体が失敗する可能性もあり、より高度なエラー処理および監視戦略が必要になります。ただし、エラー発生後に手動で火を消すのと比較して、事前に自動修復プロセスを設計しておくと、長期的には多くのトラブルを節約できます。

使い方は？いくつかの実用的なアイデア

1. ビジネスフローを整理する: 急いでコードを書かないでください。まず紙を用意し、「ユーザーが注文する -> 在庫を差し引く -> 支払いを差し引く -> 送り状を作成する」など、サービス間のビジネス プロセスを描きます。各ステップのインプットとアウトプットを明確にします。
2. 「補償アクション」を定義する: 各ステップについて、「後でこのステップが失敗した場合、どうやって元に戻すか、その影響を相殺できるか?」と自問してください。在庫を差し引くことの代償として、在庫を追加し直すことになります。控除の代償として払い戻しが行われる場合があります。補償操作もビジネス上実行可能であることを確認してください。
3. 調整方法を選択してください：通常は2種類あります。 1つは振り付けされた、バンドの指揮者のように、誰が何をすべきかを指示する集中コーディネーターを作成します。 2番目は協力的な、駅伝のように、各サービスがその作業を完了したら次のサービスに通知します。前者は強力な制御を備えていますが、後者はより分散化され、柔軟性が高くなります。チームの構造と複雑さの好みに基づいて選択してください。
4. 実装とテスト: 使い慣れたメッセージ キューまたはイベント ストリーミング プラットフォームを使用して、状態の変化を伝えます。最優先事項はテスト、特に障害シナリオです。サービスの途中でクラッシュをシミュレートして、補償チェーンが正しくトリガーできるかどうか、データが最終的に一貫しているかどうかを確認します。
5. 監視と警告: サーガの各ステージと補正操作に明確なログとインジケーターを追加します。補償が頻繁にトリガーされると、特定のサービスが不安定であることの初期の兆候である可能性があります。

確かな技術がビジネスの静かな支えとなりますように

結局のところ、技術モデルはビジネスに役立ちます。 Saga モデルは、システムにまたがる脆弱なビジネス プロセスを強化し、予測可能にするのに役立ちます。騒々しいわけではありませんが、ユーザーの注文がバックグラウンドで不可解に消えないこと、在庫数値が常に正確であること、財務フローが明確で追跡可能であることを静かに保証します。この根底にある信頼性により、最終的には製品エクスペリエンスがよりスムーズになり、チームの運用と保守に対するプレッシャーが軽減されます。

存在するキロパワー、私たちはこの安定性の追求を理解しています。慎重に設計された機械システムと同様に、各サーボ モーターの回転と各ステアリング ギアの応答は、より大きなシーケンスで正確に調整される必要があります。優れた技術アーキテクチャにも同じことが当てはまります。これにより、複雑なコラボレーションがシンプルかつ信頼性の高いものになり、無限に抜け穴を修正するのではなく、ビジネス イノベーションそのものに集中できるようになります。

次回、複数ステップの操作やサービス間呼び出しを含む関数を設計するときは、次のことを考えてみるとよいでしょう。このリンクが途中で切断された場合、それ自体でクリーンアップできるか?おそらく、必要な設計図はサーガモードです。

2005年に設立され、キロパワーは、中国広東省東莞に本社を置く、コンパクトモーションユニットの専門メーカーです。モジュラードライブテクノロジーのイノベーションを活用し、キロパワー高性能モーター、高精度減速機、マルチプロトコル制御システムを統合し、効率的でカスタマイズされたスマート ドライブ システム ソリューションを提供します。 Kpower は、スマート ホーム システム、自動エレクトロニクス、ロボティクス、精密農業、ドローン、産業オートメーションなどのさまざまな分野をカバーする製品で、世界中の 500 を超える企業クライアントにプロフェッショナルなドライブ システム ソリューションを提供してきました。