Message Queue vs services Web? [fermé]

258

Dans quelles conditions préférerait-on que les applications parlent via une file d'attente de messages plutôt que via des services Web (je veux juste dire XML ou JSON ou YAML ou quoi que ce soit sur HTTP ici, pas un type particulier)?

Je dois parler entre deux applications sur un réseau local. L'une sera une application Web et devra demander des commandes sur une autre application (exécutée sur un matériel différent). Les demandes sont des choses comme la création d'utilisateurs, le déplacement de fichiers et la création de répertoires. Dans quelles conditions préférerais-je les services Web XML (ou TCP simple ou autre) à l'aide d'une file d'attente de messages?

L'application Web est Ruby on Rails, mais je pense que la question est plus large que cela.

web-services message-queue

— Dan Rosenstark
source

315

Lorsque vous utilisez un service Web, vous avez un client et un serveur:

Si le serveur tombe en panne, le client doit prendre la responsabilité de gérer l'erreur.
Lorsque le serveur fonctionne à nouveau, le client est responsable de le renvoyer.
Si le serveur répond à l'appel et que le client échoue, l'opération est perdue.
Vous n'êtes pas en désaccord, c'est-à-dire: si des millions de clients appellent un service Web sur un serveur en une seconde, votre serveur va probablement tomber en panne.
Vous pouvez vous attendre à une réponse immédiate du serveur, mais vous pouvez également gérer les appels asynchrones.

Lorsque vous utilisez une file d'attente de messages comme RabbitMQ, Beanstalkd, ActiveMQ, IBM MQ Series, Tuxedo, vous vous attendez à des résultats différents et plus tolérants aux pannes:

Si le serveur tombe en panne, la file d'attente conserve le message (éventuellement, même en cas d'arrêt de la machine).
Lorsque le serveur fonctionne à nouveau, il reçoit le message en attente.
Si le serveur donne une réponse à l'appel et que le client échoue, si le client n'a pas accusé réception de la réponse, le message est conservé.
Vous avez un conflit, vous pouvez décider du nombre de demandes traitées par le serveur (appelez-le à la place).
Vous ne vous attendez pas à une réponse synchrone immédiate, mais vous pouvez implémenter / simuler des appels synchrones.

Message Queues a beaucoup plus de fonctionnalités, mais il s'agit d'une règle générale pour décider si vous souhaitez gérer vous-même les conditions d'erreur ou les laisser dans la file d'attente des messages.

— sw.
source

1

Si la liaison SOAP / JMS est utilisée, on obtient également un couplage lâche aux services Web.

— koppor

Pour plusieurs microservices côté serveur, qui devrait être le service Web ou la file d'attente préféré?

— shivendra pratap singh

Cher @sw. , puis-je savoir si cela signifie que nous pouvons placer MQ devant les sites Web normaux? Disons que j'ai un site Web Wordpress (pile LAMP). Puis-je utiliser MQ en face d'Apache pour que les demandes viennent 1 après 1, au lieu de toutes arriver en même temps. Dans ce cas, les clients (navigateurs) sont connectés à MQ au lieu d'Apache, ai-je raison? Mais alors, les navigateurs maintiennent-ils la connexion HTTP ouverte et attendent-ils qu'Apache réponde? Veuillez m'aider à comprendre un peu à ce sujet. Appréciez votre gentillesse.

— 夏期劇場

@ 夏期劇場 quel est votre cas d'utilisation? Qu'essayez-vous de faire pour que l'utilisateur final profite de ce navigateur?

— sw.

Ces préoccupations concernant les configurations client / serveur ne sont-elles pas toujours des préoccupations entre la file d'attente et le serveur et entre le client et la file d'attente? Il semble que le paradigme client / serveur existe toujours et maintenant à deux endroits.

— imagineerThat

75

Il y a eu pas mal de recherches récentes sur la manière dont les appels HTTP REST pourraient remplacer le concept de file d'attente de messages.

Si vous introduisez le concept d'un processus et d'une tâche en tant que ressource, le besoin d'une couche de messagerie intermédiaire commence à s'évaporer.

Ex:

POST /task/name
    - Returns a 202 accepted status immediately
    - Returns a resource url for the created task: /task/name/X
    - Returns a resource url for the started process: /process/Y

GET /process/Y
    - Returns status of ongoing process

Une tâche peut avoir plusieurs étapes pour l'initialisation, et un processus peut retourner l'état lorsqu'il est interrogé ou POST vers une URL de rappel lorsqu'il est terminé.

C'est très simple et devient assez puissant lorsque vous réalisez que vous pouvez désormais vous abonner à un flux rss / atom de tous les processus et tâches en cours d'exécution sans aucune couche intermédiaire. Tout système de mise en file d'attente nécessitera de toute façon une sorte de frontal Web, et ce concept l'a intégré sans autre couche de code personnalisé.

Vos ressources existent jusqu'à ce que vous les supprimiez, ce qui signifie que vous pouvez afficher les informations historiques longtemps après la fin du processus et de la tâche.

Vous avez intégré la découverte de services, même pour une tâche comportant plusieurs étapes, sans protocoles supplémentaires compliqués.

GET /task/name
    - returns form with required fields

