Communiquer via une file d’attente de message [1/3]

boite-au-lettre-2Aujourd’hui la construction d’un service ou site web se fait généralement via l’appel de services et requêtes HTTP. Du coup la modélisation d’une architecture est souvent basée autour de ce protocole et toute l’architecture est basée sur ce principe.

Pourtant il existe d’autres techniques qui permettent à des systèmes de communiquer entre eux. Je vous propose donc via ces quelques pages de vous faire (re)-découvrir le principe de la communication par message asynchrone. La grande différence entre les messages asynchrones et les requêtes synchrones tient au fait que l’émetteur d’une requête va attendre sa réponse et il ne va pas interrompre la communication tant que le traitement ne sera pas terminé (get http par exemple).

Alors qu’avec un message, le récepteur va confirmer le bon enregistrement de la demande et la communication peut-être interrompue même si le traitement demandé dans le message n’est pas terminé.

Prenons l’exemple de l’inscription d’un utilisateur sur un site web, à la fin de l’inscription nous souhaitons lui envoyer un e-mail de confirmation/vérification :

Dans la plupart des architectures c’est la dernière page web qui sera en charge d’émettre un email vers l’utilisateur. Du coup pendant l’envoi de cet email le client comme le serveur vont rester connectés et mobiliser un thread coté serveur pendant toute la durée de l’opération. Sans compter qu’il faudra gérer le fait que la communication peut s’interrompre ou que l’internaute rafraichir sa page ou faire un back…

Avec une architecture par message, à la fin de l’enregistrement la page envoi une demande d’envoi d’email au système de gestion de message (une base de données par exemple) et libère la connexion rapidement. De l’autre coté un processus sera en charge de réceptionner les messages (à son rythme) pour envoyer les mails.


queue

Avantage de cette solution, une forte charge au niveau des inscriptions ne perturbera pas le service car l’envoi des emails ne chargera pas le serveur web. De la même manière il sera simple d’ajouter des serveurs web indépendamment des serveurs d’envoi d’email et la gestion des logs et l’exploitation de manière générale sera également simplifiée.

Pour cette tâche, ce découpage fonctionnel est donc tout à fait intéressant et le seul inconvénient concerne le temps de livraison du mail qui n’est plus instantané, mais qui par contre est désormais garantit. Il sera peut être traité avec un peu plus de temps mais via un système fiable et robuste lors des montées en  charge.

Je termine ici ce premier exemple, je reviendrais sur ce sujet prochainement en traitant deux autres aspects de ce problème  :

  • La gestion des traitements long et/ou couteux en ressources.
  • Le partage de la charge en cas de forte influence.

N’hésitez à vous inscrire au flux RSS si vous souhaitez être informé de la publication de ces deux autres articles.

Sur le même thème :

One Response to “Communiquer via une file d’attente de message [1/3]”

  1. [...] vous avoir présenté brièvement les avantages de la communication par message dans ce premier post. Je vous propose de continuer cette série mais en s’intéressant cette fois aux tâches [...]

Leave a Reply