Choisir une plateforme de messagerie
De nombreuses plateformes de communications sont disponibles pour aider à améliorer la fiabilité d’une application distribuée, notamment dans Microsoft Azure. Chacune d’elles répond à un objectif différent. Il est important de choisir un outil adapté à l’ensemble des exigences de votre application. Jetez un œil aux options qui vous sont proposées dans Azure Service Bus.
L’architecture distribuée de l’application de commande et de suivi de Contoso Bicycles proposée requiert plusieurs composants, notamment un site Web, un stockage de données et un service principal. Vous pouvez lier les composants de votre application de différentes manières. Par ailleurs, une même application peut tirer parti de plusieurs techniques.
Vous devez déterminer lesquelles utiliser dans la nouvelle application de Contoso Bicycles. La première étape consiste à évaluer les différents emplacements où se produit une communication entre plusieurs composants. Certains composants doivent s’exécuter en temps voulu pour permettre à votre application de faire son travail. D’autres peuvent être importants, mais pas critiques d’un point de vue temporel. D’autres composants encore, par exemple les notifications de l’application mobile, sont un peu plus facultatifs.
Choisir entre les messages et les événements
Les messages et les événements sont tous deux des datagrammes, c’est-à-dire des packages de données envoyés d’un composant vers un autre. Ils diffèrent de manières qui semblent tout d’abord subtiles, mais peuvent engendrer des différences significatives dans la manière dont vous concevez votre application.
Messages
Dans la terminologie des applications distribuées, la principale caractéristique d’un message est que l’intégrité globale de l’application peut reposer sur les messages reçus. Vous pouvez considérer l’envoi d’un message comme un passage de témoin de workflow par un composant à un autre composant. L’intégralité du workflow peut être un processus d’entreprise essentiel, et le message est l’élément qui cimente les composants.
Un message contient généralement les données réelles plutôt qu’une simple référence à ces données (par exemple une URL ou un ID). L’envoi de données dans le cadre d’un datagramme est moins fragile que l’envoi d’une référence. L’architecture des messages garantit la remise du message, et dans la mesure où aucune recherche supplémentaire n’est nécessaire, le message est traité de manière fiable. Toutefois, l’application expéditrice doit savoir exactement quelles données inclure afin d’éviter d’envoyer trop de données (ce qui exigerait du travail inutile de la part du composant récepteur). Dans ce sens, l’émetteur et le récepteur du message sont souvent associés par un contrat de données strict.
Dans la nouvelle architecture destinée à Contoso Bicycles, l’entreprise utilisera probablement des messages chaque fois qu’une commande sera passée. Le composant web frontal ou l’application mobile enverra un message aux composants de traitement back-end. Dans le back-end ont lieu des étapes comme l’acheminement vers le magasin le plus proche du client et le débit sur la carte de crédit.
Événements
Un événement déclenche une notification indiquant que quelque chose s’est passé. Les événements sont « plus légers » que les messages, et sont le plus souvent utilisés pour des communications en mode diffusion.
Les événements présentent les caractéristiques suivantes :
- L’événement peut être envoyé à plusieurs récepteurs, ou à aucun.
- Les événements sont souvent destinés à être « déployés », ou ont un grand nombre d’abonnés pour chaque éditeur.
- L’éditeur d’événements n’attend aucune action particulière d’un composant récepteur.
Une chaîne de magasins de vélos utilisera probablement des événements pour envoyer des notifications aux utilisateurs à propos de changements d’état. Les événements de changement d’état pourraient être envoyés à Azure Event Grid, puis à Azure Functions et à Azure Notification Hubs pour bénéficier d’une solution entièrement serverless.
Cette différence entre les événements et les messages est fondamentale, car les plateformes de communication sont généralement conçues pour gérer les uns ou les autres. Service Bus est conçu pour gérer les messages. Si vous souhaitez envoyer des événements, vous choisiriez probablement Event Grid.
Azure propose également Azure Event Hubs, mais ce service est souvent utilisé pour un type spécifique de flux de communications à débit élevé à des fins d’analytique. Si par exemple vous disposez de capteurs en réseau dans vos entrepôts de fabrication, vous pouvez utiliser Event Hubs couplé avec Azure Stream Analytics pour repérer des modèles de changement de température susceptibles d’indiquer un incendie ou l’usure d’un composant.
Rubriques et files d’attente Service Bus
Azure Service Bus peut échanger des messages de deux façons différentes : les files d’attente et les rubriques.
Qu’est-ce qu’une file d’attente ?
Une file d’attente Service Bus est un emplacement de stockage temporaire simple pour les messages. Un composant expéditeur ajoute un message à la file d’attente. Un composant de destination récupère le message au début de la file d’attente. Dans des circonstances normales, chaque message est reçu par un seul destinataire.
Les files d’attente découplent les composants source et de destination afin d’isoler les composants de destination de la demande élevée.
Pendant les heures de pointe, les messages peuvent arriver plus rapidement que les composants de destination ne peuvent les gérer. Les composants sources n’ayant aucune connexion directe avec la destination, la source n’est pas affectée et la file d’attente augmente. Les composants de destination suppriment les messages de la file d’attente à mesure qu’ils peuvent les gérer. Lorsque la demande diminue, les composants de destination peuvent rattraper leur retard et la file d’attente raccourcit.
Une file d’attente répond à la demande élevée sans avoir à ajouter de ressources au système. Toutefois, pour les messages qui doivent être traités rapidement, la création d’autres instances de votre composant de destination peut permettre de partager la charge. Chaque message est traité par une seule instance. Il s’agit d’un moyen efficace de mettre à l’échelle l’ensemble de votre application en ajoutant uniquement des ressources aux composants qui en ont réellement besoin.
Qu’est-ce qu’une rubrique ?
Une rubrique Service Bus est similaire à une file d’attente, mais peut comporter plusieurs abonnements. Cela signifie que plusieurs composants de destination peuvent s’abonner à une même rubrique, chaque message étant alors remis à plusieurs destinataires. Les abonnements peuvent également filtrer les messages dans la rubrique afin de recevoir uniquement les messages pertinents. Les abonnements fournissent les mêmes communications découplées que les files d’attente, et répondent à la demande élevée de la même façon. Utilisez une rubrique si vous souhaitez que chaque message soit remis à plusieurs composants de destination.
Notes
Les rubriques ne sont pas prises en charge dans le niveau tarifaire De base.
Files d’attente et files d’attente de stockage Service Bus
Deux services Azure incluent des files d’attente de messages : Service Bus et le Stockage Azure. En règle générale, les files d’attente de stockage sont plus simples à utiliser, mais moins sophistiquées et moins flexibles que les files d’attente Service Bus.
Voici les principaux avantages offerts par les files d’attente Service Bus :
- Prise en charge de tailles de messages supérieures s’élevant à 256 Ko (niveau Standard) ou à 100 Mo (niveau Premium) par message, au lieu de 64 Ko pour les messages en file d’attente du stockage Azure.
- Prise en charge de la remise au plus une fois et au moins une fois. Choisissez entre une très petite probabilité qu’un message soit perdu et une très petite probabilité qu’il soit traité deux fois.
- Garantie de l’ordre premier entré, premier sorti (FIFO, First-In, First-Out). Les messages sont traités dans l’ordre dans lequel ils sont ajoutés. Bien que FIFO corresponde au fonctionnement normal d’une file d’attente, le modèle FIFO par défaut est modifié si l’organisation configure des messages séquencés ou planifiés ou pendant des interruptions comme un incident système. Pour plus d’informations, consultez Comparaison des files d’attente du Stockage Azure et des files d’attente Azure Service Bus.
- Possibilité de regrouper plusieurs messages dans une transaction. En cas d’échec de remise d’un des messages de la transaction, aucun d’eux n’est remis.
- Prise en charge de la sécurité basée sur les rôles.
- Les composants de destination ne sont pas obligés d’interroger en permanence la file d’attente.
Avantages des files d’attente de stockage :
- Prise en charge d’une taille de file d’attente illimitée (alors que la limite est de 80 Go pour les files d’attente Service Bus)
- Maintenance d’un journal de tous les messages
Comment choisir une technologie de communication ?
Vous avez vu les différents concepts et les implémentations fournies par Azure. Examinez maintenant votre processus de décision pour chacune de vos communications.
Considérations
Lorsque vous choisissez une méthode pour envoyer et recevoir des messages, posez-vous les questions suivantes :
La communication est-elle un événement ? Si oui, utilisez Event Grid ou Event Hubs.
Un même message doit-il être remis à plusieurs destinations ? Si oui, utilisez une rubrique Service Bus. Dans le cas contraire, utilisez une file d’attente Service Bus.
Files d’attente : Service Bus ou stockage
Si vous identifiez que vous avez besoin d’une file d’attente, affinez votre choix.
Choisissez une file d’attente Service Bus dans les cas suivants :
- Vous avez besoin d’une garantie de remise « au plus une fois ».
- Vous avez besoin d’une garantie FIFO (si aucun autre paramètre ne prend la priorité sur l’ordre FIFO par défaut).
- Vous avez besoin de regrouper les messages dans des transactions.
- Vous souhaitez recevoir les messages sans interroger la file d’attente.
- Vous devez fournir un accès en fonction du rôle aux files d’attente.
- Vous devez gérer des messages dont la taille est supérieure à 64 Ko, mais inférieure à 256 Ko pour le niveau Standard ou à 100 Mo pour le niveau Premium.
- La taille de la file d’attente ne sera pas supérieure à 80 Go.
- Vous souhaitez pouvoir publier et utiliser des lots de messages.
Choisissez une file d’attente de stockage dans les cas suivants :
- Vous avez besoin d’une file d’attente simple sans aucune exigence supplémentaire particulière.
- Vous avez besoin d’une piste d’audit de tous les messages qui passent par la file d’attente.
- Vous vous attendez à ce que la taille de la file d’attente dépasse 80 Go.
- Vous souhaitez suivre la progression du traitement d’un message dans la file d’attente.
Même si les composants d’une application distribuée peuvent communiquer directement, il est souvent possible d’augmenter la fiabilité de ce type de communication en utilisant une plateforme de communication intermédiaire comme Azure Event Hubs ou Azure Event Grid.
Event Hubs et Event Grid sont conçus pour les événements qui se contentent de notifier les destinataires d’un événement sans envoyer les données brutes associées à cet événement. Azure Event Hubs est conçu pour les événements de type analytique à débit élevé.
Azure Service Bus et les files d’attente concernent les messages que vous pouvez utiliser pour lier les composants essentiels de n’importe quel workflow d’application.
Si vos besoins sont simples, si vous souhaitez envoyer chaque message à une seule destination, ou si vous souhaitez écrire du code le plus rapidement possible, une file d’attente de stockage peut constituer la meilleure option. Dans le cas contraire, les files d’attente Service Bus fournissent beaucoup plus d’options et de flexibilité.
Si vous voulez envoyer des messages à plusieurs abonnés, utilisez une rubrique Service Bus.