POST (URL provided form's "action" attribute)

Votre découverte de service est un formulaire HTML - un format universel et lisible par l'homme.

L'ensemble du flux peut être utilisé par programme ou par un humain, à l'aide d'outils universellement acceptés. C'est un client, et donc RESTful. Chaque outil créé pour le Web peut piloter vos processus métier. Vous disposez toujours de canaux de messages alternatifs en POSTANT de manière asynchrone sur un tableau distinct de serveurs de journaux.

Après y avoir réfléchi pendant un certain temps, vous vous asseyez et commencez à réaliser que REST peut simplement éliminer le besoin d'une file d'attente de messagerie et d'un ESB.

http://www.infoq.com/presentations/BPM-with-REST

— tempire
source

11

@tempire qu'en est-il de la tolérance aux pannes, etc.? REST est bien, mais le développeur finit par construire lui-même le middleware

— Dan Rosenstark

10

@Yar La plupart des questions sur «qu'en est-il» peuvent être reformulées, «comment est-ce géré sur le Web?». La tolérance aux pannes peut être gérée via des équilibreurs de charge, ou même la manipulation des enregistrements DNS. Il y a quelques autres problèmes à résoudre, comme l'évolutivité horizontale - le Web ne gère pas bien par nature (attaques ddos, par exemple).

— tempire

8

@tempire, il n'y a pas de livraison garantie sur le Web, non? Je clique sur soumettre et prie pour que le message arrive à destination. Avec un MQ, je sais que si j'arrive au MQ, j'ai fini. Il gérera l'envoi du message à la destination.

— Dan Rosenstark

10

@Yar, pensez à ce que signifie «livraison garantie». C'est seulement aussi «garanti» que le temps de disponibilité de la file d'attente de messages. Remplacez la file d'attente de messages par un ou des serveurs REST qui traitent les tâches et les processus comme des ressources, et vous avez la même «garantie» que toute autre chose. Essentiellement, vous avez toujours une file d'attente de messages, mais dans un format accessible standard Web, qui peut être surveillé à l'aide de n'importe quel outil Web.

— tempire

16

@Yar - Je ne pense pas que beaucoup de gens comprennent la définition du problème que MQ essaie de résoudre suffisamment pour même envisager de telles choses. Ils comprennent le MQ, mais c'est différent de comprendre l'espace du problème. C'est un problème très répandu, car je pense que la plupart des programmeurs et gestionnaires du monde ont été formés pour connecter des éléments plutôt que des solutions d'ingénierie.

— tempire

32

Les files d'attente de messages sont idéales pour les demandes dont le traitement peut prendre du temps. Les demandes sont mises en file d'attente et peuvent être traitées hors ligne sans bloquer le client. Si le client doit être informé de l'achèvement, vous pouvez lui fournir un moyen de vérifier périodiquement l'état de la demande.

Les files d'attente de messages vous permettent également de mieux évoluer dans le temps. Il améliore votre capacité à gérer des salves d'activité intense, car le traitement réel peut être réparti dans le temps.

Notez que les files d'attente de messages et les services Web sont des concepts orthogonaux, c'est-à-dire qu'ils ne s'excluent pas mutuellement. Par exemple, vous pouvez avoir un service Web basé sur XML qui sert d'interface à une file d'attente de messages. Je pense que la distinction que vous recherchez est Message Queues versus Request / Response, cette dernière est lorsque la demande est traitée de manière synchrone.

— DSO
source

3

Oui, je pensais juste à cela: ce n'est pas s'ils bloquent ou non. Il s'agit de savoir s'ils nécessitent un temps de traitement plus long et / ou imprévisible ... En ce qui concerne leur orthogonalité, il est également vrai que les services Web peuvent être utilisés pour de longues demandes (dépôt et ramassage séparés, bien sûr). Pourtant, si vous avez le luxe d'une file d'attente de messages, ce pourrait être une bonne idée.

— Dan Rosenstark

Ma nouvelle question est, et si le processus était synchrone, mais asynchrone à l'expiration? Alors peut-être que les services Web conviendraient mieux.

— Dan Rosenstark

27

Les files d'attente de messages sont asynchrones et peuvent réessayer plusieurs fois si la livraison échoue. Utilisez une file d'attente de messages si le demandeur n'a pas besoin d'attendre une réponse.

L'expression «services Web» me fait penser aux appels synchrones vers un composant distribué via HTTP. Utilisez les services Web si le demandeur a besoin d'une réponse.

— duffymo
source

1

Merci pour ça, ouais "livraison garantie", je vais devoir me demander si c'est important. Je veux dire, la synchronisation vs async est une sorte de goût, dans un certain sens. Bien qu'il y ait clairement des boîtiers en noir et blanc, il y a aussi un énorme milieu gris.

— Dan Rosenstark

22

Je pense qu'en général, vous voudriez un service Web pour une tâche de blocage (ces tâches doivent être terminées avant d'exécuter plus de code), et une file d'attente de messages pour une tâche non bloquante (cela pourrait prendre un certain temps, mais nous ne pas besoin de l'attendre).

— Tobias Cohen
source

Les services Web proposent également des méthodes à sens unique ( @Oneway ). Pour recevoir la réponse, un service web doit être proposé par le client.

— koppor