Messagerie persistante / Bus de service - Rouler seul ou risquer la courbe d'apprentissage?

Question

Nous avons une application cliente qui doit envoyer des messages à un serveur pour diverses notifications. Pour que le client puisse exécuter une connexion occasionnelle, je vais utiliser une approche de file d'attente de messages. Le traitement de la file d'attente retirera les messages de la file d'attente et appellera un service Web qui les mettra dans une autre file d'attente pour qu'ils soient enfin traités. Cette question concerne l'environnement client. l'environnement du serveur est déjà décidé.

Je ne souhaite pas utiliser MSMQ, car nous n'avons pas le contrôle de tous les ordinateurs clients pour pouvoir installer / configurer et sécuriser correctement MSMQ, et parce que l'assistance est plus complexe en raison de la qualité des outils permettant d'enquêter sur le contenu. des files d'attente MSMQ. SQL Server 2005 Express est présent sur toutes les machines et permet de stocker des données pour notre application.

Je dispose actuellement de deux options:

1. Écrivez une file d'attente de messages persistante relativement basique qui stocke les messages dans une table après leur sérialisation, puis utilise ThreadPool.QueueUserWorkItem pour les faire traiter par des gestionnaires configurés pour chaque type de message. Tous dans un System.Transactions.TransactionScope afin qu'ils ne soient supprimés de la file d'attente persistante que s'ils ont été traités avec succès.
2. Utilisez NServiceBus (c'est le bus de service que nous avons utilisé en équipe, donc MassTransit, etc. ne sont pas des options) sur le client, avec un transport Service Broker qui utilise la base de données locale.

Comme je connais peu les bus de service (je ne connais pas encore très bien la terminologie des bus de service), je suis préoccupé par la courbe d'apprentissage par rapport à l'écriture de quelque chose de beaucoup plus simple qui répond à mes besoins de la manière dont j'en ai besoin ( le déploiement est une grosse considération).

Quelqu'un a-t-il des idées?

Answer 1

Finalement, j'ai écrit un bus de message de base configuré avec mon propre SqlTransport afin que les messages soient sérialisés et enregistrés dans une table de base de données SQL Server, avant que les événements ne soient déclenchés et qu'un thread séparé soit désigné pour traiter les messages.

Answer 2

Eh bien, je ne sais pas si je vais suggérer MSMQ, mais je dirai qu'il y a beaucoup de cas extrêmes sur lesquels il faut réfléchir pour 'rouler soi-même'.

Même avec une approche de pool de threads, sachez qu'il peut y avoir des problèmes d'ordre si vous y tenez - deux éléments postés séquentiellement sur les pools de threads peuvent ne pas être exécutés dans l'ordre, en raison de la manière dont les pools de threads traitent éléments de travail.

Vous devrez également penser à la persistance des messages, à leur durée d'existence, à la détection du statut de non-remise "fatale" et aux mesures à prendre dans ce cas.

Il existe également un certain nombre de cas de figure potentiels dans les cas où votre application tombe en panne au même moment où elle met un message en file d'attente. Par exemple, elle peut ne pas recevoir l'accusé de réception indiquant que le message a été mis en file d'attente, même s'il l'a été. Oui, vous pouvez accuser réception de la file d'attente, mais vous pouvez sans fin entrer dans les cercles d'acquittement ...

Pourquoi ne pas simplement laisser l’application détecter quand elle se connecte et envoyer toutes les données à ce moment-là?

Answer 3

Après avoir écrit notre propre bus de service, je peux vous dire que ce n'est pas une entreprise triviale et que vous rencontrerez les mêmes problèmes que tous les autres développeurs. Kyoryu en appelle deux très importantes.

Que vous fassiez le bon choix dépend également des compétences que vous possédez en interne et que vous aurez à l'avenir pour maintenir la solution.

Une autre considération est l’éventuelle échelle du système et ses exigences de fiabilité. La solution interne sera-t-elle suffisamment évolutive?

Notre bus de messages poste à poste, Zebus, basé sur ZeroMq (transport), Cassandra (découverte et persistance entre pairs) et Protobuf (sérialisation).

1. Aucun déploiement de client car sur le client, il ne s'agit que d'une bibliothèque
2. La persistance des messages est également fournie à l'aide de Cassandra et gère de nombreux cas différents (ceci est régulièrement testé dans notre environnement de production)
3. Il fonctionne bien et comme il s’agit d’une solution sans intermédiaire, il n’ya pas de goulet d’étranglement en matière de performances
4. Il n'y a pas de point de défaillance unique car l'annuaire peut être utilisé avec un magasin de données disponible tel que Cassandra

Il est open source et testé en production https://github.com/Abc-Arbitrage/Zebus