Messagerie asynchrone et transmission d'événement

La transmission de message est un autre modèle utilisé pour mettre en œuvre la communication entre microservices. Les services communiquent en échangeant des messages via une file d'attente. L'un des principaux avantages de ce style de communication est qu'il n'est pas nécessaire de disposer d'un service de découverte et que les services sont faiblement couplés.

Les systèmes synchrones sont étroitement couplés, ce qui signifie qu'un problème de dépendance synchrone en aval a un impact immédiat sur les appelants en amont. Les relances des appelants en amont peuvent rapidement se disperser et amplifier les problèmes.

En fonction d'exigences spécifiques, telles que les protocoles, AWS propose différents services facilitant la mise en œuvre de ce modèle. Une implémentation possible met en œuvre une combinaison d'Amazon Simple Queue Service (Amazon SQS) ou d'Amazon Simple Notification Service (Amazon SNS).

Les deux services fonctionnent en étroite collaboration : Amazon SNS permet aux applications d'envoyer des messages à plusieurs abonnés via un mécanisme Push. L'utilisation en conjonction d'Amazon SNS et d'Amazon SQS permet de remettre un message à plusieurs consommateurs. La figure suivante illustre l'intégration d'Amazon SNS et d'Amazon SQS.

Modèle de bus de messagerie sur AWS

Lorsque vous abonnez une file d'attente Amazon SQS à une rubrique SNS, vous pouvez publier un message dans la rubrique et Amazon SNS envoie un message à la file d'attente Amazon SQS associée. Le message contient l'objet et le message publié dans la rubrique, ainsi que les métadonnées au format JSON.

Amazon EventBridge est une autre option qui permet de créer des architectures pilotées par les événements avec des sources d'événements couvrant des applications internes, des applications SaaS tierces et des services AWS, à grande échelle. Service de bus d'événements entièrement géré, EventBridge reçoit des événements provenant de différentes sources, identifie une cible en fonction d'une règle de routage et fournit des données en temps quasi réel à cette cible, notamment AWS Lambda, Amazon SNS et Amazon Kinesis Streams, entre autres. Un événement entrant peut également être personnalisé, par transformateur d'entrée, avant la livraison.

Pour développer des applications pilotées par les événements nettement plus rapidement, les registres de schémas EventBridge collectent et organisent les schémas, y compris les schémas de tous les événements générés par les services AWS. Les clients peuvent également définir des schémas personnalisés ou utiliser une option de déduction de schéma pour découvrir les schémas automatiquement. Dans l'ensemble, toutefois, une valeur de latence relativement plus élevée pour la diffusion d'EventBridge constitue un compromis potentiel pour toutes ces fonctions. En outre, le débit et les quotas par défaut pour EventBridge peuvent nécessiter une augmentation, via une demande de support, en fonction du cas d'utilisation.

Une stratégie de déploiement différente repose sur Amazon MQ, qui peut être utilisé si les logiciels existants utilisent des API et des protocoles standard ouverts pour la messagerie, y compris JMS, NMS, AMQP, STOMP, MQTT et WebSocket. Amazon SQS expose une API personnalisée, ce qui signifie que si vous souhaitez migrer une application existante depuis un environnement sur site vers AWS par exemple, des modifications du code sont nécessaires. Avec Amazon MQ, cela n'est pas nécessaire dans de nombreux cas.

Amazon MQ gère l'administration et la maintenance d'ActiveMQ, un agent de messages open source courant. L'infrastructure sous-jacente est automatiquement configurée pour assurer une haute disponibilité et une durabilité des messages afin d'assurer la fiabilité de vos applications.