Mappage d’eShopOnContainers aux services Azure

Même si ce n’est pas une obligation, Azure convient pour prendre en charge eShopOnContainers parce que le projet a été conçu pour être une application native cloud. L’application est générée avec .NET, donc elle peut 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, qui vont 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 une communication basée sur messages. L’application prend également en charge plusieurs plateformes pour les clients, car elle adopte HTTP comme protocole de communication standard et contient des applications mobiles ASP.NET Core et Xamarin qui s’exécutent sur des plateformes Android, iOS et Windows.

L’architecture de l’application est illustrée dans la figure 2-5. À gauche se trouvent les applications clientes, divisées en versions mobile, web traditionnelle et application monopage (SPA) web. À droite se trouvent les composants côté serveur qui constituent 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 en jaune. Cette application et les applications mobiles et SPA web communiquent avec des microservices individuels via une ou plusieurs passerelles API. Les passerelles API suivent le modèle « back-ends for front-ends » (BFF), ce qui signifie que chaque passerelle est conçue pour prendre en charge un client front-end donné. Les microservices individuels sont listés à droite des passerelles API et incluent à la fois 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. Tout à droite se trouve le bus d’événements du système, qui est utilisé pour la communication entre les microservices.

Figure 2-5. Architecture d’eShopOnContainers.

Il est facile de mapper tous les composants côté serveur de cette architecture aux services Azure.

Orchestration et clustering de conteneurs

Les services de l’application hébergés par un conteneur, que ce soit les applications ASP.NET Core MVC ou les microservices Catalog et Ordering individuels, peuvent être hébergés et managé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 dans des environnements de préproduction 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 les clusters individuels de conteneurs. L’application déploie des conteneurs distincts pour chaque microservice du cluster AKS, comme illustré dans le schéma de l’architecture ci-dessus. Cette approche permet à chaque service individuel de se mettre à l’échelle 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 zéro temps d’arrêt système.

API Gateway

L’application eShopOnContainers a plusieurs clients front-end et plusieurs services back-end différents. Il n’y a 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épondre seul à cette complexité, ce qui entraîne des duplications et de nombreux emplacements où effectuer des mises à jour à mesure que les services changent ou que de nouvelles stratégies sont implémentées.

La Gestion des API Azure (APIM, Azure API Management) permet aux organisations de publier des API de manière cohérente et gérable. APIM est constitué de trois composants : la passerelle API, le portail d’administration (le portail Azure) et un portail des développeurs.

La passerelle API accepte les appels d’API et les achemine vers l’API back-end appropriée. Elle 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 du code (par exemple, pour accommoder les clients avec une interface plus ancienne).

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

Le portail des développeurs fait office de ressource principale pour les développeurs. Il fournit aux développeurs la documentation des 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, notamment les abonnements et la prise en charge des clés API.

Avec APIM, les applications peuvent exposer plusieurs groupes de services différents, chacun fournissant un back-end pour un client front-end donné. 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 parce qu’elle est simple et 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 dans votre cluster AKS. Avec cette approche, votre cluster est intégré à une instance Azure Application Gateway, ce qui permet à la passerelle d’équilibrer la charge du trafic sur les pods AKS. En savoir plus sur le contrôleur d’entrée de passerelle Azure pour AKS.

Données

Les différents services back-end utilisés par eShopOnContainers ont des besoins de stockage variés. 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 des bases de données SQL Server, Azure propose des produits pour tout, des bases de données uniques aux très scalables pools élastiques SQL Database. Les microservices individuels peuvent être configurés pour communiquer de façon simple et rapide avec leurs propres bases de données SQL Server. Ces bases de données peuvent être mises à l’échelle selon les besoins 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 Azure Cache pour Redis. Azure Cache pour Redis est un service complètement managé qui offre hautes performances et fiabilité sans avoir à déployer et gérer des conteneurs ou des instances Redis vous-même.

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 comme MongoDB, Cassandra, Gremlin et Stockage Table Azure. Azure Cosmos DB offre une base de données complètement managée et distribuée à l’échelle mondiale 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 les différents services. Cette fonctionnalité peut être implémentée de différentes manières. En local, l’application eShopOnContainers utilise RabbitMQ. Lorsqu’elle est hébergée dans Azure, l’application tire parti d’Azure Service Bus pour ses messages. Azure Service Bus est un répartiteur de messages d’intégration complètement managé qui permet aux applications et 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 rubriques distinctes pour prendre en charge les scénarios éditeurs-abonnés. 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ées à Application Insights pour fournir des rapports et des alertes en fonction de sa disponibilité. 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 de ressources fournissent des informations détaillées sur quand et comment différentes ressources Azure sont utilisées par l’application. Vous en apprendrez davantage sur les fonctionnalités de résilience natives cloud dans le chapitre 6.