これを尋ねる既存の投稿は見つかりませんでしたが、見逃した場合は謝罪します。
私は自分の頭をマイクロサービスにしようとしていますが、RabbitMQが使用されている記事に出くわしました。 RabbitMQが必要な理由がわかりません。サービスがWeb APIを使用して外部と通信し、RabbitMQが相互に通信することを意図していますか?
マイクロサービスアーキテクチャでは、マイクロサービス間で通信する2つの方法があります。
microservices.io には、マイクロサービスの使用に関する非常に素晴らしい記事があります
メッセージキューは、非同期通信プロトコルを提供します-別のサービスができるかどうかを知らなくても、あるサービスから別のサービスにメッセージを送信するオプションがありますすぐに処理するかどうか。メッセージは、責任のあるサービスの準備ができるまで待つことができます。メッセージを発行するサービスは、そのメッセージを処理するサービスの内部動作について何も知る必要はありません。このメッセージの処理方法decoupleプロデューサーとコンシューマー。
メッセージキューは、アプリケーション内のプロセスを分離し、互いに独立した状態に保ちます。このメッセージ処理方法は、保守が容易で、スケーリングが容易なシステムを作成できます。
ここ は、Parkster(デジタルパーキングサービス)がRabbitMQを使用してシステムを複数のマイクロサービスに分割する方法を説明するストーリーです。
このガイド WebアプリケーションがユーザーにWebサイトへの情報のアップロードを許可するシナリオに従います。サイトはこの情報を処理してPDFを生成し、ユーザーにメールで送り返します。情報を処理し、PDFを生成してメールを送信すると、この例では数秒かかり、それがメッセージキューが使用される理由の1つです。
ここ は、howとwhyに関するストーリーです。CloudAMQPは、マイクロサービス間でメッセージキューとRabbitMQを使用しました。
ここ は、イベントベースのマイクロサービスアーキテクチャでRabbitMQを使用して、1か月で1億人のユーザーをサポートすることに関するストーリーです。
そして最後に、コンテナへの link で、彼らがマイクロサービスアーキテクチャにRabbitMQを選んだ理由について、「メッセージングに安定した、管理しやすく、可用性の高いソリューションが必要だったから」。
CloudAMQPの背後にある会社で働いていることに注意してください。
マイクロサービスにRESTが必要な理由は同じかもしれません。マイクロサービスの概念は、月の下では新しいものではありません。バックエンドエンジニアリングと非同期リクエスト処理にワークフローの長い分散が使用されました。Microserviceは、SOLIDのS(単一責任)と一致する分離されたjvmの同じコンポーネントです。それをマイクロサービスにしているのは、バランスが取れていることです。そして、それがすべてです!特に(!)、Eurekaによって登録されているSpring Cloud/RESTベースのRESTサービスであり、プロキシゲートウェイと、ZuulおよびRibbonを介した負荷分散があります。しかし、それはマイクロサービスの全世界ではありません!ところで、非同期分散処理は、マイクロサービスが使用されるタスクの1つです。ずっと前に、分離されたJVMのサービス(コンポーネント)はメッセージング上に統合され、そのパターンはESBとして知られています。マイクロサービスは、パターンと同じ主題です。 Spring Cloudの流行により、RESTはマイクロサービスの唯一の方法のように思えます。いや!メッセージベースの非同期マイクロサービスアーキテクチャは、Vertxでサポートされています https://dzone.com/articles/asynchronous-microservices-with-vertx など。 RabbitMQをメッセージチャネルとして使用しないのはなぜですか?この場合、RabbitMQクラスターを構築することで負荷分散を提供できます。例: https://codeburst.io/using-rabbitmq-for-microservices-communication-on-docker-a43840401819 ですから、世界はもっと広くなっています。