VENTES: 1-800-867-1389

Modèles de messagerie asynchrone et haute disponibilité

Mis à jour: septembre 2014

La messagerie asynchrone peut être implémentée de différentes manières. Avec les files d'attente, les rubriques et les abonnements, collectivement appelés entités de messagerie, Microsoft Azure Service Bus prend en charge l'asynchronie via un mécanisme de stockage et de transfert. En mode normal (synchrone), vous envoyez les messages aux files d'attente et aux rubriques, et recevez les messages en provenance des files d'attente et des abonnements. Les applications que vous créez dépendent de ces entités, qui doivent toujours être disponibles. Lorsque l'intégrité de l'entité change (quelle qu'en soit la raison), vous devez trouver un moyen de fournir une fonctionnalité réduite capable de satisfaire la plupart des besoins.

Les applications utilisent généralement des types de messagerie asynchrones pour prendre en charge différents scénarios de communication. Vous pouvez créer des applications dans lesquelles les clients ont la possibilité d'envoyer des messages à un service, même si ce dernier n'est pas en cours d'exécution. Pour les applications confrontées à des pics de communications, une file d'attente peut permettre de niveler la charge en plaçant les communications dans la mémoire tampon. Enfin, vous pouvez bénéficier d'un service d'équilibrage de charge simple mais efficace pour distribuer les messages entre les différents ordinateurs.

Pour que ces entités restent disponibles, tenez compte des différents scénarios d'indisponibilité de ces entités pour un système de messagerie durable. Généralement, les applications que nous créons n'ont plus accès aux entités dans les cas suivants :

  1. Impossible d'envoyer des messages.

  2. Impossible de recevoir des messages.

  3. Impossible d'administrer les entités (créer, récupérer, mettre à jour ou supprimer des entités).

  4. Impossible de contacter le service.

Pour chacune de ces défaillances, différents modes existent afin de permettre à une application de continuer à fonctionner avec des fonctionnalités réduites. Par exemple, un système qui peut envoyer des messages mais pas en récupérer peut malgré tout recevoir des commandes des clients, même s'il n'est pas en mesure de les traiter. Cette rubrique décrit les problèmes potentiels qui peuvent survenir et la manière de les atténuer. Service Bus propose un certain nombre de solutions d'atténuation, et cette rubrique présente également les règles qui gouvernent l'utilisation de ces solutions.

Les problèmes de messages et d'entités peuvent être gérés de différentes façons et des instructions gouvernent l'utilisation appropriée de ces solutions d'atténuation. Pour comprendre les instructions, vous devez d'abord comprendre les défaillances qui peuvent se produire dans Service Bus. Compte tenu de la conception des systèmes Azure, ces problèmes sont généralement de courte durée. Globalement, les différentes causes d'indisponibilité sont les suivantes :

  • Limitation provenant d'un système externe dont Service Bus dépend. La limitation est liée aux interactions avec les ressources de stockage et de calcul.

  • Problème sur un système dont Service Bus dépend. Par exemple, un composant donné d'un système de stockage peut rencontrer des problèmes.

  • Défaillance de Service Bus au niveau d'un sous-système. Dans ce cas, l'état d'un nœud de calcul peut devenir incohérent. Celui-ci doit alors être redémarré, ce qui entraîne un équilibrage de charge de toutes les entités qu'il sert vers d'autres nœuds. Cette opération peut momentanément ralentir le traitement des messages.

  • Défaillance de Service Bus dans un centre de données Azure. Il s'agit de la « défaillance grave » classique au cours de laquelle le système est injoignable pendant quelques minutes, voire quelques heures.

noteRemarque
Le terme stockage peut à la fois s'appliquer à Azure Storage et SQL Azure.

Service Bus contient un certain nombre de solutions d'atténuation pour les problèmes ci-dessus. Les sections suivantes traitent de chacun de ces problèmes et de leurs solutions d'atténuation respectives.

Avec Service Bus, la limitation permet une gestion coopérative du débit de messages. Chaque nœud Service Bus héberge de nombreuses entités. Chacune de ces entités effectue sur le système des demandes relatives au processeur, à la mémoire, au stockage et à d'autres facettes. Lorsqu'une de ces facettes détecte une utilisation supérieure aux seuils définis, Service Bus peut refuser la demande. L'appelant reçoit une exception ServerBusyException et effectue une nouvelle tentative au bout de 10 secondes.

Pour atténuer le problème, le code doit lire l'erreur et interrompre les nouvelles tentatives pendant au moins 10 secondes. Dans la mesure où l'erreur peut se produire sur différents composants de l'application du client, chaque composant doit indépendamment exécuter la logique de nouvelle tentative. Le code peut réduire la probabilité de limitation en autorisant le partitionnement sur une file d'attente ou une rubrique.

D'autres composants d'Azure peuvent occasionnellement rencontrer des problèmes de service. Par exemple, lorsqu'un système utilisé par Service Bus est mis à niveau, les capacités de ce système peuvent momentanément être réduites. Pour contourner ces types de problèmes, Service Bus recherche régulièrement les solutions d'atténuation disponibles et les implémente. Ces solutions d'atténuation ont des effets secondaires. Par exemple, pour gérer les problèmes de stockage transitoires, Service Bus implémente un système qui assure la cohérence des opérations d'envoi de messages. Compte tenu de la nature de la solution d'atténuation, 15 minutes peuvent être nécessaires pour qu'un message envoyé apparaisse dans la file d'attente ou dans l'abonnement concerné et soit prêt pour une opération de réception. Généralement, la plupart des entités ne rencontrent pas ce problème. Toutefois, compte tenu du nombre d'entités de Service Bus sous Azure, cette solution d'atténuation est parfois nécessaire pour un petit sous-ensemble de clients Service Bus.

Quelle que soit l'application, certaines circonstances peuvent entraîner une perte de cohérence au niveau d'un composant interne de Service Bus. Lorsque Service Bus détecte ce type de problème, il recueille les données de l'application pour tenter de déterminer ce qui s'est passé. Une fois les données recueillies, l'application est redémarrée pour tenter de rétablir sa cohérence. Ce processus est relativement rapide et se manifeste par l'indisponibilité d'une entité pendant quelques minutes maximum, bien que les temps morts soient généralement moins longs.

Dans ce cas, l'application cliente génère une exception TimeoutException ou MessagingException. Le Kit de développement logiciel (SDK) Service Bus contient une solution d'atténuation de ce problème, sous la forme d'une logique de nouvelles tentatives automatisée. Si le message n'est pas remis à l'issue du délai de nouvelles tentatives, vous pouvez envisager d'utiliser d'autres fonctionnalités telles que les espaces de noms appariés. Des mises en garde s'appliquent aux espaces de noms appariés, comme indiqué plus loin dans ce document.

Les défaillances qui se produisent dans les centres de données Azure sont généralement dues à l'échec du déploiement d'une mise à niveau de Service Bus ou d'un système qui en dépend. La plateforme ayant gagné en maturité, la probabilité d'apparition de ce type de défaillance est désormais moindre. Un centre de données peut également connaître une défaillance pour les raisons suivantes :

  • Panne d'électricité (coupure d'alimentation ou de production).

  • Connectivité (coupure Internet entre vos clients et Azure).

