Cette architecture est basée sur l’architecture d’intégration d’entreprise de base, mais inclut la façon d’intégrer des systèmes back-end d’entreprise. Cette architecture utilise les répartiteurs de messages et les événements pour dissocier les services pour améliorer la scalabilité et la fiabilité. Assurez-vous que vous connaissez bien la conception et les composants de l’architecture d’intégration de base. Ces éléments fournissent des informations fondamentales sur les composants principaux de cette architecture.
Architecture
Les systèmes principaux auxquels cette conception fait référence incluent des systèmes SaaS (Software as a Service), des services Azure, des services basés sur des messages et des services web existants dans votre entreprise.
Téléchargez un fichier Visio de cette architecture.
Détails du scénario
L’architecture précédente repose sur l’architecture d’intégration d’entreprise de base plus simple qui utilise Azure Logic Apps pour orchestrer des workflows directement avec des systèmes principaux et utilise Azure 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 est un répartiteur de messages sécurisé et fiable.
Azure Event Grid est un service de routage des événements. Il utilise un modèle de publication et d’abonnement aux événements.
Cette architecture utilise la communication asynchrone via un répartiteur de messages au lieu d’effectuer des appels directs et synchrones aux services principaux. La communication asynchrone offre les avantages suivants :
Utilise le modèle de nivellement de charge basé sur la file d’attente pour gérer les rafales dans les charges de travail via le niveau de charge
Utilise le modèle Publisher-Subscriber pour que vous puissiez diffuser des messages vers plusieurs consommateurs
Suit la progression des workflows de longue durée de manière fiable, même lorsqu’ils impliquent plusieurs étapes ou plusieurs applications
Aide à dissocier les applications
S’intègre à des systèmes basés sur des messages existants
Fournit la possibilité de mettre en file d’attente les messages lorsqu’un système principal n’est pas disponible
Utilisez Event Grid pour que différents composants du système puissent réagir aux événements lorsqu’ils se produisent, plutôt que de s’appuyer sur des tâches d’interrogation ou planifiées. Comme pour une file d’attente de messages et des rubriques, Event Grid permet de dissocier les applications et les services. Si une application ou un service publie des événements, tous les abonnés intéressés sont avertis. Vous pouvez ajouter de nouveaux abonné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 crée des flux de travail réactifs dans lesquels le chargement d’un fichier ou la mise en file d’attente d’un message démarre une série de processus. Les processus peuvent s’exécuter en parallèle ou dans une séquence spécifique.
Recommandations
Tenez compte des recommandations suivantes. Pour plus de recommandations, consultez Architecture d’intégration d’entreprise de base.
Service Bus
Service Bus a deux modèles de remise, le modèle d’extraction et le modèle push proxié :
Modèle d’extraction : le récepteur interroge en permanence les nouveaux messages. Si vous devez gérer plusieurs files d’attente et heures d’interrogation, l’interrogation peut être inefficace. Toutefois, ce modèle peut simplifier votre architecture, car il supprime des composants et des tronçons de données supplémentaires.
Modèle Push proxié : le récepteur s’abonne initialement à un type d’événement spécifique sur une rubrique Event Grid. Lorsqu’un nouveau message est disponible, Service Bus déclenche et envoie un événement via Event Grid. Cet événement déclenche ensuite le récepteur pour extraire le lot suivant de messages à partir de Service Bus. Ce modèle permet aux systèmes de recevoir des messages presque en temps réel, mais sans utiliser de ressources pour interroger en permanence les nouveaux messages. Cette architecture utilise des composants supplémentaires que vous devez déployer, gérer et sécuriser.
Lorsque vous créez un flux de travail Logic Apps standard qui consomme des messages Service Bus, nous vous recommandons d’utiliser les déclencheurs de connecteur intégrés Service Bus. Le connecteur intégré déclenche la plupart de la configuration du modèle pull sans ajouter de coût supplémentaire. Cette fonctionnalité offre le bon équilibre entre le coût, la gestion des surfaces d’exposition et la sécurité, car le connecteur effectue en permanence des boucles dans le moteur d’exécution Logic Apps. Pour plus d’informations, consultez les déclencheurs de connecteur intégrés Service Bus.
Utilisez le mode 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 empêche la perte accidentelle de messages.
Event Grid
Lorsqu’un déclencheur Event Grid se déclenche, cela signifie qu’au moins un événement s’est produit. Par exemple, lorsqu’une application logique obtient un déclencheur Event Grid pour un message Service Bus, plusieurs messages peuvent être disponibles pour le traitement.
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 en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.
Microsoft Entra ID est une plateforme SaaS distribuée mondialement et hautement disponible.
Vous pouvez déployer Gestion des API dans plusieurs configurations hautement disponibles, en fonction des exigences métier et de la tolérance aux coûts. Pour plus d’informations, consultez Vérifier Gestion des API disponibilité et fiabilité.
Le niveau Consommation de Logic Apps prend en charge le stockage géoredondant. Pour plus d’informations, consultez La continuité d’activité et la récupération d’urgence pour Logic Apps.
Les définitions de ressources Event Grid pour les rubriques, les rubriques système, les domaines et les abonnements aux événements et les données d’événement sont automatiquement répliquées entre les zones de disponibilité d’une 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 plus d’informations, consultez l’article récupération d’urgence et continuité d’activité inter-région.
Service Bus Premium prend en charge la géorécupération d’urgence et les zones de disponibilité. Service Bus Standard prend en charge la réplication.
Pour plus d’informations sur la disponibilité garantie de chaque service, consultez les contrats SLA pour services en ligne.
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 en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la sécurité.
Pour sécuriser Service Bus, associez l’authentification Microsoft Entra à des identités managées. L’intégration d’ID Microsoft Entra pour les ressources Service Bus fournit un contrôle d’accès en fonction du rôle Azure (RBAC) pour un contrôle précis sur l’accès d’un client aux ressources. Vous pouvez utiliser Azure RBAC pour accorder des autorisations à un principal de sécurité, tel qu’un utilisateur, un groupe ou un principal de service d’application. Le principal du service d’application dans ce scénario est une identité managée.
Si vous ne pouvez pas utiliser l’ID Microsoft Entra, utilisez l’authentification par signature d’accès partagé (SAP) pour accorder aux utilisateurs l’accès et des droits spécifiques aux ressources Service Bus.
Si vous devez exposer une file d’attente ou une rubrique Service Bus en tant que point de terminaison HTTP, par exemple pour publier de nouveaux messages, utilisez Gestion des API pour sécuriser la file d’attente en frontant le point de terminaison. Vous pouvez ensuite utiliser des certificats ou l’authentification OAuth pour sécuriser le point de terminaison. Le moyen le plus simple de sécuriser un point de terminaison consiste à utiliser une application logique qui a un déclencheur de requête ou de réponse HTTP en tant qu’intermédiaire.
Le service Event Grid permet de sécuriser la remise des événements via un code de validation. Si vous utilisez Logic Apps pour consommer l’événement, la validation est automatique. Pour en savoir plus, consultez la page Sécurité et authentification pour Event Grid.
Sécurité du réseau
Prenez en compte la sécurité réseau tout au long de votre conception.
Vous pouvez lier Service Bus Premium à un point de terminaison de service de sous-réseau de réseau virtuel. Cette configuration permet de sécuriser l’espace de noms, car il accepte uniquement le trafic provenant de réseaux virtuels autorisés. Vous pouvez également utiliser Azure Private Link pour autoriser uniquement le trafic privé vers votre réseau virtuel via des points de terminaison privés.
Vous pouvez configurer Logic Apps Standard et Premium pour accepter le trafic entrant via des points de terminaison privés et envoyer du trafic sortant via l’intégration de réseau virtuel.
Vous pouvez utiliser un réseau virtuel Azure pour sécuriser l’accès à votre instance et API Gestion des API. Cette méthode prend en charge les points de terminaison privés. Pour plus d’informations, consultez Utiliser un réseau virtuel avec Gestion des API.
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 Liste de contrôle de la révision de la conception pour l'optimisation des coûts.
Utiliser 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 Gestion des API lorsqu’elles s’exécutent. Si vous effectuez un scale-up, puis que vous n’avez plus besoin de ce niveau de performances, effectuez un scale-down manuel ou configurez la mise à l’échelle automatique.
Pour les charges de travail d’utilisation légère, tenez compte du niveau Consommation, qui est une option serverless à faible coût. Le niveau Consommation est facturé par appel d’API. D’autres niveaux sont facturés par heure.
Logic Apps
Logic Apps utilise un modèle serverless. La facturation est calculée en fonction du nombre d’actions et d’appels de connecteur. Pour plus d’informations, consultez Tarifs Logic Apps.
Files d’attente, rubriques et abonnements Service Bus
Les files d’attente et les abonnements Service Bus prennent en charge les modèles push et pull proxiés pour remettre des messages. Dans le modèle par extraction, chaque requête d’interrogation est mesurée en tant qu’action. Même si vous définissez une interrogation longue sur la valeur par défaut de 30 secondes, le coût peut être élevé. Sauf si vous avez besoin d’une remise de messages en temps réel, envisagez d’utiliser le modèle push proxié.
Les files d’attente Service Bus sont incluses dans tous les niveaux : De base, Standard et Premium. Les rubriques et abonnements Service Bus sont disponibles dans les niveaux Standard et Premium. Pour plus d’informations, consultez Tarification Service Bus.
Event Grid
Event Grid utilise un modèle serverless. La facturation est calculée en fonction du nombre d’opérations. Les opérations incluent des événements qui vont vers des domaines ou des rubriques, des correspondances avancées, des tentatives de remise et des appels de gestion. L’utilisation est gratuite jusqu’à 100 000 opérations.
Pour plus d’informations, consultez la tarification Event Grid et l’optimisation des coûts du framework bien architected.
Excellence opérationnelle
L’excellence opérationnelle couvre les processus opérationnels qui déploient une application et la maintiennent en production. Pour plus d’informations, consultez la Liste de contrôle de l'examen de la conception pour l'excellence opérationnelle.
L’architecture de référence d’intégration d’entreprise de base fournit des conseils sur les modèles DevOps, qui s’alignent sur le pilier De l’excellence opérationnelle du Framework Bien architected.
Automatisez les opérations de récupération autant que possible pour améliorer l’excellence opérationnelle. Avec l’automatisation à l’esprit, vous pouvez combiner la supervision des journaux Azure avec Azure Automation pour automatiser le basculement de vos ressources Service Bus. Pour obtenir un exemple de logique d’automatisation pour lancer un basculement, consultez le flux de 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 en savoir plus, consultez Liste de vérification de l'examen de la conception pour l'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. Pour plus d’informations, consultez les niveaux de messagerie Service Bus Premium et Standard et la fonctionnalité de mise à l’échelle automatique.
Pour plus de recommandations Service Bus, consultez les meilleures pratiques pour améliorer les performances à l’aide de la messagerie Service Bus.
Étapes suivantes
- Vue d’ensemble de l’intégration de Service Bus vers Event Grid
- Tutoriel qui utilise la messagerie pour intégrer des systèmes non-Microsoft via NServiceBus