Basculement en cas de panne pour le bus de service avec NServiceBus ou MassTransit

Question

J'ai besoin de construire un serveur d'identité comme Microsoft http://login.live.com.

Pour gérer le basculement, j'ai plusieurs nœuds de serveurs Web. Le plan est que toutes les opérations d'écriture de base de données sont effectuées en envoyant des messages au serveur de base de données. La base de données sera mise en miroir ou répliquée. L'idée est que la base de données s'abonne aux opérations d'écriture mais que les autres nœuds s'abonnent également. De cette façon, les autres nœuds n'ont pas besoin de lire dans la base de données et peuvent mettre à jour leurs caches.

Je commence tout juste à apprendre l'architecture du bus de service et ce que je ne comprends pas, c'est comment gérer le scénario de basculement pour le bus de service.

Question:

1. Si le serveur de base de données ne sont pas disponibles, ce qui se passera avec les messages publiés?
2. Seront-ils stockés quelque part et où?
3. Ai-je besoin d'une machine supplémentaire ou d'un cluster pour gérer le basculement du bus de service?
4. J'ai lu que SQL Server peut être utilisé comme un magasin de messages, mais puis-je utiliser MSMQ durable? Je file des messages pour pouvoir les écrire dans la base de données, alors pourquoi les stocker dans la base de données juste pour les prendre et les écrire à nouveau? OU, je me trompe et DB est seulement utilisé pour la liste des abonnements et pas pour les messages?

Answer 1

1. Cela dépendra de la façon dont il est configuré, mais MassTransit vous pouvez laisser l'abonnement actif pour que le message sera toujours livré à la file d'attente pour la DB. Lorsque le DB est à nouveau actif, vous pouvez lire les messages dans la file d'attente. Chaque service connecté à un bus de service, dans MassTransit, a une file d'attente active pour lui-même. Les messages seront stockés là.

2. Je pense que c'est un "ça dépend" ... MassTransit supporte d'autres MQ que MSMQ mais est vraiment construit autour de MSMQ. Nous n'avons aucun support technique pour des choses telles que le basculement de MSMQ. Cependant, tout continuera à fonctionner sans faute si le service d'abonnement (c'est-à-dire le bus) échoue - les services savent déjà à qui s'adresser. C'est seulement quand un changement dans un consommateur (s'abonner ou se désinscrire) où cela devient un problème. Pour moi, c'est un événement qui n'arrive presque jamais. Avec MassTransit, nous utilisons la base de données pour stocker les états d'abonnement mais tous les messages sont stockés dans MSMQ.

Si vous souhaitez plus de détails dans l'une de ces réponses ou avez des questions supplémentaires au sujet de MT, vous pouvez nous rejoindre sur la liste de diffusion: http://groups.google.com/group/masstransit-discuss.

De plus, Udi ou sa communauté seraient probablement heureux de répondre à des questions sur la liste NServiceBus ainsi: http://tech.groups.yahoo.com/group/nservicebus/

Answer 2

Whe mettre en œuvre ce type d'architecture, vous devriez regarder à appliquer les principes de CQRS - requêtes (est-ce user/pwd combo valide) ne devrait pas être fait via le bus; Les commandes (changement pwd, oublié pwd) sont envoyées via le bus, non publiées en tant qu'événements. En interne, vous utiliserez probablement des événements pour conserver la synchronisation des côtés de la commande et de la requête, mais cela n'implique pas le client.

Les requêtes peuvent être effectuées en utilisant ado.net simple par rapport aux esclaves en lecture répliquée de votre base de données - ce qu'on appelle le modèle de vue persistante dans CQRS. Si vous le souhaitez, vous pouvez aussi mettre en place un simple WCF. Lors de l'utilisation de MSMQ, tous les messages sont transmis via le mode de stockage différé et de retransmission (forward-and-forward) lors de l'utilisation de MSMQ. Cela signifie qu'ils sont d'abord stockés sur le client avant d'être remis au serveur, donc si le serveur est en panne, les messages sont placés sur le client en attente. Pour la tolérance de panne, vous voudrez que vos messages soient récupérables (écrits sur le disque) - c'est la valeur par défaut dans NServiceBus mais pas la valeur par défaut de MSMQ standard (ne sait pas sur MassTransit). Vous n'avez pas besoin de la base de données pour cela.

Dans NServiceBus, le bus n'est pas installé sur une machine distincte, vous n'avez donc pas besoin de gérer sa disponibilité indépendamment du reste du système. Ce n'est que lorsque vous envisagez d'étendre votre traitement de commande à plusieurs nœuds que vous pouvez envisager d'utiliser l'équilibreur de charge basé sur message dans NServiceBus (appelé le distributeur) qui, pour une haute disponibilité, doit être installé sur un cluster ou un matériel tolérant aux pannes.