Dans les deux cas, le problème est dû à une cause naturelle ou humaine. Pour contourner ce problème et continuer à envoyer des messages, vous pouvez utiliser des espaces de noms appariés afin de permettre l'envoi des messages à un emplacement secondaire le temps que le problème soit résolu à l'emplacement principal.

La fonctionnalité Espaces de noms appariés prend en charge les scénarios dans lesquels une entité ou un déploiement Service Bus devient indisponible au sein d'un centre de données. Bien que ce type d'événement soit rare, les systèmes distribués doivent malgré tout être prêts à gérer les pires scénarios. Généralement, cet événement survient parce qu'un élément dont Service Bus dépend rencontre un problème de courte durée. Pour que l'application reste disponible pendant la panne, les utilisateurs de Service Bus peuvent utiliser deux espaces de noms distincts, de préférence dans des centres de données distincts, pour héberger leurs entités de messagerie. La terminologie suivante est employée dans le reste de cette section :

  • Espace de noms principal : espace de noms avec lequel votre application interagit pour les opérations d'envoi et de réception.

  • Espace de noms secondaire : espace de noms de secours de l'espace de noms principal. La logique d'application n'interagit pas avec cet espace de noms.

  • Intervalle de basculement : en cas de défaillance normale, délai à l'issue duquel l'application bascule de l'espace de noms principal vers l'espace de noms secondaire.

