Service Fabric の Reliable Services パイプラインを実装しようとしたとき、次の 3 つのアプローチから選択する必要がありました。
そして、Cが良い方法のようです。詳細はこちら。
この場合、ワーカー サービス間にある種のメッセージ ポンプを実装する必要があります。
たとえば、2 種類のワーカー サービスがあります。最初のものは IO バウンドで、スケーラビリティは必要ありません。2 つ目は CPU バウンドであり、スケーラビリティが必要なため、パーティショニングを使用します。具体的なアイテムの処理に正確にどのパーティションが使用されるかは気にしないので、メッセージ ポンプはロード バランサーとして機能し、入力キューに最小限のアイテムでアイテムを CPU バウンド サービスにエンキューする必要があります。とりあえず、この目的のためにステートフル サービスを作成しました。
この形式では、これは TPL Dataflow パイプラインに非常に似ています。
私の質問は、Service Fabric を正しく使用していますか? ここにオーバーエンジニアリングはありますか？
Reliable Actors は、この種のパイプラインにより適していますか? (またはパイプラインの一部)
