Рекомендации по потоку данных TPL, Akka.NET, а также для проекта, управляемого событиями для одного процесса?

Question

В моем проекте у меня есть центральный компонент, который выполняет несколько сервисов внутри одного процесса. Например, есть планировщик , который опросает данные из БД и запускает задание (возможно одновременное выполнение заданий). И когда завершается работа , она уведомляет планировщика. Существует также служба уведомлений , которая отправляет письма или другие сервисные опросы другого сервера, чтобы уведомить ожидающие задания и т. Д. Для такого приложения я чувствую, что дизайн, ориентированный на события, является хорошей идеей для сокращения развязки. Моя конечная цель - уменьшить сложность. У меня нет проблемы с производительностью. Вот некоторые идеи:

1. Используйте события или Реактивные расширения с центральным концентратором на Опубликовать Подписка механизм.
2. Использование TPL Dataflow
3. Использование AKKA.NET

мне все подходы выглядят законны, хотя:

1) намного проще реализовать, хотя это может быть слишком просто, чтобы бороться от сложности.

2) TPL Dataflow выглядит неплохо, но из документации в нем указано, что это подходит для тяжелых процессоров или ввода/вывода. Ни одна из них не проблема для меня. Кроме того, в отличие от подхода AKKA TPL DataFlow - это единственная вещь процесса. Если в будущем мне нужно будет отделить эти службы от отдельных процессов, мне придется изменить какой-то код.

3-) Акка сильно подчеркивает параллелизм и проблемы с долговечностью. Кажется, это хороший выбор, если в будущем мне нужно будет отделить эти службы от небольших процессов, но это может быть слишком сложным для реализации.

Как вы думаете?

Answer 1

Боль вы получите с помощью Rx, является то, что, если вы планирования работы (с реализациями Rx IScheduler), то логические очереди работы:

• в памяти
• не легко инструментальными или визуализированный

Если у вас есть какие-либо проблемы с системой, эти вещи усугубят проблему. Вам будет сложно увидеть глубину очереди для мониторинга и отладки. И если процесс завершится неудачно, вы потеряете элементы в логических очередях в реализации планировщика.

Однако, если вы решили использовать базу данных в качестве механизма очередей (например, Hangfire), тогда вы действительно используете Rx для опроса базы данных для вас. Это не реагирует, это опрос и вытягивание данных. В этом случае Rx кажется странным выбором инструментов. См. Wont use Rx (который должен далее ссылаться на Transactionality как на драйвер для не использования Rx при выводе из очередей).

Отметив Hangfire, я также предлагаю посмотреть на него. Кажется, он идеально подходит. Маленький, простой в установке (nuget), работает с Sql Server (при условии, что это ваша БД) и управляет этим материалом для вас.

Никогда не использовал Akka.NET в гневе, это был бы другой вариант, который я бы рассмотрел.