Modèle de routage de passerelle

Acheminez les requêtes vers plusieurs services ou instances de service à l’aide d’un seul point de terminaison. Ce modèle est utile dans les situations suivantes :

• Exposer plusieurs services sur un seul point de terminaison et quand vous voulez créer un routage vers le service approprié basé sur la requête
• Exposer plusieurs instances du même service sur un point de terminaison unique à des fins d’équilibrage de charge ou de disponibilité
• Exposer différentes versions du même service sur un point de terminaison unique et acheminer le trafic entre les différentes versions

Contexte et problème

Lorsqu’un client doit consommer plusieurs services, plusieurs instances de service ou une combinaison des deux, le client doit être mis à jour lorsque les services sont ajoutés ou supprimés. Examinez les scénarios suivants.

• Plusieurs services disparates - une application de e-commerce peut fournir des services comme faire des recherches, laisser des avis, remplir son panier, effectuer des paiements et consulter l’historique des commandes. Chaque service possède une API différente avec laquelle le client doit interagir, et le client doit avoir des informations sur tous les points de terminaison pour pouvoir se connecter aux services. En cas de modification d’une API, le client doit également être mis à jour. Si vous refactorisez un service en deux ou plusieurs services distincts, le code doit être modifié dans le service et le client.
• Plusieurs instances du même service : le système peut nécessiter l’exécution de plusieurs instances du même service dans les mêmes régions ou différentes. L’exécution de plusieurs instances peut être effectuée à des fins d’équilibrage de charge ou pour répondre aux exigences de disponibilité. Chaque fois qu’une instance est mise à jour pour correspondre à la demande, le client doit être mis à jour.
• Plusieurs versions du même service : dans le cadre de la stratégie de déploiement, de nouvelles versions d’un service peuvent être déployées côte à côte. Il s’agit des déploiements bleus verts. Dans ces scénarios, le client doit être mis à jour chaque fois qu’il y a des modifications apportées au pourcentage de trafic acheminé vers la nouvelle version et le point de terminaison existant.

Solution

Placez une passerelle devant un ensemble d’applications, de services ou de déploiements. Utilisez le routage de couche Application 7 pour acheminer la requête vers les instances appropriées.

Avec ce modèle, l’application cliente doit uniquement connaître des informations sur un point de terminaison unique et communiquer avec celui-ci. Voici comment le modèle de routage de passerelle traite les trois scénarios décrits dans la section contexte et problème.

Plusieurs services disparates

Le modèle de routage de passerelle est utile dans ce scénario où un client consomme plusieurs services. Si un service est consolidé, décomposé ou remplacé, le client ne doit pas nécessairement être mis à jour. Il peut continuer à envoyer des requêtes à la passerelle et seul le routage change.

Une passerelle vous permet également d’extraire les services principaux à partir des clients, ce qui simplifie les appels des clients lors de l’application des modifications dans les services principaux derrière la passerelle. Les appels des clients peuvent être acheminés vers n’importe quels services nécessaires pour gérer le comportement du client attendu, ce qui vous permet d’ajouter, de fractionner et de réorganiser des services derrière la passerelle sans modifier le client.

Plusieurs instances du même service

L’élasticité est essentielle dans le cloud computing. Les services peuvent être mis en place pour répondre à une demande croissante ou diminuer lorsque la demande est faible pour économiser de l’argent. La complexité de l’inscription et de l’annulation de l’inscription des instances de service est encapsulée dans la passerelle. Le client n’est pas conscient d’une augmentation ou d’une diminution du nombre de services.

Les instances de service peuvent être déployées dans une ou plusieurs régions. Le modèle Geode détaille la façon dont un déploiement multirégion, actif-actif peut améliorer la latence et augmenter la disponibilité d’un service.

Plusieurs versions du même service

