TPL Dataflow、Akka.NETに関するアドバイス、または単一プロセスのイベントドリブンデザインのアドバイス？

Question

私のプロジェクトでは、1つのプロセス内で複数のサービスを実行する中央コンポーネントがあります。たとえば、スケジューラがあり、DBからデータをポーリングし、ジョブ（同時に実行されるジョブが可能）を起動します。 ジョブが終了すると、スケジューラに通知されます。 通知サービスもあります。メールやその他のサービスが別のサーバーをポーリングして保留中のジョブなどに通知します。 このようなアプリケーションでは、デカップリングを減らすためにイベント駆動型の設計が有効です。私の究極の目標は、複雑さを軽減することです。パフォーマンスの問題はありません。ここではいくつかのアイデアです：

1. 使用イベントやメカニズムを購読公開の中央ハブと反応拡張子。
2. 使用TPLデータフロー
3. 使用AKKA.NET私に

すべてのアプローチはしかし合法的に見える：それは戦いに単純すぎるかも知れません実装がはるかに簡単

1-）複雑さに対して

2）TPLデータフローはかなり良く見えますが、ドキュメントでは重いCPUまたはI/Oには が適していると書かれています。どちらも私にとっては問題ではありません。また、AKKAのアプローチとは異なり、TPL DataFlowは単一のプロセスです。将来、これらのサービスを別々のプロセスに分ける必要がある場合は、いくつかのコードを変更する必要があります。

3-）Akkaは並行性と耐久性の問題を重視しています。将来的にはこれらのサービスをより小さなプロセスに分ける必要があるが、実装するのは過度なことかもしれないが、それは良い選択であろう。

あなたはどう思いますか？

Answer 1

あなたが受信を使用して取得します痛みは、あなたが（RxのIScheduler実装と）仕事のスケジュールを設定している場合ということで、その後の作業の論理的なキューは、次のとおりです。

• メモリ内
• 簡単に計測されていませんか視覚化

システムに問題がある場合、これらのことが問題を悪化させます。監視とデバッグのためにキューの深さを確認するのに苦労します。また、プロセスが失敗すると、スケジューラーの実装内の論理キュー内の項目が失われます。

ただし、データベースをキューイング機構として使用する場合（Hangfireの場合のように）、Rxを使用してデータベースをポーリングするだけです。これは反応的ではない、これはデータをポーリングして引っ張ることである。この場合、Rxはツールの奇妙な選択と思われます。 Wont use Rxを参照してください（さらに、キューから引き出すときにRxを使用しないためのトランザクションとしてTransactionalityを挙げる必要があります）。

Hangfireと書かれているので、私はそれを見ることもお勧めします。それは完璧なフィット感があるようです。小型でインストールが簡単（ナゲット）、Sql Serverで動作します（あなたのDBを前提としています）。

怒りの中でAkka.NETを使ったことは一度もありませんでしたが、これは私が検討するもう1つの選択肢です。