Nous contacter
C’est l’histoire d’un message broker rempli de files de messages. Mais comment s’y retrouver parmi toute cette pelote ?
Dans un contexte entreprise, l’agent de message (messages broker pour les intimes) est souvent une entité partagée entre les domaines. Plusieurs applications (voire des équipes) partagent le même broker, en utilisant des files différentes. La plupart du temps, le broker de PROD est séparé des environnements de TESTS et de BUILD pour éviter les effets de bords un peu malheureux.
Quand bien même, la grande question est : comment nommer efficacement ses files pour s’y retrouver ?
Les informations à intégrer
Voici quelques informations assez fréquentes que j’apprécie personnellement retrouver :
- L’environnement d’utilisation de la file: PROD, UAT, DEV
- L’équipe responsable de la file de messages : celle que vous allez contacter pour consommer ou pousser du message
- Le domaine de la file de messages : que contient cette file / quelle est la destination des messages
La plupart des files répondent à des usages bien précis, que cela soit un pattern d’usage ou bien une utilisation récurrente au sein de votre architecture. Dans ces cas-là, j’aime beaucoup ajouter le nom du patron en tant que suffixe.
- Retry : les messages qui ne sont pas passés et qui vont retenter leur chance
- Dead Letter Queue ( ou dlq) : le cimetière des messages en erreur, plutôt pratique pour reprendre les messages un par un quand un souci est survenu (un retry qui ne passe vraiment pas, un souci à l’exécution qui casse l’algo par exemple).
- Resiliency / buffer : les files tampons qui absorbent la charge.
- Et sûrement plein d’autres usages que vous avez chez vous ! (des files de priorités par exemple, des events business…)
Les files contiennent des messages qui respectent une structure de données bien précise. Et oui, il s’agit d’une API.
Si l’évolution de la structure de message induit une évolution cassante au niveau production ou réception, alors la version doit être différente.
C’est pour moi une information utile à préciser sur la file de message : quelle structure je respecte.
- La version des messages : dans une approche type JSON où l’ajout de champs n’est pas cassante, seule la version majeure m’intéresse. Si vous respectez une approche plus rigoureuse où l’ajout devient problématique, c’est la version complète qui me semble nécessaire.
Quelques contraintes cependant :
- Attention à la taille max des noms : ça dépend de vos outils.
- Quel séparateur choisir ? Tout pareil, ça dépend de vos outils.
Le résultat par l’exemple
Ce qui nous donne :
<environnement>.<equipe-responsable>.<domaine>.<pattern>.<version>Par exemple:
dev.team-marketing.booking.resiliency.v1Et dans le cas de tests automatisés ?
Lorsque nous réalisons des tests automatisés d’intégration, il peut être nécessaire de créer à la volée des files de messages. Dans ces cas-là, l’environnement est bien explicité (comme évoqué plus tôt), et j’aime beaucoup ajouter un UID en suffixe pour pouvoir lancer deux tests en simultanés. L’UID peut être aussi bien un UUID, qu’une concaténation d’un contexte d’exécution, d’un identifiant de test et d’un timestamp / donnée temporel par exemple.
Tel que :
e2e.team-marketing.booking.resiliency.v1.runner-1.test-13.20250127T1112Certains brokers autorisent la suppression automatique de files après une certaine période d’inactivité.
Sinon, vous pouvez vous appuyer sur la structure de nommage pour nettoyer tout ce qui n’est plus nécessaire et qui est passé au travers des mailles du filet des étapes de nettoyage.
/in/cedriccf/