Mappage d’eShopOnContainers aux services Azure

Bien qu’il ne soit pas nécessaire, Azure est bien adapté à la prise en charge des eShopOnContainers, car le projet a été conçu pour être une application native cloud. L’application est générée avec .NET, afin qu’elle puisse s’exécuter sur des conteneurs Linux ou Windows en fonction de l’hôte Docker. L’application est constituée de plusieurs microservices autonomes, chacun avec ses propres données. Les différents microservices présentent différentes approches, allant des opérations CRUD simples aux modèles DDD et CQRS plus complexes. Les microservices communiquent avec les clients via HTTP et entre eux via la communication basée sur les messages. L’application prend également en charge plusieurs plateformes pour les clients, car elle adopte HTTP comme protocole de communication standard et inclut ASP.NET applications mobiles Core et Xamarin qui s’exécutent sur des plateformes Android, iOS et Windows. (Xamarin n’est pas pris en charge depuis mai 2024.)

L’architecture de l’application est illustrée dans la figure 2-5. Sur la gauche se trouvent les applications clientes, divisées en versions mobiles, web traditionnelles et application monopage web (SPA). À droite sont les composants côté serveur qui composent le système, chacun pouvant être hébergé dans des conteneurs Docker et des clusters Kubernetes. L’application web traditionnelle est alimentée par l’application ASP.NET Core MVC affichée en jaune. Cette application et les applications SPA mobiles et web communiquent avec les microservices individuels via une ou plusieurs passerelles d’API. Les passerelles d’API suivent le modèle « backends pour les serveurs frontaux » (BFF), ce qui signifie que chaque passerelle est conçue pour prendre en charge un client frontal donné. Les microservices individuels sont répertoriés à droite des passerelles d’API et incluent la logique métier et un certain type de magasin de persistance. Les différents services utilisent des bases de données SQL Server, des instances de cache Redis et des magasins MongoDB/CosmosDB. À l’extrême droite, le bus d’événements du système est utilisé pour la communication entre les microservices.

Figure 2-5. L'architecture d'eShopOnContainers.

Les composants côté serveur de cette architecture sont mappés facilement aux services Azure.

Orchestration et clustering de conteneurs

Les services hébergés par conteneur de l’application, de ASP.NET applications MVC principales aux microservices de catalogue et de commande individuels, peuvent être hébergés et gérés dans Azure Kubernetes Service (AKS). L’application peut s’exécuter localement sur Docker et Kubernetes, et les mêmes conteneurs peuvent ensuite être déployés sur des environnements intermédiaires et de production hébergés dans AKS. Ce processus peut être automatisé, comme nous le verrons dans la section suivante.

AKS fournit des services de gestion pour des clusters individuels de conteneurs. L’application déploie des conteneurs distincts pour chaque microservice du cluster AKS, comme illustré dans le diagramme d’architecture ci-dessus. Cette approche permet à chaque service individuel de s’adapter indépendamment en fonction de ses besoins en ressources. Chaque microservice peut également être déployé indépendamment, et dans l’idéal, ces déploiements doivent entraîner aucun temps d’arrêt système.

Passerelle d’API

L’application eShopOnContainers a plusieurs clients frontaux et plusieurs services principaux différents. Il n’existe aucune correspondance un-à-un entre les applications clientes et les microservices qui les prennent en charge. Dans ce scénario, il peut y avoir beaucoup de complexité lors de l’écriture de logiciels clients à interfacer avec les différents services back-end de manière sécurisée. Chaque client doit résoudre cette complexité par elle-même, ce qui entraîne une duplication et de nombreux endroits où effectuer des mises à jour à mesure que les services changent ou que de nouvelles stratégies sont implémentées.

Gestion des API Azure (APIM) aide les organisations à publier des API de manière cohérente et gérable. APIM se compose de trois composants : la passerelle API et le portail d’administration (portail Azure) et un portail de développement.

La passerelle API accepte les appels d’API et les route vers l’API principale appropriée. Il peut également fournir des services supplémentaires tels que la vérification des clés API ou des jetons JWT et la transformation d’API à la volée sans modification de code (par exemple, pour prendre en charge les clients qui attendent une interface plus ancienne).

Le portail Azure est l’endroit où vous définissez le schéma d’API et empaquetez différentes API dans des produits. Vous configurez également l’accès utilisateur, affichez des rapports et configurez des stratégies pour les quotas ou les transformations.

Le portail des développeurs sert de ressource principale pour les développeurs. Il fournit aux développeurs la documentation de l’API, une console de test interactive et des rapports sur leur propre utilisation. Les développeurs utilisent également le portail pour créer et gérer leurs propres comptes, y compris la prise en charge des abonnements et des clés API.