Les espaces de noms appariés prennent en charge la disponibilité d'envoi. Cette dernière se concentre sur la préservation de la capacité à envoyer les messages. Pour utiliser la disponibilité d'envoi, votre application doit remplir les conditions suivantes :

  1. Les messages reçus proviennent uniquement de l'espace de noms principal.

  2. Les messages envoyés à une file d'attente/rubrique donnée peuvent arriver dans le désordre.

  3. Si votre application utilise des sessions :

    1. les messages d'une session peuvent arriver dans le désordre. Il s'agit d'un problème au niveau de la fonctionnalité normale des sessions. Cela signifie que votre application utilise des sessions pour regrouper les messages de façon logique.

    2. L'état de la session est uniquement géré sur l'espace de noms principal.

  4. La file d'attente principale peut se connecter et commencer à accepter les messages avant que la file d'attente secondaire ne lui ait remis tous les messages.

Cette section traite des API et de la façon dont celles-ci sont implémentées. Elle présente également des exemples de code utilisant la fonctionnalité. Veuillez noter que des conséquences de facturation sont associées à cette fonctionnalité.

La fonctionnalité Espaces de noms appariés intègre la nouvelle méthode suivante à la classe MessagingFactory :

public Task PairNamespaceAsync(PairedNamespaceOptions options)

Lorsque la tâche se termine, l'appariement d'espaces de noms prend également fin et se prépare à agir pour un MessageReceiver, QueueClient ou TopicClient créé avec la fabrique MessagingFactory. PairedNamespaceOptions correspond à la classe de base des différents types d'appariements disponibles avec une fabrique MessagingFactory. Actuellement, la seule classe dérivée est SendAvailabilityPairedNamespaceOptions. Celle-ci implémente les exigences de disponibilité d'envoi. SendAvailabilityPairedNamespaceOptions possède un ensemble de constructeurs qui se génèrent tous mutuellement. L'examen du constructeur qui possède le plus de paramètres vous permettra de comprendre le comportement des autres constructeurs.

public SendAvailabilityPairedNamespaceOptions(
    NamespaceManager secondaryNamespaceManager,
    MessagingFactory messagingFactory,
    int backlogQueueCount,
    TimeSpan failoverInterval,
    bool enableSyphon)

