マイクロサービスアーキテクチャに基づくアプリケーションの最初のバージョンがあります。外部および内部の通信にはRESTを使用しました。
ここで、CP（CAP定理）*からAPに切り替え、マイクロサービス間の通信にメッセージバスを使用します。Kafka、RabbitMQなどに基づいてイベントバスを作成する方法については多くの情報があります。しかし、RESTとメッセージングの組み合わせのベストプラクティスは見つかりません。たとえば、自動車サービスを作成し、さまざまな自動車コンポーネントを追加する必要があるとします。この目的のために、POST要求でRESTを使用する方が理にかなっています。一方、車を予約するためのサービスは、イベントベースのアプローチには適しています。
辞書とビジネスロジックの機能が異なる場合、同様のアプローチがありますか？それらをどのように組み合わせるのですか？両方のアプローチを別々にサポートするだけですか？または、1つのアプローチでそれらを統合しますか？
*最初のバージョンでは、一貫性とパーティションの許容範囲を選択することに同意しました。しかし今では、可用性が私たちにとってより重要になっています。
結論：コマンドクエリの責任の分離を探しています。これは、データのクエリから実行するプロセスの要求までの責任を分割するためのアーキテクチャパターンを定義します。簡単に言うと、クエリまたはプロセスのいずれかで2つをブロック的に混在させたくないということです。この回答の残りの部分では、その理由と、実行しようとしていることを実行できる3つの異なる方法について詳しく説明します。
この回答は、マイクロサービスでの経験の短い形式です。私の善意：マイクロサービストポロジをゼロから作成し（そして知識はほとんどゼロ）、彼らが言うように、途中ですべてのブランチにヒットしました。
ゼロ知識から始めることの利点の1つは、私が作成した最初のトポロジで、サービス内同期およびブロッキング（HTTP）通信（操作に必要なデータを保持しているサービスから取得するため）とメッセージキューを組み合わせて使用したことです。 +操作を実行するための非同期イベント（コマンド用）。
両方の用語を定義します。
コマンド：サービスに何かをするように指示します。たとえば、「ETLバッチジョブの実行」です。これからの出力があることを期待します。しかし、それは必然的にあなたが確実に待つことができないであろうプロセスです。コマンドには副作用があります。このアクションにより、何かが変化します（何も起こらず、何も変化しない場合は、何もしていません）。
クエリ：保持しているデータをサービスに要求します。このデータは、コマンドが与えられたために存在した可能性がありますが、データを要求しても副作用はありません。クエリを受信したため、コマンド操作を実行する必要はありません。
とにかく、トポロジーに戻ります。
この最初のトポロジでは、同期クエリと非同期イベントの発行を混合しました。これは...問題がありました。
メッセージバスは本質的に観察可能です。RabbitMQの1つの設定、またはイベントソースであり、システム内のすべてのイベントを監視できます。これにはいくつかの良い副作用があります。プロセスで何かが発生すると、通常、どのイベントがその状態につながったかを把握できます（イベント駆動型パラダイム+ステートマシンに従う場合）。
HTTP呼び出しは、ネットワークトラフィックを検査するか、それらの要求をログに記録しないと監視できません（これ自体に問題があるため、通常の操作では「実行不可能」から始めます）。したがって、メッセージベースのプロセスとHTTP呼び出しを混在させると、何が起こっているのかわからない穴ができてしまいます。ネットワークエラーが原因でHTTP呼び出しがデータを返さず、そのためにサービスがプロセスを続行しなかった場所があります。また、HTTP呼び出しの再試行/サーキットブレーカーパターンを接続して、少なくとも数回試行するようにする必要がありますが、「ダウンしているためアップしない」と「一時的にビジーであるためアップしない」を区別する必要があります。 "。
つまり、コマンド駆動型プロセスで2つの方法を組み合わせると、回復力が低下します。
この成熟度モデルのステップ2では、コマンドとクエリを分離します。コマンドはイベント駆動型システムを使用する必要があり、クエリはHTTPを介して発生する必要があります。コマンドのクエリの結果が必要な場合は、メッセージを発行し、メッセージバスを介して要求/応答パターンを使用します。
これには利点と問題もあります。
利点に関しては、コマンドが複数のサービスをホップしている場合でも、コマンド全体を監視できるようになりました。イベントを再実行することでシステム内のプロセスを再生することもできます。これは、問題の追跡に役立ちます。
問題に関しては、イベントの一部がクエリによく似ています。これで、HTTPでメッセージに使用できる美しいHTTPおよびRESTセマンティクスを再作成しています。そして、それはひどく楽しくも便利でもありません。例として、404はRESTにデータがないことを示します。メッセージベースのイベントの場合、それらのセマンティクスを再作成する必要があります（私が見つけることができない主題についての良いYoutube会議の話がありますが、チームはそれを非常に苦労してやろうとしました）。
ただし、イベントは非同期で非ブロッキングになり、すべてのサービスは、特定のイベントに応答するステートマシンにリファクタリングできます。いくつかの注意点は、これらのイベントには操作に必要なすべてのデータが含まれている必要があることです（これにより、プロセスの過程でメッセージが大きくなります）。
クエリは引き続き外部通信にHTTPを使用できます。ただし、内部コマンド/プロセスの場合は、メッセージバスを使用します。
このアプローチもお勧めしません（最初のアプローチからのステップアップですが）。イベントが不純になり始めるため、お勧めしません。マイクロサービスシステムでは、システム全体で契約が同じであることが重要です。
成熟度モデルの3番目のステップ（およびプロジェクトを離れたときにそのパラダイムに向かっていた）は、データを生成するサービスが、そのデータが生成されたときにイベントを発行することです。次に、そのデータは、それらのイベントをリッスンしているサービスによって書き留められ、それらのサービスは、その（可能性がありますか？）古いデータを使用して操作を実行します。外部のお客様は引き続きHTTPを使用しています。ただし、内部的には、新しいデータが生成されたときにイベントを発行し、そのデータを処理する各サービスは、必要なときに使用するためにデータを保存します。これは、MichaelBryzekの講演「マイクロサービスアーキテクチャの正しい設計」の核心です。Michael Bryzekは、ホワイトレーベルのeコマース企業であるFlow.ioのCTOです。
他の問題と一緒にもっと深い答えが必要な場合は、このテーマに関する私のブログ投稿を紹介します。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加