バックエンド コンポーネントの開発では、これらのコンポーネントがどのように相互作用し、相互に通信するかを決定する必要があります。特に、(RESTful、micro) Web サービスとメッセージ ブローカー (RabbitMQ など) を使用する方が良いかどうかを判断する必要があります。各コンポーネントに Web サービスを使用するか、メッセージングを使用するかを決定するのに役立つ特定の基準はありますか?
2 に答える
エランダは彼の回答でこれについていくつか説明しましたが、主な要因は次の 3 つだと思います。
- Request-Response タイプの相互作用をモデル化していますか?
- インタラクションを非同期にすることはできますか?
- 情報の送信者は、受信者についてどの程度の知識を持っている必要がありますか?
非同期メッセージング インフラストラクチャで要求と応答のタイプの対話を行うことは可能ですが、複雑さが大幅に増加するため、一般的に要求と応答のタイプの対話 (つまり、送信者が受信者から返されるデータが必要かどうか) は、RPC/としてより簡単にモデル化できます。 REST インタラクション。
インタラクションが非同期になる可能性がある場合は、REST インタラクションを使用してこれを実装することができますが、ファイア アンド フォーゲット メッセージング タイプのインタラクションを使用すると、より適切に拡張できる可能性があります。
また、情報の提供者が誰が情報を消費しているかを気にしない場合は、非同期メッセージングの対話がより適切になります。情報プロバイダーが情報を公開し、その情報の新しいコンシューマーを後でシステムに追加しても、プロバイダーを変更する必要はありません。
Web server and message broker have their own use cases. Web server used to host web services and the message broker are use to exchange messages between two points. If you need to deploy a web service then you have to use a web server, where you can process that message and send back a response. Now let's think that you need to have publisher/subscriber pattern or/and reliable messaging between any two nodes, between two servers, between client and server, or server and client, that's where the message broker comes into the picture where you can use a message broker in the middle of two nodes to achieve it. Using message broker gives you the reliability but you have to pay it with the performance. So the components you should use depends on your use case though there are multiple options available.