Amazon SNSおよびSQSを使用した.NET Coreマイクロサービスメッセージング
だから私はいくつかの検索を行いましたが、このトピックに関する多くの提案を見つけることができないようです。私の質問は、.NET CoreベースのWebAPIマイクロサービスでAmazon SQSキューからメッセージを受信する最良の方法について、どのような意見がありますか？プロジェクト全体は約5つのマイクロサービスで構成され、インフラストラクチャにAWSを利用しています。サービスがAmazon SNSトピックにイベントを発行し、それらのメッセージがサブスクライブされているSQSキューに配信される基本的なpub/subスタイルのイベントバスを実装しました。メッセージを受信するにはSQSキューをポーリングする必要があるため、いくつかの解決策を考え出すことができました。
- 長いポーリングを使用して、メッセージのキューを継続的にポーリングします。
- メッセージがSQSに配信されたときにラムダ関数をトリガーします。SQSは、サブスクライブしているマイクロサービスにHTTPリクエストを送信し、メッセージが到着したことを通知します。
最初のオプションは、不要なネットワークトラフィックを引き起こし、リソースを占有する可能性があるため、私には非効率的です。後者のオプションは私にはまともな解決策のように見えますが、サービス自体がECSでホストされ、複数のインスタンスが実行されてメッセージを消費する可能性があるため、競合する消費者シナリオに対処するために追加の作業が必要になる場合があります。
だから、私の質問は、私がここで正しい軌道に乗っているように見えるのでしょうか？あるいは、誰かが提案できると私が考えていなかった他のいくつかの解決策がありますか？フィードバックに感謝します。これは私の最初の投稿ですので、十分な背景情報を提供できなかったことをお詫び申し上げます。ありがとう。
組み込みのロングポーリングを使用するか、固定間隔でポーリングするだけです。
受信するメッセージがないときに帯域幅を浪費するだけなので、ネットワーク帯域幅を使いすぎても問題はありません。これにより、無駄な帯域幅を制御可能な小さな量に制限します。たとえば、キューごとに10秒ごとに1つのメッセージを送信します。
プッシュモデルに移行すると、大量のトラフィックがある場合、何千ものメッセージがプッシュされます。これは、単一の受信呼び出しが複数のメッセージを取得するので使用されません。
ここでは、はるかに多くの帯域幅と制御不能な量を浪費しています。