Je concevons actuellement une application que je souhaiterai finalement passer à Windows Azure. À court terme, cependant, il fonctionnera sur un serveur que je vais me héberger.
L'application implique un certain nombre d'applications Web distinctes - certaines d'entre elles sont essentiellement des services de la WCF qui reçoivent des données et certains sont des sites destinés aux utilisateurs de gérer les données. De plus, un service de travailleurs doit être exécuté dans l'arrière-plan qui traitera des données de différentes manières.
Je tiens très envie d'utiliser une architecture découplée pour cela. Idéalement, je veux que les composants (c'est-à-dire des applications Web et du service de travail) de connaître le moins possible les uns des autres. Il semble que l'utilisation d'une file d'attente de messages sera la meilleure solution ici - les applications Web peuvent en faire des messages avec des unités de travail dans la file d'attente et le service des travailleurs peut les choisir et les traiter au besoin.
Cependant, je veux élaborer un bon ensemble de technologies pour ce faire, gardant à l'esprit que je vais finalement passer à Azure et que je veux minimiser la quantité de re-ok, je devrai faire quand je migrerai au nuage. Azure a une composante de file d'attente intégrée qui semble idéale pour mes besoins. Ce que j'aimerais faire, c'est créer quelque chose moi-même qui imitera cela aussi étroitement que possible.
On dirait qu'il y a plusieurs options (j'utilise .NET sur Windows, avec une arrière-arrière SQL Server 2005) - celles que j'ai trouvées jusqu'à présent sont:
Je me demandais si quelqu'un a des suggestions pour cela - ou si quelqu'un a fait quelque chose de similaire et que des conseils sur des choses à faire / à éviter. Je me rends compte que chaque situation est différente, mais dans ce cas, je pense que mes exigences en file d'attente sont assez génériques, j'aimerais donc entendre les pensées de quelqu'un d'autre sur la meilleure façon de le faire.
Merci d'avance,
Jean
3 Réponses :
Si vous avez une azur à l'esprit, vous devriez peut-être commencer tout droit sur Azure, car les API et les semnatics sont nettement différents entre les files d'attente Azure et l'une quelconque de MSMQ ou SSB.
Une comparaison rapide de 3048 mètres de MSMQ vs SSB (je quitterai une table de la natation personnalisée en dehors de la comparaison car elle dépend vraiment de la manière dont vous l'appliquez ...)
En plus, j'ajouterais que SSB et MSMQ diffèrent de manière significative au niveau de la primitive qu'ils offrent: la primitive SSB est une conversation , tandis que MSMQ Primitive est un message . Pensez TCP contre la sémantique UDP.
Merci! C'est très utile. Il semble que MSMQ soit une meilleure option à nos besoins - je suppose qu'une grande étape suivante sera de comparer MSMQ à Azure Queuing. Je sais, par exemple, que Azure ne garantit pas les messages sera livré dans l'ordre (ou une seule fois qu'une seule fois), donc je devrai vérifier cela contre MSMQ pour voir quel est le comportement correspondant. Mais merci encore pour cela - c'est une comparaison très informative.
Choisissez une file d'attente de la queue qui fonctionne pour vous ou convient mieux à votre environnement. @Remus a donné une grande comparaison entre MSMQ et SSB. MSMQ va être plus facile à mettre en œuvre, mais a des limitations notables, tandis que SSB va se sentir très lourd comme c'est à l'autre extrémité du spectre.
a votre chemin strong>
Pour minimiser la reprise de vos applications, Abstract Les files d'attente ont accès à une interface, puis fournissent une mise en œuvre du transport de la file d'attente, vous décidez finalement de partir. Quand il est temps de passer à Azure ou à un autre transport de la file d'attente, vous offrez simplement une nouvelle implémentation de votre interface. P> Vous devez contrôler la sémantique de la manière dont vous souhaitez interagir avec la file d'attente pour donner une utilisable cohérente API de vos applications. P> Une idée approximative peut être: p> interface IQueuedTransport
{
void SendMessage(XmlDocument);
XmlDocument ReceiveMessage();
}
public class MSMQTransport : IQueuedTransport {}
public class AzureQueueTransport : IQueuedTransport {}
Utilisez win32 MailSlots . Ils seront fiables sur un seul serveur, sont faciles à mettre en œuvre et ne nécessitent aucun logiciel supplémentaire.