Tout les message sont envoyé à l'exchange (topic) principal : agoram_exchange
C'est le consommateur qui met en place la topologie adapté à son usage.
| Sommaire |
|---|
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 :
...
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
...
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]
...
Les services offre une abstraction permettant de définir des interfaces standards et un ensemble de règles de fonctionnement.
Exemple de topologie
L'exemple ci-dessous ne satisfait pas les nouvelles spécifications
https://drive.google.com/a/gadz.org/file/d/0B6ucsDu49YbqTHJUc1ZQM3ZRLTQ/view?usp=sharing
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