La signification de ces paramètres est la suivante :

  • secondaryNamespaceManager : instance de NamespaceManager initialisée pour l'espace de noms secondaire et que la méthode PairNamespaceAsync peut utiliser pour configurer l'espace de noms secondaire. Le gestionnaire sera utilisé pour obtenir la liste des files d'attente de l'espace de noms et vérifier que les files d'attente requises pour les journaux de travaux en souffrance existent. Si ces files d'attente n'existent pas, elles seront créées. Le gestionnaire NamespaceManager doit être en mesure de créer un jeton avec la revendication Manage.

  • messagingFactory : instance MessagingFactory de l'espace de noms secondaire. La fabrique MessagingFactory est utilisée pour l'envoi. Elle est également utilisée pour la réception des messages de la file d'attente des journaux de travaux en souffrance si la propriété EnableSyphon est définie sur true.

  • backlogQueueCount : nombre de files d'attente de journaux de travaux en souffrance à créer. Cette valeur doit au moins être définie sur 1. Lors de l'envoi de messages au journal des travaux en souffrance, une de ces files d'attente est choisie de manière aléatoire. Si vous définissez la valeur sur 1, une seule file d'attente pourra être utilisée. Dans ce cas, et si une file d'attente de journaux de travaux en souffrance génère des erreurs, le client ne pourra pas essayer une autre file d'attente de journaux de travaux en souffrance et l'envoi de votre message risque d'échouer. Nous vous recommandons de définir ce paramètre sur une valeur supérieure et de choisir 10 comme valeur par défaut. Vous pouvez le définir sur une valeur supérieure ou inférieure en fonction du volume de données qu'envoie quotidiennement votre application. Chaque file d'attente de journaux de travaux en souffrance peut contenir 5 Go de messages.

  • failoverInterval : délai à l'issue duquel vous basculez de l'espace de noms principal vers l'espace de noms secondaire. Les basculements interviennent entité par entité. Les entités d'un même espace de noms résident souvent dans des nœuds distincts de Service Bus. Une défaillance au niveau d'une entité n'entraîne pas de défaillance sur une autre. Vous pouvez définir cette valeur sur System.TimeSpan.Zero pour basculer vers l'instance secondaire juste après votre première défaillance non transitoire. Les défaillances qui déclenchent le minuteur de basculement correspondent aux exceptions MessagingException dans lesquelles la propriété IsTransient est « false », ou à une exception TimeoutException. Les autres exceptions, comme UnauthorizedAccessException, n'entraînent pas de basculement, car elles indiquent que le client est mal configuré. Une exception ServerBusyException n'entraîne pas de basculement, car le schéma approprié consiste à attendre 10 secondes avant de renvoyer le message.

  • enableSyphon : indique que cet appariement doit également transférer les messages de l'espace de noms secondaire vers l'espace de noms principal. En général, les applications qui envoient des messages doivent définir cette valeur sur false ; les applications qui reçoivent des messages doivent définir cette valeur sur true. Ceci est dû au fait que le nombre de destinataires est souvent inférieur au nombre d'expéditeurs. En fonction du nombre de destinataires, vous pouvez choisir d'utiliser une même instance de l'application pour gérer les tâches de transfert. L'utilisation de différents destinataires comporte des conséquences de facturation pour chaque file d'attente de journaux de travaux en souffrance.

Pour utiliser le code, créez une instance MessagingFactory principale, une instance MessagingFactory secondaire, une instance NamespaceManager secondaire et une instance SendAvailabilityPairedNamespaceOptions. L'appel peut être aussi simple que ce qui suit :

SendAvailabilityPairedNamespaceOptions sendAvailabilityOptions =
    new SendAvailabilityPairedNamespaceOptions(secondaryNamespaceManager, secondary);
primary.PairNamespaceAsync(sendAvailabilityOptions).Wait();

Une fois la tâche renvoyée par la méthode PairNamespaceAsync terminée, tout est configuré et prêt à être utilisé. Avant que la tâche ne soit renvoyée, vous n'avez peut-être pas terminé toutes les tâches d'arrière-plan nécessaires au bon fonctionnement de l'appariement. En conséquence, vous ne pouvez pas entamer l'envoi de messages tant que la tâche n'a pas été renvoyée. En cas de défaillances, liées à des informations d'identification incorrectes ou à l'impossibilité de créer les files d'attente des journaux de travaux en souffrance par exemple, ces exceptions seront envoyées une fois la tâche accomplie. Lorsque la tâche est renvoyée, vérifiez que les files d'attente ont été trouvées ou créées en examinant la propriété BacklogQueueCount sur votre instance SendAvailabilityPairedNamespaceOptions. Pour le code précédent, cette opération apparaît comme suit :

if (sendAvailabilityOptions.BacklogQueueCount < 1)
{
    // Handle case where no queues were created. 
}

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.
Afficher:
© 2015 Microsoft