Pourquoi utiliser AMQP / ZeroMQ / RabbitMQ
plutôt que d'écrire votre propre bibliothèque.
Nous travaillons sur un projet ici qui sera un pool de serveurs auto-divisant, si une section devient trop lourde, le gestionnaire la divisera et la mettra sur une autre machine en tant que processus séparé. Il alerterait également tous les clients connectés que cela affecte de se connecter au nouveau serveur.
Je suis curieux d'utiliser ZeroMQ pour la communication inter-serveurs et inter-processus. Mon partenaire préférerait rouler le sien. Je me tourne vers la communauté pour répondre à cette question.
Je suis moi-même un programmeur assez novice et je viens d'apprendre les files d'attente de messagerie. Comme je l'ai googlé et lu, il semble que tout le monde utilise des files d'attente de messagerie pour toutes sortes de choses, mais pourquoi? Qu'est-ce qui les rend meilleurs que d'écrire votre propre bibliothèque? Pourquoi sont-ils si communs et pourquoi y en a-t-il autant?
qu'est-ce qui les rend meilleurs que d'écrire votre propre bibliothèque?
Lors du déploiement de la première version de votre application, probablement rien: vos besoins sont bien définis et vous développerez un système de messagerie adapté à vos besoins: petite liste de fonctionnalités, petit code source etc.
Ces outils sont très utiles après la première version, lorsque vous devez réellement étendre votre application et y ajouter plus de fonctionnalités. Permettez-moi de vous donner quelques cas d'utilisation:
- votre application devra parler à une grosse machine endienne (sparc/powerpc) à partir d'une petite machine endienne (x86, intel/AMD). Votre système de messagerie avait une hypothèse de commande endian: allez le réparer
- vous avez conçu votre application pour qu'elle ne soit pas un protocole/système de messagerie binaire et maintenant elle est très lente car vous passez la plupart de votre temps à l'analyser (le nombre de messages a augmenté et l'analyse est devenue un goulot d'étranglement): adaptez-la pour qu'elle puisse transporter du binaire/encodage fixe
au début, vous aviez 3 machines dans un lan, aucun retard notable, tout arrive à chaque machine. votre client/patron/boss-diable-aux cheveux pointus apparaît et vous dit que vous installerez l'application sur WAN vous ne gérez pas - puis vous commencez à avoir des échecs de connexion, une mauvaise latence, etc. .vous devez stocker le message et réessayer de l'envoyer plus tard: revenez au code et branchez ce truc (et profitez-en)
les messages envoyés doivent avoir des réponses, mais pas tous: vous envoyez certains paramètres et attendez une feuille de calcul en conséquence au lieu de simplement envoyer et accuser réception, revenez au code et branchez ce truc (et profitez-en).
- certains messages sont critiques et la réception/l'envoi nécessite une sauvegarde/persistance/appropriée. Pourquoi demandes-tu ? fins d'audit
Et bien d'autres cas d'utilisation que j'ai oubliés ...
Vous pouvez l'implémenter vous-même, mais ne passez pas beaucoup de temps à le faire: vous le remplacerez probablement plus tard de toute façon.
C'est un peu comme demander: pourquoi utiliser une base de données alors que vous pouvez écrire la vôtre?
La réponse est que l'utilisation d'un outil qui existe depuis un certain temps et qui est bien compris dans de nombreux cas d'utilisation différents, est de plus en plus rentable au fil du temps et à mesure que vos besoins évoluent. Cela est particulièrement vrai si plusieurs développeurs sont impliqués dans un projet. Voulez-vous devenir membre du personnel de support pour un système de mise en file d'attente si vous passez à un nouveau projet? L'utilisation d'un outil empêche cela de se produire. Cela devient le problème de quelqu'un d'autre.
Exemple concret: persistance. Écrire un outil pour stocker un message sur le disque est facile. Il est difficile d'écrire une persistance qui évolue et fonctionne bien et de manière stable, dans de nombreux cas d'utilisation différents, et qui est gérable et bon marché à prendre en charge. Si vous voulez voir quelqu'un se plaindre de la difficulté, regardez ceci: http://www.lshift.net/blog/2009/12/07/rabbitmq-at-the-skills-matter-functional -programmation-échange
Quoi qu'il en soit, j'espère que cela vous aidera. Par tous les moyens, écrivez votre propre outil. Beaucoup de gens l'ont fait. Tout ce qui résout votre problème, c'est bien.
J'envisage d'utiliser ZeroMQ moi-même - c'est pourquoi je suis tombé sur cette question.
Supposons pour le moment que vous avez la possibilité de mettre en œuvre un système de mise en file d'attente des messages qui répond à toutes vos exigences. Pourquoi adopteriez-vous ZeroMQ (ou une autre bibliothèque tierce) plutôt que l'approche roll-your-own? Simple - coût.
Supposons un instant que ZeroMQ réponde déjà à toutes vos exigences. Tout ce qui doit être fait est de l'intégrer dans votre build, de lire du doco et de commencer à l'utiliser. Cela doit être beaucoup moins d'effort que de rouler le vôtre. De plus, le fardeau de la maintenance a été transféré à une autre entreprise. Étant donné que ZeroMQ est gratuit, c'est comme si vous veniez de développer votre équipe de développement pour inclure (une partie de) l'équipe ZeroMQ.
Si vous dirigiez une entreprise de développement de logiciels, je pense que vous équilibreriez le coût/risque de l'utilisation de bibliothèques tierces par rapport à la vôtre, et dans ce cas, l'utilisation de ZeroMQ gagnerait haut la main.
Peut-être que vous (ou plutôt votre partenaire) souffrez, comme tant de développeurs, du syndrome "Not Invented Here" ? Si oui, ajustez votre attitude et réévaluez l'utilisation de ZeroMQ. Personnellement, je préfère de loin les avantages de l'attitude Proudly Found Elsewhere. J'espère pouvoir être fier de trouver ZeroMQ ... le temps nous le dira.
EDIT: Je suis tombé sur ce vidéo des développeurs ZeroMQ qui parle pourquoi vous devriez utiliser ZeroMQ.
qu'est-ce qui les rend meilleurs que d'écrire votre propre bibliothèque?
Les systèmes de mise en file d'attente des messages sont transactionnels, ce qui est conceptuellement facile à utiliser en tant que client, mais difficile à obtenir correctement en tant qu'implémenteur, en particulier compte tenu des files d'attente persistantes. Vous pourriez penser que vous pouvez vous débrouiller avec l'écriture d'une bibliothèque de messagerie rapide, mais sans transactions et persistance, vous n'auriez pas tous les avantages d'un système de messagerie.
La persistance dans ce contexte signifie que le middleware de messagerie conserve les messages non traités dans un stockage permanent (sur disque) en cas de panne du serveur; après un redémarrage, les messages peuvent être traités et aucune retransmission n'est nécessaire (l'expéditeur ne sait même pas qu'il y a eu un problème). Transactionnel signifie que vous pouvez lire des messages de différentes files d'attente et écrire des messages dans différentes files d'attente de manière transactionnelle, ce qui signifie que toutes les lectures et écritures réussissent ou (si une ou plusieurs échouent) aucune ne réussit. Ce n'est pas vraiment très différent de la transactionnalité connue de l'interfaçage avec les bases de données et a les mêmes avantages (cela simplifie la gestion des erreurs; sans transactions, vous devez vous assurer que chaque lecture/écriture réussit, et si une ou plusieurs échouent, vous avez pour annuler les changements qui ont réussi).
Avant d'écrire votre propre bibliothèque, lisez le Guide 0MQ ici: http://zguide.zeromq.org/page:all
Il y a de fortes chances que vous décidiez soit d'installer RabbitMQ, soit de créer votre bibliothèque au dessus de ZeroMQ puisqu'ils ont déjà fait toutes les parties dures.
Si vous avez un peu de temps, essayez et déployez votre propre implémentation! Les enseignements de cet exercice vous convaincront de la sagesse d'utiliser une bibliothèque déjà testée.