Des conseils sur TPL Dataflow, Akka.NET ou encore pour une conception événementielle pour un seul processus?

Question

Dans mon projet, j'ai un composant central qui exécute plusieurs services dans un seul processus. Par exemple, il existe un planificateur, qui interroge les données de la base de données et déclenche un travail (les travaux en cours d'exécution sont possibles). Et lorsque le travail est terminé, il avertit le planificateur. Il existe également un service de notification qui envoie des courriers ou d'autres services d'interrogation à un autre serveur pour notifier les travaux en attente, etc. Pour une telle application, je pense qu'une conception pilotée par événement est une bonne idée pour réduire le découplage. Mon but ultime est la réduction de la complexité. Je n'ai pas de problème de performance. Voici quelques idées:

1. Utiliser des événements ou extensions réactives avec un moyeu central sur Publish mécanisme Abonnez-vous.
2. Utilisez TPL Dataflow
3. Utilisez AKKA.NET

Pour moi, toutes les approches regard legit si:

1) beaucoup plus simple à mettre en œuvre si elle peut être trop simple pour combattre contre la complexité. 2-12 TPL Dataflow semble assez bon, mais de la documentation, il est convient pour un processeur ou des E/S lourds. Aucun de ceux-là n'est un problème pour moi. Contrairement à l'approche AKKA, TPL DataFlow est un processus unique. Si à l'avenir j'ai besoin de séparer ces services pour séparer les processus, je dois changer du code. 3-12) Akka met fortement l'accent sur les problèmes de simultanéité et de durabilité. Il semble que ce soit un bon choix si, à l'avenir, je dois séparer ces services en processus plus petits, mais cela pourrait aussi être trop difficile à mettre en œuvre.

Qu'en pensez-vous?

Answer 1

La douleur que vous obtiendrez avec l'aide de Rx, est que si vous planifiez le travail (avec les implémentations Rx iScheduler), puis les files d'attente logiques de travail sont:

• en mémoire
• pas facilement instrumenté ou visualisé

Si vous avez des problèmes avec le système, ces éléments vont exacerber le problème. Vous aurez du mal à voir la profondeur de la file d'attente pour la surveillance et le débogage. Et si le processus échoue, vous perdrez les éléments dans les files d'attente logiques dans l'implémentation du planificateur.

Toutefois, si vous décidez d'utiliser la base de données comme mécanisme de mise en file d'attente (comme le fait Hangfire), vous utilisez simplement Rx pour interroger la base de données à votre place. Ce n'est pas réactif, c'est l'interrogation et l'extraction de données. Dans ce cas, Rx semble un choix étrange d'outils. Voir Wont use Rx (qui devrait en outre citer Transactionality comme un pilote pour ne pas utiliser Rx lors du tirage à partir de files d'attente).

Ayant mentionné Hangfire, je suggère également de le regarder. Cela semble être un ajustement parfait. Petit, facile à installer (nuget), fonctionne avec SQL Server (en supposant que c'est votre base de données) et gère ce genre de choses pour vous.

N'ayant jamais utilisé Akka.NET en colère, ce serait l'autre option que je considérerais.