Ce modèle peut également être utilisé pour les déploiements en vous permettant de gérer la façon dont les mises à jour sont déployées aux utilisateurs. Lorsqu’une nouvelle version de votre service est déployée, elle peut être déployée en parallèle avec la version existante. Le routage vous permet de contrôler quelle version du service est présentée aux clients, ce qui vous donne la possibilité d’utiliser diverses stratégies de mise en production (déploiement de mises à jour incrémentielles, parallèles ou complètes). Les problèmes détectés après avoir déployé le nouveau service peuvent être corrigés rapidement en modifiant la configuration au niveau de la passerelle, sans affecter les clients.

Problèmes et considérations

• Le service de passerelle peut introduire un point de défaillance unique. Vérifiez qu’il est correctement conçu pour répondre à vos besoins de disponibilité. Pensez aux capacités de tolérance de panne et de résilience lors de l’implémentation.
• Le service de passerelle peut introduire un goulot d’étranglement. Vérifiez que les performances de la passerelle sont appropriées pour gérer la charge et qu’elle peut facilement évoluer en fonction de vos envies de croissance futures.
• Effectuez un test de charge sur la passerelle pour vous assurer de ne pas introduire d’échecs en cascade dans les services.
• Le routage de passerelle est au niveau 7. Il peut être basé sur IP, port, en-tête ou URL.
• Les services de passerelle peuvent être globaux ou régionaux. Azure Front Door est une passerelle mondiale, tandis que Azure Application Gateway est régional. Utilisez une passerelle globale si votre solution nécessite des déploiements multirégions de services. Envisagez d’utiliser Application Gateway si vous disposez d’une charge de travail régionale qui nécessite un contrôle précis de l’équilibrage du trafic. Par exemple, vous souhaitez équilibrer le trafic entre les machines virtuelles.
• Le service de passerelle est le point de terminaison public pour les services qu’il se trouve devant. Envisagez de limiter l’accès au réseau public aux services principaux, en rendant les services accessibles uniquement via la passerelle ou via un réseau virtuel privé.

Quand utiliser ce modèle

Utilisez ce modèle dans les situations suivantes :

• Un client doit utiliser plusieurs services accessibles derrière une passerelle.
• Vous souhaitez simplifier les applications clientes à l’aide d’un seul point de terminaison.
• Vous avez besoin d’acheminer les requêtes de points de terminaison adressables externes vers des points de terminaison virtuels internes, par exemple exposer des ports sur une machine virtuelle vers des adresses IP virtuelles de cluster.
• Un client doit consommer des services s’exécutant dans plusieurs régions pour bénéficier d’une latence ou d’un avantage de disponibilité.
• Un client doit consommer un nombre variable d’instances de service.
• Vous souhaitez implémenter une stratégie de déploiement où les clients accèdent simultanément à plusieurs versions du service.

Ce modèle peut ne pas convenir lorsque vous avez une application simple qui utilise uniquement un ou deux services.

Conception de la charge de travail

Un architecte doit évaluer la façon dont le modèle de routage de passerelle 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 :

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.

Exemple

Avec Nginx en tant que routeur, voici un exemple de fichier de configuration simple d’un serveur qui achemine des requêtes pour des applications se trouvant sur différents répertoires virtuels vers des machines distinctes au niveau du back end.

server {
    listen 80;
    server_name domain.com;

    location /app1 {
        proxy_pass http://10.0.3.10:80;
    }

    location /app2 {
        proxy_pass http://10.0.3.20:80;
    }

    location /app3 {
        proxy_pass http://10.0.3.30:80;
    }
}

Les services Azure suivants peuvent être utilisés pour implémenter le modèle de routage de passerelle :

• Une instance Application Gateway, qui fournit un routage régional de couche 7.
• Une instance Azure Front Door, qui fournit un routage global de couche 7.

Ressources associées

• Backends for Frontends pattern (Modèle de services principaux destinés aux frontaux)
• Gateway Aggregation pattern (Modèle d’agrégation de passerelle)
• Modèle de déchargement de passerelle