Cet exemple d’architecture est basé sur l’architecture Intégration d’entreprise de base. Il étend cette architecture pour montrer comment intégrer les systèmes back-end d’entreprise en utilisant des répartiteurs de messages et des événements pour découpler les services et obtenir ainsi une scalabilité et une fiabilité supérieures. Veillez à vous familiariser avec cette conception et les composants utilisés dans l’architecture d’intégration de base. En effet, vous ne trouverez pas d’informations conceptuelles sur les composants de base de cette architecture ici.
Architecture
Les systèmes back-end référencés dans cette conception peuvent inclure des systèmes SaaS (Software as a Service), des services Azure et des services web existants dans votre entreprise.
Téléchargez un fichier Visio de cette architecture.
Workflow
L’architecture illustrée ici s’appuie sur une architecture plus simple, qui est illustrée dans Intégration d’entreprise de base. Cette architecture utilise Logic Apps pour orchestrer les workflows directement avec des systèmes back-end, et la Gestion des API pour créer des catalogues d’API.
Cette version de l’architecture ajoute deux composants qui permettent de rendre le système plus fiable et plus scalable :
Azure Service Bus . Service Bus est un courtier de messages sécurisé et fiable.
Azure Event Grid . Event Grid est un service de routage d’événements. Il utilise un modèle de gestion des événements publication/abonnement (pub/sub).
La communication asynchrone avec un répartiteur de messages offre les avantages suivants par rapport aux appels synchrones et directs à des services back-end :
- Fournit un nivellement de la charge pour gérer les pics des charges de travail avec le Modèle de nivellement de charge basé sur une file d’attente.
- Permet la diffusion de messages à plusieurs consommateurs à l’aide du modèle éditeur-abonné.
- Effectue un suivi fiable de la progression des workflows à exécution longue qui impliquent plusieurs étapes ou plusieurs applications.
- Aide à découpler les applications.
- S’intègre à des systèmes existants basés sur les messages.
- Permet la mise en file d’attente des travaux quand un système back-end n’est pas disponible.
Event Grid permet aux différents composants du système de réagir aux événements au fur et à mesure qu’ils se produisent, au lieu de s’appuyer sur l’interrogation ou sur des tâches planifiées. Comme avec une file d’attente de messages et des rubriques, il permet de découpler les applications et les services. Une application ou un service peut publier des événements : les abonnés intéressés en sont alors avertis. De nouveaux abonnés peuvent être ajoutés sans mettre à jour l’expéditeur.
De nombreux services Azure prennent en charge l’envoi d’événements à Event Grid. Par exemple, une application logique peut être à l’écoute d’un événement, par exemple quand de nouveaux fichiers sont ajoutés à un magasin d’objets blob. Ce modèle permet des workflows réactifs, où le chargement d’un fichier ou le placement d’un message dans une file d’attente lance une série de processus. Les processus peuvent être exécutés en parallèle ou dans une séquence spécifique.
Recommandations
Les recommandations décrites dans Intégration d’entreprise de base s’appliquent à cette architecture.
Service Bus
Service Bus a deux modes de remise : par extraction (pull) ou par envoi (push) par proxy. Dans le modèle d’extraction, le récepteur interroge de façon continue pour déterminer s’il y a de nouveaux messages. L’interrogation peut être inefficace, surtout si vous avez de nombreuses files d’attente qui reçoivent chacune quelques messages, ou si l’intervalle de temps entre les messages est important. Dans le modèle d’envoi par proxy, Service Bus envoie un événement via Event Grid quand il y a de nouveaux messages. Le destinataire s’abonne à l’événement. Quand l’événement est déclenché, le destinataire extrait de Service Bus le lot de messages suivant.
Quand vous créez une application logique pour consommer des messages Service Bus, nous recommandons d’utiliser le modèle d’envoi par proxy avec intégration à Event Grid. Il est souvent plus économique, car l’application logique n’a pas besoin d’interroger Service Bus. Pour plus d’informations, consultez Vue d’ensemble de l’intégration d’Azure Service Bus à Event Grid. Actuellement, le niveau Premium de Service Bus est nécessaire pour les notifications Event Grid.
Utilisez PeekLock pour accéder à un groupe de messages. Lorsque vous utilisez PeekLock, l’application logique peut suivre des étapes pour valider chaque message avant de terminer ou d’abandonner le message. Cette approche protège contre la perte accidentelle de messages.
Event Grid
Quand un déclencheur Event Grid est activé, cela signifie qu’au moins un événement s’est produit. Par exemple, quand une application logique reçoit un déclencheur Event Grid pour un message Service Bus, elle doit supposer que plusieurs messages peuvent être disponibles pour être traités.
Considérations
Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.
Fiabilité
La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.
- Microsoft Entra ID : Microsoft Entra ID est une plate-forme SaaS distribuée à l'échelle mondiale et hautement disponible. Pour plus d’informations sur la disponibilité garantie, reportez-vous au Contrat de niveau de service (SLA).
- Gestion des API : La Gestion des API peut être déployée dans plusieurs configurations à haute disponibilité, en fonction des exigences métier et de la tolérance des coûts. Reportez-vous à Garantir la disponibilité et la fiabilité la Gestion des API pour passer en revue la totalité des options. Pour plus d’informations sur la disponibilité garantie, reportez-vous également au SLA.
- Logic Apps : Le stockage géoredondant est disponible pour Logic Apps sur le niveau de plan Consommation. Pour obtenir des informations sur la conception d’une solution de continuité d’activité et de reprise d’activité, reportez-vous aux conseils. Pour plus d’informations sur la disponibilité garantie, reportez-vous également au SLA.
- Event Grid : Les définitions de ressource Event Grid pour les rubriques, les rubriques système, les domaines, les abonnements aux événements et les données d’événements sont répliquées automatiquement dans trois zones de disponibilité (quand elles sont disponibles) dans la région. En cas de défaillance dans l’une des zones de disponibilité, les ressources Event Grid basculent automatiquement vers une autre zone de disponibilité sans intervention humaine. Pour obtenir des conseils sur la conception d’une solution de reprise d’activité afin de basculer vers une autre région, reportez-vous à Géo-reprise d’activité après sinistre dans les régions. Pour plus d’informations sur la disponibilité garantie, reportez-vous également au SLA.
- Service Bus : Service Bus Premium prend en charge la géo-reprise d’activité après sinistre et les zones de disponibilité. La réplication est disponible pour Service Bus Standard. Pour plus d’informations sur la disponibilité garantie, reportez-vous également au SLA.
Sécurité
La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.
Pour sécuriser Service Bus, utilisez l’authentification Microsoft Entra associée aux identités managées. L'intégration Microsoft Entra pour les ressources Service Bus fournit un contrôle d'accès basé sur le rôle (RBAC) Azure pour un contrôle précis de l'accès d'un client aux ressources. Vous pouvez utiliser le contrôle d’accès en fonction du rôle (RBAC) Azure pour accorder des autorisations à un principal de sécurité, qui peut être un utilisateur, un groupe ou un principal de service d’application (une identité managée dans le cas présent).
Lorsque Microsoft Entra ID n'est pas disponible, vous pouvez utiliser la signature d'accès partagé (SAS). Par exemple, vous pouvez accorder à un utilisateur l’accès à des ressources Service Bus avec des droits spécifiques en utilisant l’authentification SAS.
Si vous devez exposer une file d’attente ou rubrique Service Bus en tant que point de terminaison HTTP (pour la publication de nouveaux messages, par exemple), utilisez Gestion des API pour la sécuriser en exposant le point de terminaison. Vous pouvez alors sécuriser le point de terminaison avec des certificats ou une authentification OAuth si besoin. Le moyen le plus simple de sécuriser un point de terminaison consiste à utiliser une application logique avec un déclencheur de requête/réponse HTTP comme intermédiaire.
Le service Event Grid sécurise la distribution des événements au moyen d’un code de validation. Si vous utilisez Logic Apps pour consommer l’événement, la validation est automatiquement effectuée. Pour en savoir plus, consultez la page Sécurité et authentification pour Event Grid.
Sécurité du réseau
La sécurité réseau doit être prise en compte tout au long de la conception.
- Service Bus Premium peut être lié à un point de terminaison de service de sous-réseau de réseau virtuel (VNet), ce qui sécurise l’espace de noms pour accepter uniquement le trafic provenant de réseaux virtuels autorisés. De plus, utilisez des points de terminaison privés pour bloquer le trafic de votre réseau virtuel en le limitant au trafic privé via Private Link.
- Logic Apps Vous pouvez configurer Logic Apps Standard et Premium pour accepter le trafic entrant par le biais de points de terminaison privés et envoyer le trafic sortant par le biais de l’intégration au réseau virtuel.
- La Gestion des API offre plusieurs options pour sécuriser l’accès à votre instance de Gestion des API et aux API à l’aide d’un réseau virtuel Azure. Pour un examen approfondi des options, reportez-vous à la documentation Utiliser un réseau virtuel avec la Gestion des API Azure. Les points de terminaison privés sont également pris en charge.
Optimisation des coûts
L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.
En règle générale, utilisez la calculatrice de prix Azure pour estimer les coûts. Voici quelques autres éléments à prendre en compte :
Gestion des API
Vous êtes facturé pour toutes les instances de Gestion des API en cours d’exécution. Si vous avez effectué un scale-up et que vous n’avez pas besoin de ce niveau de performances tout le temps, effectuez manuellement un scale-down ou configurez la mise à l’échelle automatique.
Pour les charges de travail à utilisation simplifiée, considérez le niveau Consommation, qui est une option serverless à faible coût. Le niveau Consommation est facturé par appel d’API, tandis que les autres niveaux sont facturés à l’heure.
Logic Apps
Logic Apps utilise un modèle serverless. La facturation est calculée en fonction de l’action et de l’exécution du connecteur. Pour plus d’informations, consultez Tarifs Logic Apps.
Service Bus - Files d’attente, rubriques et abonnements
Les files d’attente et abonnements Service Bus prennent en charge à la fois les modèles d’envoi par proxy et les modèles d’extraction pour la remise des messages. Dans le modèle par extraction, chaque requête d’interrogation est mesurée en tant qu’action. Même avec une interrogation longue de 30 secondes (par défaut), les coûts peuvent être élevés. Songez à utiliser le modèle d’envoi par proxy à moins que vous ayez besoin de distribuer des messages en temps réel.
Les files d’attente Service Bus sont incluses dans tous les niveaux (niveaux de base, standard et premium). Alors que les rubriques et les abonnements Service Bus sont disponibles dans les niveaux Standard et Premium. Pour en savoir plus, consultez les rubriques Tarification Azure Service Bus.
Event Grid
Event Grid utilise un modèle serverless. La facturation est calculée en fonction du nombre d’opérations (exécutions d’événement). Les opérations comprennent l’entrée d’événements aux Domaines ou Rubriques, des correspondances avancées, des tentatives de distribution ainsi que des appels de gestion. L’utilisation est gratuite jusqu’à 100 000 opérations.
Pour plus d’informations, consultez Prix d’Event Grid.
Pour plus d’informations, consultez la section sur les coûts dans Microsoft Azure Well-Architected Framework.
Excellence opérationnelle
L’architecture de référence de l’intégration entreprise de base fournit des conseils sur les modèles DevOps, qui s’alignent sur le pilier d’excellence opérationnelle de Well-Architected Framework.
Le fait d’automatiser autant que possible les opérations de reprise d’activité fait partie intégrante de l’excellence opérationnelle. Avec l’automatisation à l’esprit, vous pouvez combiner le monitoring des journaux Azure et Azure Automation pour automatiser le basculement de vos ressources Service Bus. Reportez-vous au diagramme présenté dans la documentation relative aux flux de basculement pour obtenir un exemple de logique d’automatisation permettant de lancer un basculement.
Efficacité des performances
L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.
Pour bénéficier d’une meilleure extensibilité, le niveau Premium de Service Bus peut augmenter le nombre d’unités de messagerie. Reportez-vous à la documentation sur les couches messagerie Service Bus Premium et Standard pour passer en revue les avantages du niveau Premium. Reportez-vous également la documentation sur la fonctionnalité de mise à l’échelle automatique pour en savoir plus sur la configuration de la mise à l’échelle automatique des unités de messagerie.
Vous trouverez d’autres recommandations concernant Service Bus dans Bonnes pratiques relatives aux améliorations des performances à l’aide de la messagerie Service Bus.
Étapes suivantes
Pour plus d’informations, consultez la documentation Service Bus :
- Vue d’ensemble de l’intégration d’Azure Service Bus et Event Grid
- Couches messagerie Service Bus Premium et Standard
- Fonctionnalité de mise à l’échelle automatique Service Bus
- Bonnes pratiques relatives aux améliorations de performances à l’aide de la messagerie Service Bus