L’architecture pilotée par les événements passe d’un modèle limité à quelques services à un vaste réseau de producteurs, de consommateurs et de canaux de messagerie. À ce stade, le problème principal n’est plus l’envoi du message, mais de savoir ce qui est envoyé, qui en est propriétaire, qui en dépend, et comment modifier son schéma ou recréer son infrastructure sans provoquer d’incidents en production. C’est le sujet de la session d’Ian Cooper consacrée à la gestion des interfaces de programmation asynchrones à grande échelle, en s’appuyant sur des pratiques d’ingénierie concrètes chez Just Eat Takeaway.
Pourquoi la situation se complexifie-t-elle avec la croissance ?
Dans les petites organisations, les membres des équipes peuvent connaître les services qui publient et consomment les événements, et les sujets ou les canaux peuvent être créés via le framework de messagerie ou au moyen d’une demande directe adressée à l’équipe plateforme. Mais cette approche perd son efficacité lorsque le nombre d’équipes et de services augmente. Il peut devenir difficile de savoir qui possède un point de terminaison donné, quel contrat décrit le message, ou si des consommateurs inconnus existent au sein des équipes chargées des données et de l’analytique.
Le risque apparaît lorsqu’une équipe modifie le schéma d’un message après avoir consulté uniquement les consommateurs connus, alors que d’autres équipes dépendent du message sans faire partie du cercle de communication. La suppression d’un sujet considéré comme inutilisé peut entraîner la perte d’un flux critique, en particulier lorsqu’il n’existe aucun moyen fiable d’en connaître le propriétaire ou de recréer l’infrastructure nécessaire autrement qu’en redéployant de grandes parties du système.
Trois axes pour gérer les interfaces événementielles
Cooper divise le problème en découverte, gouvernance et provisionnement. Cela commence par la compréhension de ce qui doit être décrit dans tout point de terminaison, au moyen de ce qu’il appelle les « ABC » : l’adresse, la liaison et le contrat. L’adresse indique où circulent les messages, la liaison décrit le protocole, le transport et l’encodage, tandis que le contrat définit les en-têtes et les données transportées par le message.
Dans ce contexte, AsyncAPI fournit un équivalent aux mécanismes de documentation des interfaces HTTP tels qu’OpenAPI, avec une modélisation des serveurs, des canaux, des messages, des opérations et des liaisons propres au protocole. Il prend en charge la description des messages à l’aide de JSON Schema, d’Avro et de Protobuf, et permet également de réutiliser les définitions plutôt que de les répéter dans plusieurs fichiers. Mais Cooper souligne que le fait de placer des centaines de fichiers AsyncAPI dans un même dépôt ne résout pas à lui seul le problème de la découverte ; la recherche textuelle reste limitée lorsque l’inventaire des événements prend de l’ampleur.
Les organisations peuvent donc avoir besoin d’outils de catalogue tels qu’EventCatalog ou Marmot, ou d’un registre ouvert tel que xRegistry, afin d’afficher les flux de messages et leurs relations, et de relier les schémas aux producteurs et aux consommateurs. Ces outils diffèrent par leur niveau de visualisation et leurs interfaces prêtes à l’emploi, mais leur fonction commune consiste à faire passer la découverte d’une question posée dans Slack ou d’une recherche effectuée dans des dépôts dispersés à un service interrogeable.
Le rôle de CloudEvents dans l’unification des métadonnées
CloudEvents prend en charge un autre aspect du problème en proposant un ensemble unifié de métadonnées telles que l’identifiant, la source, la version et le type, ainsi que des champs facultatifs pour le type de contenu des données, le sujet, l’heure et un lien vers le schéma. Le type d’événement peut être utilisé pour acheminer le message ou sélectionner un mécanisme de désérialisation lorsque plusieurs types partagent un même canal.
La session explique que les modes binary et structured de CloudEvents sont liés à la capacité du protocole de transport à transporter des en-têtes, et non au fait que le message soit « binaire » ou « structuré » au sens habituel. Ce détail est important dans des systèmes tels que SNS, où un nombre limité d’attributs du message peut être consommé rapidement si toutes les données CloudEvents sont placées dans les en-têtes, ce qui fait de leur encapsulation dans le corps une option pratique dans certains scénarios.
La gouvernance ne se limite pas à la documentation
La documentation du contrat définit la nature du message pour les consommateurs, mais elle n’empêche pas le producteur de publier une modification qui rompt leurs dépendances. L’approche présentée recommande donc d’utiliser un registre de schémas qui applique des règles de compatibilité lors de la mise à jour des contrats, et qui rejette les messages ou les modifications ne respectant pas les règles approuvées.
Les pratiques sûres consistent généralement à ajouter les champs en les rendant facultatifs, à reporter la suppression des champs jusqu’à ce que tous les consommateurs aient cessé de les utiliser, et à traiter le renommage comme une modification composée d’une suppression et d’un ajout. La modification du type d’un champ est généralement considérée comme une modification rompant la compatibilité. Elle peut être effectuée en ajoutant un nouveau champ du type requis, puis en y faisant migrer les consommateurs, avant de supprimer l’ancien champ.
Qu’est-ce qui change concrètement ?
Le message essentiel pour le lecteur technique est que la gestion des événements à grande échelle nécessite une chaîne interconnectée, et non un outil isolé : AsyncAPI pour décrire les interfaces, CloudEvents pour unifier les métadonnées, un catalogue ou un registre pour faciliter la découverte, un registre de schémas pour imposer la compatibilité, ainsi que l’automatisation pour provisionner l’infrastructure et surveiller sa dérive. Sans ces couches, l’architecture événementielle peut se transformer en un réseau de dépendances invisibles.
Des contraintes pratiques subsistent : les normes ne fournissent pas à elles seules une connaissance complète des consommateurs, et les outils diffèrent quant à leur prise en charge des interfaces, de la visualisation et de l’intégration avec les brokers. La mise en œuvre de cette approche exige donc de définir clairement la propriété des contrats et des canaux, de relier les modifications aux processus CI/CD et de conserver un chemin de restauration capable de recréer les ressources, plutôt que de dépendre de connaissances individuelles ou d’une documentation obsolète.