現在、高いスループットが必要な Service Fabric マイクロサービスに取り組んでいます。

ワークステーションでループバックを使用して 1 KB のメッセージを毎秒 500 件以上処理できないのはなぜだろうと思いました。

エンド ツー エンドのパフォーマンスを測定するためだけに、すべてのビジネス ロジックを削除し、パフォーマンス プロファイラーを追加しました。

時間の ~96% がクライアントの解決に費やされ、実際の HTTP 要求の実行には ~2% しか費やされていないようです。

テストのためにタイトループで「送信」を呼び出しています。

これに関するアイデアはありますか？ドキュメントによると、サービスを呼び出す方法は Service Fabric のベスト プラクティスのようです。

更新: ServicePartioningClient をキャッシュするとパフォーマンスが向上しますが、パーティション化されたサービスを使用すると、特定の PartitionKey のパーティションがわからないため、クライアントをキャッシュできません。

更新 2 : 最初の質問に完全な詳細が含まれていなかったことをお詫びします。ソケットベースの通信を最初に実装したときに、InvokeWithRetry のオーバーヘッドが非常に大きいことに気付きました。

http リクエストを使用している場合は、それほど気にすることはありません。http リクエストには既に 1 ミリ秒程度かかるため、InvokeWithRetry に 0.5 ミリ秒を追加してもそれほど目立ちません。

しかし、私たちのケースで ~ 0.005ms かかる raw ソケットを使用すると、InvokeWithRetry に 0.5ms のオーバーヘッドが追加されます。

これは http の例です。InvokeAndRetry を使用すると、3 倍の時間がかかります。

InvokeWithRetry がクライアントから逃したくない素晴らしいものを追加することは承知しています。しかし、すべての呼び出しでパーティションを解決する必要がありますか?

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 が完全にダウンしたり一時的に削除されたりした場合でも、メッセージを決して失わないことであることに注意してください。したがって、直接呼び出しはありません。

ありがとう