Exchanges
Les exchanges sont les points d'entrée pour une Producteur de messages voulant envoyer un Message dans le système.
Dans l'architecture Gadz.org, on distingue 4 types d'exchanges :
- L'exchange d'évenement
- L'exchange de log
- Les exchanges de requêtes
- Les exchanges de réponses
L'exchange d'événement
Il n'y a qu'un seul exchange d’événement. C'est un exchange durable de type topic ayant pour nom agoram_event_exchange
Cet exchange reçoit l'ensemble des événements ayant lieu dans le système. Les services se s’inscrivent aux topics dont il souhaitent recevoir les notifications.
La manière dont le message est ensuite traité et la topologie en aval est définie par le service consommateur.
L'exchange de logs
Il n'y a qu'un seul exchange de log. C'est un exchange durable de type topic ayant pour nom log
Il a pour vocation à être inscrit à chacun des autres exchanges d'entrée sur le topic *. Cette inscription est à la charge du service responsable de l'exchanges d'entrée
Chacun des loggers peut ensuite s'inscrire à l'exchange de log, en spécifiant ou non une clé de routage pour n'écouter qu'une partie du traffic.
Le logger principal est abonné à l'exchange de log via la clé de routage *
Les exchanges de requêtes
Les exchanges de requêtes sont des exchanges créés par les services afin de recevoir des requêtes.
Un exchange de requêtes DOIT être de types topic.
Un exchange de requêtes DOIT être durable.
Un exchange de requêtes DOIT avoir un nom du type request.[identifiant_du_service]
Un service DOIT ne presenter qu'un seul exchange de requêtes.
Un exchange de requêtes DOIT abonner l'exchange de logs au topic *
La topologie en aval de l'exchange de requêtes est définie par le service recevant les requêtes.
Les exchanges de réponses
Les exchanges de réponses sont des exchanges créé par les services afin de recevoir les réponses à leurs requêtes.
Un exchange de réponses DOIT être de types topic.
Un exchange de réponses DOIT être durable
Un service DOIT ne presenter qu'un seul exchange de reponses.
Un exchange de réponses DOIT avoir un nom du type reply.[identifiant_du_service]
Un exchange de réponses DOIT abonner l'exchange de logs au topic *
La topologie en aval de l'exchange de requêtes est définie par le service ayant émis la requêtes
Service
Un service est un acteur de la SOA Gadz.org. Il vise a permettre le partage de fonctionnalités entre plusieurs applications et fournir une abstraction permettant de séparer la fonction métier des choix techniques (Choix de logiciel, de prestataire, etc.)
Un service peut être Producteur, Consommateur ou les deux.
Les services offre une abstraction permettant de définir des interfaces standards et un ensemble de règles de fonctionnement.
Exemples de topologies de services
Émetteur de message
Il s'agit du service le plus simple, il se contente d'émettre des événements ou des requêtes sans recevoir aucun message
Consommateur d’événement simple
Ce service consomme des évenements et logs éventuellement leur traitement.
La gestion des erreurs et des tentatives successives n'est pas gérée dans RabbitMQ.
Service multi instance avec gestion des Softfails
Ce service permet d'avoir plusieurs instances simultanées (pour augmenter la charge admissible) : service_cons1 avec service_prod1, service_cons2 avec service_prod2
En cas de soft fail, le message est envoyé dans service_delayed_in_x . Il est alors envoyé dans l'exchange de logs et dans une queue de stockage correspondant à la routing key d'entrée (par exemple request.service.action1 ).
Cette queue de stockage est configurée avec un TTL (durée de vie des message) et n'a pas de consommateur. Le message ne peut donc pas sortir de la queue avant son expiration. Le dead-letter-exchange de la queue a pour valeur service_delayed_out_x, un exchange fanout auquel la service queue est abonnée. Le message est ainsi réinjecté dans la queue principale après le TTL