マイクロサービスのための分散一貫性パターン

マイクロサービスの分割後に発生する問題の 1 つは、分散後の一貫性の問題です。モノリシック アーキテクチャのビジネス処理とデータはすべて 1 つのプロセスにまとめられており、一貫性の保証も非常に成熟しているため、開発者は基本的に心配する必要はありません。ビジネス システムがさまざまなプロセスに分割されると、技術的な一貫性の問題が発生します。これによりジレンマが生じますが、問題を一挙に解決できる特効薬があることを願っています。ただし、分散一貫性 (CAP) 理論には完璧なソリューションがないため、選択できるソリューションは特定のビジネス シナリオに応じたものになります。

ここで言う分散とは、特に大量のデータによって生じる分散ではなく、ビジネス ロジックの分割によって生じる分散を指します。

業務が分割されておらず、データ量が特に大きく分散する必要がある場合は、ビッグデータをサポートする分散データベースを選択できます。 Cassandra、MongoDB などの NoSQL、または TiDB などの SQL をサポートする分散ソリューションを選択できます。

ビジネスが分割されている場合、どのデータベースを選択しても、分散一貫性の問題を解決することはできません。データベースまたは分散データベースは、データベース内の外部要求の分散問題を処理できるが、複数の外部要求の一貫性の問題は処理できないシステムと考えてください。

分散型の強力な一貫性のあるデータベースでは、ビジネス ロジックの分割によって発生する分散一貫性の問題を解決できません。ビジネスの分散一貫性の問題をどのように解決するかについては、依然として苦労し続けなければなりません。

まず、マイクロサービスの分散一貫性の問題を、データ共有一貫性の問題とビジネストランザクション一貫性の問題に分けます。

1. データ共有の一貫性

モノリシック アーキテクチャでは、同じデータベースが使用されるため、データ共有の問題は発生しません。マイクロサービスでは独立したデータベースが重視されるため、データをどのように共有するかという問題が生じます。

データ共有は、プルとプッシュの 2 つのモードに分かれています。プルとは、コンシューマーがサプライヤーからデータをプルすることを意味し、プッシュとは、サプライヤーが積極的にコンシューマーにデータをプッシュすることを意味します。

1. プルビュー共有

一般的な企業情報システムの場合、データ量は大きくなく、同時実行性の要件も大きくありません。すべてのマイクロサービスで同じデータベース インスタンスを使用しながら、それを異なるスキーマに分割することをお勧めします。これの利点は、データベースがビジネス ロジックの面で独立しており、独立して進化できることです。データベースを集中管理できるようになります。このソリューションは、元々 1 つのデータベースにあった大規模なレガシー システムを分割するのに特に適しています。ビジネスをより自立的に進化させるために、データベース スキーマを分割し、元のデータベース インスタンス管理テクノロジを継続することができます。異なるマイクロサービスは実際には同じデータベース インスタンス上で実行されるため、ビューを作成するだけでデータを共有できます。

テーブル全体を抽出するのではなく、必要に応じていくつかのフィールドを選択する必要があることに注意してください。このモードは技術的にはシンプルですが、2 つの欠点があります。1 つ目は、ビューによって同期されるデータはリアルタイムであるため、アプリケーションはリアルタイム同期データを前提として設計される可能性があり、将来的に分散拡張を行うことが特に困難になります。 2 番目に、ビューはテーブル構造を簡単に公開できますが、公開されたビューが既存のテーブル構造に直接バインドされないように、ビューの設計と構造管理を特別に強化する必要があります。ビューに必要なフィールドはテーブル上にあるものではなく、外部要件です。このように、ビューはインターフェースですが、特定のデータベース インスタンスに強く結合されています。

2. プルAPI取得

マイクロサービスに最も推奨されるアプローチは、サービス プロバイダーがデータ API を提供し、消費者が必要に応じてそれを取得できるようにすることです。利点は、消費者とサプライヤーが技術的に完全に分離されることですが、欠点は開発コストが増加することです。コンシューマーが API を使用して必要なデータを取得する場合は、プログラミングに非同期 Stream メソッドを使用することをお勧めします。ビジネス リクエストで複数のデータ ソースを取得する必要がある場合は、処理時間が長くなるため、同期的に呼び出すことはお勧めしません。非同期プルとアセンブリには、reactiveX モードを使用することをお勧めします。

3. プッシュイベントメッセージ

イベントが発生したときにメッセージを送信することは、DDD CQRS パターンであり、コンシューマーが使用するデータを持つという問題 (ローカル データ構造を確立し、必要に応じてパフォーマンスとメソッドを取得する) を解決し、異種データベース テクノロジの問題も解決します。問題は、メッセージング プラットフォームが必要であり、消費者またはサプライヤーをメッセージング プラットフォーム テクノロジに結び付ける必要があることです。大規模なレガシー システムの変換にはあまり適していません。一方、レガシー システムのメッセージ プラットフォームは、高い同時実行性と大量のデータに対するパフォーマンス要件を満たさないことがよくあります。一方、新しいマイクロサービスでは、古いメッセージ プラットフォームに依存するのではなく、Kafka などの高同時実行性と軽量性を備えたインターネット メッセージ プラットフォームを使用したいと考えています。

