マイクロサービス-キューを使用してサービスの失敗を補正する

アプリでは、ある種のマイクロサービスアプローチを使用しています（ただし、実際にはそれに準拠していません）。

サービスがダウンしているか例外がスローされている場合、アプローチはそれをキュー（ActiveMQ）に入れ、サービスが再びアップしたときに再試行します。

これは「標準」ソリューションですか？それとも、何らかの理由で回避する必要がありますか？

または、この問題に対するより良い、または代替の解決策はありますか？

呼び出しを非同期にできると仮定すると（続行するためにサービスから応答を取得する必要がない）、そうすることは多くの場合良い考えです。

これにより、呼び出し側のサービスは、他のサービスの呼び出しによって引き起こされる遅延（または完全なエラー）なしに作業を続行できます。これにより、より複雑な再試行ロジックを使用して、時間の経過とともに負荷をより均等に分散させることができます。

多くの場合、キューによって提供される順序付けの保証をあきらめ、Kafkaまたは別の非同期メッセージブローカーに切り替えることで、さらに多くのことを得ることができます。HermesはKafkaの上にさらに便利なREST APIを提供します。

これは私の考えでは悪いアプローチです。あなたはどちらか

• 常に通信してキューを表示する：アプリケーションは即時の応答を期待すべきではないため、ワーカープロセスが100％利用可能である必要はありません。

• 常にRPCスタイルの通信を使用します。複数のサービスインスタンス間でリクエストを負荷分散します。サービスに障害がある場合、別のサービスがリクエストに応答するため、100％の稼働時間が得られます。

フロー、サービスの呼び出し、エラーの発生、キューへの配置、すべてのメッセージではなく一部のメッセージへの返信がないかキューを確認することを忘れないでください。複雑すぎる。

編集：どちらか一方だけではなく、同期と非同期の両方の通信スタイルをプログラムする必要があるという点で、非常に複雑です。