Le modèle de réclamation-vérification permet aux charges de travail de transférer des charges utiles sans les stocker utile dans un système de messagerie. Le modèle stocke la charge utile dans un magasin de données externe et utilise une « réclamation-vérification » pour la récupérer. La réclamation-vérification est un jeton ou une clé unique, pour masquer. Pour récupérer la charge utile, les applications doivent présenter le jeton de réclamation-vérification au magasin de données externe.
Contexte et problème
Les systèmes de messagerie traditionnels sont optimisés pour gérer un volume élevé de petits messages et présentent souvent des restrictions quant à la taille des messages qu’ils peuvent traiter. Les messages volumineux risquent non seulement de dépasser ces limites, mais aussi de dégrader les performances de l’ensemble du système lorsque le système de messagerie les stocke.
Solution
Utilisez le modèle de réclamation-vérification et n’envoyez pas de messages volumineux au système de messagerie. Envoyez plutôt la charge utile vers un magasin de données externe et générez un jeton de réclamation-vérification pour cette charge utile. Le système de messagerie envoie un message avec le jeton de réclamation-vérification aux applications réceptrices afin qu’elles puissent récupérer la charge utile dans le magasin de données. Le système de messagerie ne voit et ne stocke jamais la charge utile.
- Charge utile
- Enregistrez la charge utile dans le magasin de données.
- Générez un jeton de réclamation-vérification et envoyez un message avec ce dernier.
- Recevez le message et lisez le jeton de réclamation-vérification.
- Récupérez la charge utile.
- Traitez la charge utile.
Problèmes et considérations concernant le modèle de réclamation-vérification
Tenez compte des recommandations suivantes lors de l’implémentation du modèle de réclamation-vérification :
Supprimez les messages consommés. Si vous n’avez pas besoin d’archiver le message, supprimez-le ainsi que la charge utile après que les applications de réception l’ont consommé. Utilisez une stratégie de suppression synchrone ou asynchrone :
Suppression synchrone : l’application consommatrice supprime le message et la charge utile immédiatement après la consommation. Il lie la suppression au flux de travail de gestion des messages et utilise la capacité de calcul du flux de messagerie.
Suppression asynchrone : un processus extérieur au flux de traitement des messages supprime le message et la charge utile. Il dissocie le processus de suppression du flux de travail de gestion des messages et réduit l’utilisation du calcul du flux de messagerie.
Implémentez le modèle de manière conditionnelle. Incorporez la logique dans l’application d’envoi qui applique le modèle de réclamation-vérification si la taille du message dépasse la limite du système de messagerie. Pour les messages plus petits, ignorez le modèle et envoyez-les vers le système de messagerie. Cette approche conditionnelle réduit la latence, optimise l’utilisation des ressources et améliore le débit.
Quand utiliser le modèle de revendication-vérification
Le modèle de revendication-vérification est principalement utilisé dans les scénarios suivants :
Limitations du système de messagerie : utilisez le modèle de revendication-vérification lorsque les tailles des messages dépassent les limites de votre système de messagerie. Déplacez la charge utile vers le stockage externe. Envoyez uniquement le message avec son jeton de revendication-vérification au système de messagerie.
Performances du système de messagerie : utilisez le modèle de revendication-vérification lorsque des messages volumineux sollicitent le système de messagerie et en dégradent les performances.
Le modèle de revendication-vérification est utilisé comme seconde solution dans les scénarios suivants :
Protection des données sensibles : utilisez le modèle réclamation-vérification lorsque les charges utiles contiennent des données sensibles que le système de messagerie ne doit pas rendre visibles. Appliquez le modèle à la totalité ou à une partie des informations sensibles contenues dans la charge utile. Sécurisez les données sensibles sans les transmettre directement via le système de messagerie.
Scénarios de routage complexes : les messages qui passent par plusieurs composants peuvent provoquer des goulets d’étranglement en raison des tâches de sérialisation, de désérialisation, de chiffrement et de déchiffrement. Utilisez le modèle revendication-vérification pour empêcher le traitement direct des messages par des composants intermédiaires.
Conception de la charge de travail avec le modèle de revendication-vérification
Un architecte doit évaluer la façon dont le modèle de réclamation-vérification peut être utilisé dans la conception de leurs charges de travail pour se conformer aux objectifs et principes abordés dans les piliers d’Azure Well-Architected Framework. Par exemple :
| Pilier | Comment ce modèle soutient les objectifs des piliers. |
|---|---|
| Les décisions concernant la conception de la fiabilité contribuent à rendre votre charge de travail résiliente aux dysfonctionnements et à garantir qu’elle se récupère complètement après une défaillance. | Les systèmes de messagerie n’offrent pas une fiabilité et une reprise après sinistre comparables à celles des magasins de données dédiés. La séparation des données du message peut fournir une fiabilité accrue pour la charge utile. Cette séparation facilite la redondance des données qui vous permet de récupérer des charges utiles après un sinistre. - RE :03 Analyse du mode d’échec - RE :09 reprise d’activité après sinistre |
| Les décisions relatives à la conception de la sécurité permettent de garantir la confidentialité, l’intégrité et la disponibilité des données et des systèmes de votre charge de travail. | Le modèle de revendication-vérification peut extraire des données sensibles à partir de messages et les stocker dans un magasin de données sécurisé. Cette configuration vous permet d’appliquer des contrôles d’accès plus stricts, qui garantissent que seuls les services censés utiliser les données sensibles peuvent y accéder. Par ailleurs, elle masque ces données aux services non liés, tels que ceux utilisés pour la surveillance des files d’attente. - SE :03 Classification des données - SE :04 Segmentation |
| L’optimisation des coûts est axée sur le maintien et l’amélioration du retour sur investissement de votre charge de travail. | Les systèmes de messagerie imposent souvent des limites à la taille des messages, et l’augmentation des limites de taille constitue souvent une fonctionnalité Premium. La réduction de la taille des corps des messages est un moyen d’utiliser une solution de messagerie moins onéreuse. - CO :07 Coûts composants - CO :09 Coûts des flux |
| L’efficacité des performances permet à votre charge de travail de répondre efficacement aux demandes grâce à l’optimisation de la mise à l’échelle, du transfert des données et de l’exécution du code. | Le modèle de revendication-vérification améliore l’efficacité des applications d’envoi et de réception et du système de messagerie grâce à une gestion plus efficace des messages volumineux. Il réduit la taille des messages envoyés au système de messagerie et garantit que les applications réceptrices n’accèdent aux messages volumineux qu’en cas de besoin. - PE :05 Mise à l’échelle et partitionnement - PE :12 Optimisation continue des performances |
Comme pour toute autre décision de conception, il convient de prendre en compte les compromis par rapport aux objectifs des autres piliers qui pourraient être introduits avec ce modèle.
Exemples de modèles de revendication-vérification
Les exemples suivants montrent la façon dont Azure facilite l’implémentation du modèle de revendication-vérification :
Systèmes de messagerie Azure : les exemples couvrent quatre scénarios de système de messagerie Azure : Stockage File d’attente Azure, Azure Event Hubs (API Standard), Azure Service Bus et Azure Event Hubs (API Kafka).
Génération automatique ou manuelle du jeton de revendication-vérification : ces exemples présentent également deux méthodes pour générer le jeton de revendication-vérification. Dans les exemples de code 1 à 3, Azure Event Grid génère automatiquement le jeton lorsque l’application d’envoi transfère la charge utile vers le stockage Blob Azure. L’exemple de code 4 montre un processus de génération de jeton manuel à l’aide d’un client de ligne de commande exécutable.
Choisissez l’exemple qui répond à vos besoins et suivez le lien fourni pour afficher le code sur GitHub :
| Exemple de code | Scénarios de système de messagerie | Générateur de jeton | Application de réception | Magasin de données |
|---|---|---|---|---|
| Exemple de code 1 | Stockage File d’attente Azure | Azure Event Grid | Fonction | Stockage Blob Azure |
| Exemple de code 2 | Azure Event Hubs (API Standard) | Azure Event Grid | Client de ligne de commande exécutable | Stockage Blob Azure |
| Exemple de code 3 | Azure Service Bus | Azure Event Grid | Fonction | Stockage Blob Azure |
| Exemple de code 4 | Azure Event Hubs (API Kafka) | Client de ligne de commande exécutable | Fonction | Stockage Blob Azure |
Étapes suivantes
- Le site de modèles Intégration Entreprise a une description de ce modèle.
- Pour un autre exemple, consultez Traiter des messages Service Bus volumineux à l’aide du modèle de revendication-vérification (billet de blog).
- Un autre modèle pour gérer les messages volumineux est Fractionner et Agréger.
- Les bibliothèques comme NServiceBus prennent en charge ce modèle prête à l’emploi avec leur fonctionnalité DataBus.