Choisir entre l’utilisation de messages ou d’événements
Supposons que vous planifiez l’architecture d’une application distribuée de partage de musique. Vous voulez vous assurer que l’application sera aussi fiable et évolutive que possible, et avez l’intention d’utiliser les technologies Azure pour créer une infrastructure de communication robuste.
Avant de choisir la technologie Azure appropriée, vous devez comprendre chacune des communications échangées entre les composants de l’application. Pour chaque communication, vous pouvez choisir une technologie Azure différente.
La première chose à comprendre concernant une communication est si elle envoie des messages ou des événements. Ces connaissances vous aident à choisir le service Azure approprié à utiliser.
Stratégies de communication dans Azure (API)
Qu’est-ce qu’un message ?
Dans la terminologie des applications distribuées, les messages présentent les caractéristiques suivantes :
- Un message contient des données brutes produites par un composant et consommées par un autre composant.
- Un message contient les données proprement dites, pas une référence à celles-ci.
- Le composant expéditeur attend du composant destinataire qu’il traite le contenu du message d’une certaine manière. L’intégrité de l’ensemble du système peut dépendre du fait que l’expéditeur et le destinataire effectuent un travail spécifique.
Par exemple, supposons qu’un utilisateur charge une nouvelle chanson à l’aide de l’application mobile de partage de musique. L’application mobile doit envoyer cette chanson à l’API web s’exécutant dans Azure. Le fichier multimédia de la chanson doit être envoyé, et pas seulement une alerte indiquant qu’une chanson a été ajoutée. L’application mobile attend que l’API web stocke la nouvelle chanson dans la base de données et la mette à la disposition d’autres utilisateurs. Voici un exemple de message.
Qu’est-ce qu’un événement ?
Les événements sont plus légers que les messages et sont le plus souvent utilisés pour des communications en mode diffusion. Les composants expéditeurs de l’événement sont appelés éditeurs et les destinataires sont appelés abonnés.
Avec les événements, les composants destinataires décident des communications qui les intéressent et « s’abonnent » à ces événements. Un intermédiaire gère l’abonnement, comme Azure Event Grid ou Azure Event Hubs. Quand des publieurs envoient un événement, l’intermédiaire le route vers les abonnés intéressés. Ce modèle est ce qu’on appelle une « architecture de publication-abonnement ». Ce n’est pas la seule façon de gérer des événements, mais c’est la plus courante.
Les événements présentent les caractéristiques suivantes :
- Un événement est une notification légère qui indique que quelque chose s’est produit.
- L’événement peut être envoyé à plusieurs destinataires ou à aucun d’eux.
- Les événements sont souvent destinés à être « déployés », ou ont un grand nombre d’abonnés pour chaque éditeur.
- L’éditeur de l’événement n’attend aucune action particulière d’un composant destinataire.
- Certains événements sont des unités distinctes, sans lien avec d’autres événements.
- Certains événements font partie d’une série continue et ordonnée.
Par exemple, supposons que le chargement du fichier de musique est terminé et que la nouvelle chanson a été ajoutée à la base de données. L’API web doit informer les utilisateurs du frontend et de l’application mobile de l’existence du nouveau fichier. Les utilisateurs pouvant choisir d’écouter la nouvelle chanson, la notification initiale n’inclut pas le fichier de musique, mais avertit seulement les utilisateurs de l’existence de la chanson. L’expéditeur n’a pas d’attente spécifique quant à ce que les destinataires de l’événement vont faire en réponse à celui-ci.
Ce scénario est un exemple d’événement discret.
Comment choisir des messages ou des événements
Une même application est susceptible d’utiliser des événements dans certains buts et des messages dans d’autres. Avant de choisir, vous devez analyser l’architecture de votre application et tous ses cas d’usage pour identifier les différents objectifs pour lesquels ses composants doivent communiquer entre eux.
Les événements sont plus susceptibles d’être utilisés pour des diffusions et sont souvent éphémères. Cela signifie qu’une communication peut ne pas être traitée par un récepteur si aucun n’y est actuellement abonné. Les messages sont plus susceptibles d’être utilisés quand l’application distribuée nécessite une garantie de traitement de la communication.
Pour chaque communication, posez-vous la question suivante : le composant expéditeur attend-il que la communication soit traitée d’une manière particulière par le composant destinataire ?
Si la réponse est Oui, choisissez d’utiliser un message. Si la réponse est non, il se peut que vous puissiez utiliser des événements.
En comprenant la façon dont vos composants doivent communiquer, vous choisissez plus facilement comment vos composants communiquent. Commençons par les messages.