4. データ共有の一貫性の選択の概要:

レガシー システムの変換や、データ量が少ないアプリケーション (1 日のトランザクション量が 100 万を超えない) の場合は、異なるマイクロサービスを使用して異なるスキーマを作成し、同じデータベース インスタンスを使用して、ビューを通じてデータを共有することをお勧めします。

一部のビジネス データが非常に大きく、共有する必要がある場合は、API 共有と非同期ストリーム プログラミングを使用してデータを共有します。

マイクロサービス プラットフォームの技術的設備が成熟している場合は、プッシュ イベント メッセージ モードを使用して、共有データ消費の利便性とデータ構造の分離の問題を解決できます。軽量メッセージング プラットフォーム (Kafka) を使用すると、技術的な結合はわずかにしか発生しません。

2. ビジネストランザクションの分散一貫性

ビジネス トランザクションの分散一貫性とは、異なるマイクロサービス システムで処理されるリクエストを指し、一貫性の調整の問題を引き起こします。

トランザクション分散一貫性は、補償モード、セカンダリ送信モード、および Saga モードに分かれています。

1. 補償モード

補正モードは主に再試行を通じて最終的な成功を達成し、ビジネスにおいてトランザクション要求が失敗してはならないシナリオにのみ適用されます。

最も一般的に使用される補償モードはメッセージ配信です。 A にメッセージを送信するとします。A からメッセージが受信されたことの確認が届かない場合は、A がメッセージが受信されたことを確認するまで送信を続けます。

必ず成功しなければならない取引に発展する可能性のあるビジネスはたくさんあります。例えば、注文して代金を支払う際に、先に注文を確認してから代金を引き落とすと、口座の残高不足により引き落としが失敗し、事業が失敗する可能性があります。先に代金を引いてから注文を確定する業務に変更した場合、注文が正常に確定されているとみなすことができます。この状況を達成するには、トランザクションが成功する必要があります。技術的な実装は比較的簡単です。タスク キューは、タスクの完了ステータスを追跡して再試行するかどうかを決定するために使用されます。補正モードでは、タスクが成功してもコンシューマーがそれに気付かず、タスク要求を再度発行する可能性があるため、API がべき等である必要があります。

2. 二次提出モード

補償モデルはビジネスへの調整を必要とし、適用範囲が比較的狭いため、一般的な分散一貫性ソリューションが提供されることを期待しています。

最も有名なのは 2 コミット モード、具体的には TCC (Try、Confirm、Cancel) です。まず、ビジネス タスクの参加者が処理の準備ができるように、試行要求を開始します。参加者全員が準備ができたら、確認のために確認リクエストを発行します。すべてのビジネス参加者が事前に準備を行っているため、確認フェーズで一度の成功を確実にすることができます。

参加者のいずれかがそれを認識した場合、キャンセルが送信され、ロールバックされます。このモードは基本的にデータトランザクション管理と同じです。たとえば、Java の JTA 実装 Automikos は、データベース トランザクションと REST API の両方をサポートします。セカンダリコミットはトランザクションの一貫性の問題を解決できますが、コストが比較的高くなります。ビジネス プロセスは、準備と実行確認の 2 つの段階に分割する必要があり、ビジネス設計と開発コストに高い要求が課せられます。

3. サガパターン

Sagas モードはシンプルで、補償モードとセカンダリ送信モードでの分散トランザクション シナリオを幅広くサポートできます。セカンダリ送信モードは悲観的ロックに基づいているため、すべてのタスク参加者は実行前に準備する必要があります。

Saga と補正モードは楽観的ロックに基づいており、タスク参加者が最初に実行できるようにします。応答がない場合は、再度実行する必要があります。 Saga が参加者にタスクを発行すると、イベント (Saga の中国語訳は「行為」) が記録され、すべてのイベントが永続的になります。 1 人の参加者が実行に失敗した場合、すべての参加者にロールバックを要求するキャンセル要求が発行されます。ほとんどのトランザクション要求は成功するため、楽観的ロックに基づくこの調整メカニズムにより一貫性が実現され、開発コストが削減され、ビジネス設計が理解しやすくなります。

現在、Saga をサポートする Java フレームワークには、Huawei のオープンソース servicecomb saga が含まれており、JD.com はすでに一部のオンライン システムでこれを使用しています。 saga を実装する Axoniq と呼ばれる CQRS フレームワークもあります。

【この記事は51CTOコラムニスト「張毅」によるオリジナル記事です。転載については原著者にお問い合わせください。

この著者の他の記事を読むにはここをクリックしてください