Service Fabric を使用して、サービス 1 (ほとんどが API) からサービス 2 (ほとんどが API) に送信する必要があるメッセージが失われないことを保証するための最適なアーキテクチャ (黒い矢印) は何ですか?
アイデア:
1
1.a. サービス 1 と 2 をステートフル サービスにします。ステートフルな Web API を持つのは悪い呼び出しですか?
1.b. Reliable Collections を使用して、API コードからサービス 2 にメッセージを送信します。
2
2.a. サービス 1 と 2 をステートレス サービスにする
2.b. 3 つ目のサービスを追加する
2.c. サービス 1 からキューイング システム (つまり、サービス バス) 経由でメッセージを送信します。
2.d. 3番目のサービスで受け取ります。注意: この 3 番目のサービスは、サービス 2 (API) がアクセスできる DB にもアクセスできます。マイクロサービス アーキテクチャの理想的なソリューションではありませんよね?
3
3.a. 他のアイデアはありますか？
目標は、サービス 2 が完全にダウンしたり一時的に削除されたりした場合でも、メッセージを決して失わないことであることに注意してください。したがって、直接呼び出しはありません。
ありがとう