À l’aide d’APIM, les applications peuvent exposer plusieurs groupes de services différents, chacun fournissant un back-end pour un client frontal particulier. APIM est recommandé pour les scénarios complexes. Pour des besoins plus simples, la passerelle API légère Ocelot peut être utilisée. L’application eShopOnContainers utilise Ocelot en raison de sa simplicité et parce qu’elle peut être déployée dans le même environnement d’application que l’application elle-même. En savoir plus sur eShopOnContainers, APIM et Ocelot.

Une autre option si votre application utilise AKS consiste à déployer le contrôleur d’entrée de passerelle Azure en tant que pod au sein de votre cluster AKS. Cette approche permet à votre cluster d’intégrer une passerelle Azure Application Gateway, ce qui permet à la passerelle d’équilibrer la charge du trafic vers les pods AKS. En savoir plus sur le contrôleur d’entrée de passerelle Azure pour AKS.

Données

Les différents services principaux utilisés par eShopOnContainers ont des exigences de stockage différentes. Plusieurs microservices utilisent des bases de données SQL Server. Le microservice Basket tire parti d’un cache Redis pour sa persistance. Le microservice Locations attend une API MongoDB pour ses données. Azure prend en charge chacun de ces formats de données.

Pour la prise en charge de la base de données SQL Server, Azure propose des produits pour tous les éléments des bases de données uniques jusqu’aux pools élastiques SQL Database hautement évolutifs. Les microservices individuels peuvent être configurés pour communiquer avec leurs propres bases de données SQL Server individuelles rapidement et facilement. Ces bases de données peuvent être mises à l’échelle si nécessaire pour prendre en charge chaque microservice distinct en fonction de ses besoins.

L’application eShopOnContainers stocke le panier d’achat actuel de l’utilisateur entre les demandes. Cet aspect est géré par le microservice Basket qui stocke les données dans un cache Redis. En développement, ce cache peut être déployé dans un conteneur, tandis qu’en production, il peut utiliser Le Cache Azure pour Redis. Azure Cache pour Redis est un service entièrement géré offrant des performances et une fiabilité élevées sans avoir à déployer et gérer des instances ou des conteneurs Redis.

Le microservice Locations utilise une base de données NoSQL MongoDB pour sa persistance. Pendant le développement, la base de données peut être déployée dans son propre conteneur, tandis qu’en production, le service peut tirer parti de l’API Azure Cosmos DB pour MongoDB. L’un des avantages d’Azure Cosmos DB est sa capacité à tirer parti de plusieurs protocoles de communication différents, notamment une API SQL et des API NoSQL courantes, notamment MongoDB, Cassandra, Gremlin et Stockage Table Azure. Azure Cosmos DB offre une base de données entièrement gérée et distribuée mondialement en tant que service qui peut être mise à l’échelle pour répondre aux besoins des services qui l’utilisent.

Les données distribuées dans les applications natives cloud sont abordées plus en détail dans le chapitre 5.

Bus d'événements

L’application utilise des événements pour communiquer les modifications entre différents services. Cette fonctionnalité peut être implémentée avec différentes implémentations, et localement, l’application eShopOnContainers utilise RabbitMQ. Lorsqu’elle est hébergée dans Azure, l’application tire parti d’Azure Service Bus pour sa messagerie. Azure Service Bus est un répartiteur de messages d’intégration entièrement managé qui permet aux applications et aux services de communiquer entre eux de manière découplée, fiable et asynchrone. Azure Service Bus prend en charge des files d’attente individuelles ainsi que des sujets distincts pour prendre en charge les scénarios de publication-souscription. L’application eShopOnContainers tirerait parti des rubriques avec Azure Service Bus pour prendre en charge la distribution de messages d’un microservice à tout autre microservice qui aurait besoin de réagir à un message donné.

Résilience

Une fois déployée en production, l’application eShopOnContainers peut tirer parti de plusieurs services Azure disponibles pour améliorer sa résilience. L’application publie des contrôles d’intégrité, qui peuvent être intégrés à Application Insights pour fournir des rapports et des alertes en fonction de la disponibilité de l’application. Les ressources Azure fournissent également des journaux de diagnostic qui peuvent être utilisés pour identifier et corriger les bogues et les problèmes de performances. Les journaux des ressources fournissent des informations détaillées sur le moment et la façon dont différentes ressources Azure sont utilisées par l’application. Vous en apprendrez davantage sur les fonctionnalités de résilience native dans le cloud dans le chapitre 6.