マイクロサービス アーキテクチャでサービス間の非同期通信にどう対処するか?

インターネット技術の発展に伴い、さまざまなアプリケーション システムの規模と複雑さも増大しています。従来のモノリシック アプリケーション アーキテクチャでは、急速に増大するトラフィックとますます複雑化するビジネス ロジックに対処することが困難です。したがって、マイクロサービス アーキテクチャは多くの企業や開発者によって選択されるようになりました。

マイクロサービス アーキテクチャは、1 つのアプリケーションを複数の独立したサービスに分割し、それぞれの API インターフェイスを介してサービス間の対話と通信を実現します。アプリケーションを小さなサービスに分割するこの方法により、開発と展開が容易になるだけでなく、全体的なスケーラビリティと保守性も向上します。しかし、マイクロサービス アーキテクチャでは非同期通信の問題が重要な課題となっており、本記事ではマイクロサービス アーキテクチャにおけるサービス間の非同期通信の問題への対処方法を紹介します。

1. 非同期通信が必要な理由

マイクロサービス アーキテクチャでは、サービス間の通信方式は同期と非同期の 2 種類に分類されます。同期通信とは、呼び出し側がリクエストを送信した後、受信側の応答を待ち、応答を受信するまでは後続の操作を続行できないことを意味します。フロントエンド JavaScript の同期リクエストと非同期リクエストの概念に似ています。

非同期通信とは、呼び出し側がリクエストを送信した後、受信側からの応答を待たずに後続の操作を実行し続けることができることを意味します。受信者はリクエストを受信すると、メッセージ ミドルウェアを通じて非同期に処理し、呼び出し元に応答します。マイクロサービス アーキテクチャでは、サービス間の呼び出しが非常に頻繁に行われるため、すべての同期通信方式を使用すると、大量のブロッキングが発生し、システムのパフォーマンスに影響を与えます。したがって、非同期通信を使用すると、この問題をより適切に解決できます。

2. マイクロサービス非同期通信の技術的実装

マイクロサービス アーキテクチャでは、メッセージ キューなどの技術的手段を使用して非同期通信を実装できます。一般的に使用されるメッセージ キューには、RabbitMQ、Kafka、IonMQ などが含まれます。

(1) メッセージ キュー

メッセージ キューは、あるサービスから別のサービスにメッセージを転送して、サービスを分離できる非同期通信メカニズムです。メッセージ キューは通常、プロデューサーとコンシューマーで構成されます。プロデューサーはキューにメッセージを送信する責任を負い、コンシューマーはキューからメッセージを読み取って処理する責任を負います。

マイクロサービス アーキテクチャでは、メッセージ キューはサービス間の「転送ステーション」として機能し、あるサービスから別のサービスにメッセージを渡して非同期通信の効果を実現できます。たとえば、注文サービスの注文作成メッセージをメッセージ キューを通じて倉庫サービスに渡し、在庫変更操作を実行できるようにします。

(2) イベント ソーシング

イベント ソーシングは、いつでもバックトラックしてクエリできるように、アプリケーションのすべてのイベント状態を記録および保存するイベント駆動型の開発モデルです。イベント ソーシングにより、開発者はアプリケーションのすべての動作を理解し、システムのデバッグと修復を容易にすることができます。

マイクロサービス アーキテクチャでは、イベント ソーシングを非同期通信に使用できます。サービスがメッセージを送信すると、受信側は将来の参照のためにメッセージを記録します。このアプローチは、開発者がサービス間の順序の乱れやタイムアウトの問題をより適切に処理するのに役立ちます。

3. マイクロサービスの非同期通信の実践

マイクロサービス アーキテクチャで非同期通信の問題に対処する場合は、次の点に注意する必要があります。

(1) メッセージ送信時のブロックを回避する

サービスがメッセージ キューにメッセージを送信するとき、同期呼び出しを使用することはできません。そうしないと、送信者はここ​​でブロックされ、受信者の応答を待ちます。したがって、システム全体のパフォーマンスに影響を与えます。したがって、非同期通信の送信者は、メッセージ送信の影響を最小限に抑え、メッセージの送信後もサービスが継続して実行できるようにする必要があります。

(2) メッセージの信頼性を確保する

非同期通信システムではメッセージを制御できないため、メッセージの損失、順序の乱れ、繰り返し送信などの問題に対処する必要があります。たとえば、メッセージ キューの再試行メカニズムを使用して、メッセージ配信の信頼性を確保できます。さらに、一部のメッセージ キューは信頼性の高い TCP などの複数の送信プロトコルもサポートしており、カスタム プロトコルを使用して複数のコピーを実装してデータを複製および同期することもあります。

(3) 適切なメッセージ キューの選択

メッセージ キューが異なれば、スループット、応答時間、メッセージの耐久性などの特性も異なります。メッセージ キューを選択するときは、実際のビジネス ニーズに基づいて選択する必要があります。たとえば、メッセージ配信の高い信頼性を実現する必要がある場合は、RabbitMQ メッセージ キューの使用を選択でき、メッセージ配信の高スループットを確保する必要がある場合は、Kafka の使用を選択できます。

(4) 分散トランザクションの使用は可能な限り避ける

マイクロサービス アーキテクチャでは、分散トランザクションを使用すると、履歴やスケーラビリティに問題が発生する可能性があります。したがって、マイクロサービスの非同期通信におけるデータの一貫性制御を実現するには、分散トランザクションの使用をできるだけ避けてください。

4. 結論

マイクロサービス アーキテクチャにおける非同期通信の問題に対処することは、マイクロサービス開発プロセスにおける重要な問題です。この記事では、非同期通信が発生する理由と実装方法を紹介し、実際に非同期通信を処理する方法について提案するため、マイクロサービス アーキテクチャの設計と実装の参考になります。

以上がマイクロサービス アーキテクチャでサービス間の非同期通信にどう対処するか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。