Vue d’ensemble de Spring Cloud Gateway – Grape Up

Dans ma vie, j’ai eu l’opportunité de travailler dans une équipe qui maintient le système Api Gateway. La création de ce système a commencé il y a plus de 15 ans, il y a donc assez longtemps compte tenu du rythme d’évolution de la technologie. Le système a été mis à jour vers Java 8, développé sur un serveur léger qui est Tomcat Apache, et contenait divers tests : intégration, performances, de bout en bout et test unitaire. Bien que la passerelle ait été entretenue avec diligence, il est évident que son cœur contient de nombreuses implémentations de traitement des requêtes telles que le routage, la modification des en-têtes, la conversion de la charge utile des requêtes, qui peuvent aujourd’hui être fournies par un framework comme Spring Cloud Gateway. Dans cet article, je vais montrer les avantages du cadre mentionné ci-dessus.

Les principaux avantages fournis par Spring Cloud Gateway :

• prise en charge du modèle de programmation réactif : point de terminaison http réactif, socket Web réactif
• configurer le traitement des requêtes (routes, filtres, prédicats) par du code java ou encore un autre langage de balisage (YAML)
• rechargement dynamique de la configuration sans redémarrage du serveur (intégration avec Spring Cloud Config Server)
• prise en charge de SSL
• API de l’actionneur
• passerelle d’intégration au mécanisme de découverte de service
• mécanismes d’équilibrage de charge
• mécanismes de limitation de débit (étranglement)
• mécanisme des disjoncteurs
• intégration avec Oauth2 en raison de la fourniture de fonctionnalités de sécurité

Ces fonctionnalités mentionnées ci-dessus ont un impact énorme sur la rapidité et la facilité de création d’un système de passerelle API. Dans cet article, je vais décrire quelques-unes de ces fonctionnalités.

En raison du logiciel, le monde est le monde de la pratique et les systèmes ne peuvent fonctionner qu’en théorie, j’ai décidé de créer un environnement de laboratoire pour prouver la valeur pratique de l’écosystème Cloud Spring Gateway. Ci-dessous, je mets une architecture de l’environnement de laboratoire :

Éléments de construction de Spring Cloud Gateway

La première fonctionnalité de Spring Cloud Gateway que je vais décrire est une configuration de traitement des requêtes. Il peut être considéré comme le cœur de la passerelle. C’est l’une des principales parties et responsabilités. Comme je l’ai mentionné plus tôt, cette logique peut être créée par du code Java ou par des fichiers YAML. Ci-dessous, j’ajoute un exemple de configuration en YAML et en code Java. Les blocs de construction de base utilisés pour créer la logique de traitement sont :

• Prédicats – correspondent aux requêtes en fonction de leur fonctionnalité (chemin, nom d’hôte, en-têtes, cookies, requête)
• Filtres – traitez et modifiez les demandes de différentes manières. Peuvent être divisés en fonction de leur objectif :
• filtre de passerelle – modifier la requête http entrante ou la réponse http sortante
• filtre global – filtres spéciaux s’appliquant à toutes les routes tant que certaines conditions sont remplies

Vous trouverez des détails sur les différentes implémentations des composants de construction d’évasion dans les documents : https://cloud.spring.io/spring-cloud-gateway/reference/html/.

Exemple de configuration de route dans Java DSL :

Configuration même route avec YAML :

Spring Cloud Config Server intégré à Gateway

Quelqu’un n’est peut-être pas un grand fan du langage YAML, mais l’utiliser ici peut avoir un gros avantage dans ce cas. Il est possible de stocker des fichiers de configuration dans Spring Cloud Config Server et une fois la configuration modifiée, elle peut être rechargée dynamiquement. Pour effectuer ce processus, nous devons utiliser le point de terminaison Actuator Api.
Le rechargement dynamique de la configuration de la passerelle montre l’image ci-dessous. Les quatre premières étapes montrent le traitement des demandes cohérent avec la configuration actuelle. La passerelle transmet les requêtes du client au point de terminaison « employés/v1 » du microservice PeopleOps (étape 2). Ensuite, la passerelle renvoie la réponse du microservice PeopleOps à l’application cliente (étape 4). L’étape suivante consiste à mettre à jour la configuration. Une fois que Config Server utilise le référentiel git pour stocker la configuration, la mise à jour signifie valider les modifications récentes apportées au fichier application.yaml (étape 5 dans l’image). Après avoir poussé de nouveaux commits vers le dépôt, il est nécessaire d’envoyer une requête GET sur le bon point de terminaison de l’actionneur (étape 6). Ces deux étapes suffisent pour que les demandes des clients soient transmises à un nouveau point de terminaison dans PeopleOps Microservice (étapes 7, 8, 9, 10).

Flux Web réactif dans Api Gateway

Comme le dit la documentation, Spring Cloud Gateway est construit sur Spring Web Flux. La programmation réactive gagne en popularité parmi les développeurs Java. Spring Gateway propose donc de créer des applications entièrement réactives. Dans mon laboratoire, j’ai créé Controller dans un microservice Marketing qui génère des données d’article de manière répétitive toutes les 4 secondes. Le navigateur observe ce flux de requêtes. L’image ci-dessous montre que 6 blocs de données ont été reçus en 24 secondes.

Je ne plonge pas profondément dans le style de programmation réactif, il y a beaucoup d’articles sur les avantages et les différences entre les styles de programmation réactifs et autres. Je viens de mettre la mise en œuvre d’un endpoint réactif simple dans le microservice Marketing ci-dessous. Il est également accessible sur GitHub : https://github.com/chrrono/Spring-Cloud-Gateway-lab/blob/master/Marketing/src/main/java/com/grapeup/reactive/marketing/MarketingApplication.java

Possibilités de limitation de débit de Gateway

La prochaine fonctionnalité de Spring Cloud Gateway est la mise en œuvre de mécanismes de limitation de débit (throttling). Ce mécanisme a été conçu pour protéger les passerelles du trafic nuisible. L’un des exemples pourrait être une attaque par déni de service distribué (DDoS). Elle consiste à créer un nombre énorme de requêtes par seconde que le système ne peut pas gérer.
Le filtrage des demandes peut être basé sur les principes de l’utilisateur, des champs spéciaux dans les en-têtes ou d’autres règles. Dans les environnements de production, la plupart du temps plusieurs instances de passerelles sont opérationnelles, mais pour Spring Cloud, le framework Gateway n’est pas un obstacle, car il utilise Redis pour stocker des informations sur le nombre de requêtes par clé. Toutes les instances sont connectées à une instance Redis afin que la limitation puisse fonctionner correctement dans un environnement multi-instances.
Pour prouver les avantages de cette fonctionnalité, j’ai configuré la limitation de débit dans Gateway dans l’environnement de laboratoire et créé un test de bout en bout, qui peut être décrit dans l’image ci-dessous.

Les paramètres configurés pour la limitation sont les suivants : DefaultReplenishRate = 4, DefaultBurstCapacity = 8. Cela signifie que les escapades autorisent 4 transactions (requête) par seconde (TPS) pour la clé concrète. La clé dans mon exemple est la valeur d’en-tête du champ “Hôte”, ce qui signifie que les premier et deuxième clients ont une limite de 4TPS séparément. Si la limite est dépassée, la passerelle répond par une réponse http avec le code http 429. Pour cette raison, toutes les demandes du premier client sont transmises au service de production, mais pour le second client, seule la moitié des demandes sont transmises au service de production par la passerelle, et une autre moitié est immédiatement répondue au client avec 429 Http Code .

Si quelqu’un est intéressé par la façon dont je le teste en utilisant Rest Assured, JUnit et Executor Service in Java test est accessible ici : https://github.com/chrrono/Spring-Cloud-Gateway-lab/blob/master/Gateway/src/test/java/com/grapeup/gateway/demo/GatewayApplicationTests.java

Découverte de services

Le prochain sujet d’intégration concerne le mécanisme de découverte de service. La découverte de services est un registre de services. Le démarrage du microservice s’enregistre auprès de Service Discovery et d’autres applications peuvent utiliser son entrée pour trouver et communiquer avec ce microservice. L’intégration de Spring Cloud Gateway avec la découverte de services Eureka est simple. Sans la création d’une configuration concernant le traitement des demandes, les demandes peuvent être transmises de la passerelle à un microservice spécifique et à son point de terminaison concret.

L’image ci-dessous montre toutes les applications d’enregistrement de mon architecture de laboratoire créées grâce à un test pratique de Spring Cloud Gateway. Le microservice “Production” a une entrée pour deux instances. Il s’agit d’une configuration spéciale, qui permet l’équilibrage de charge par une passerelle.

Mention Disjoncteur

Le disjoncteur est un modèle qui est utilisé en cas de panne connecté à un microservice spécifique. Tout ce dont nous avons besoin est de définir les procédures de secours de Spring Gateway. Une fois la connexion interrompue, la demande sera transmise à une nouvelle route. Le disjoncteur offre plus de possibilités, par exemple, une action spéciale en cas de retard du réseau et il peut être configuré dans la passerelle.

Expérimentez par vous-même

Je vous encourage à mener vos propres tests ou à développer un système que je construis, dans votre propre direction. Ci-dessous, il y a deux liens vers les référentiels GitHub :

1. https://github.com/chrrono/config-for-Config-server (Repo pour garder la configuration pour Spring Cloud Config Server)
2. https://github.com/chrrono/Spring-Cloud-Gateway-lab (Tous les codes de microservices et la configuration docker-compose)

Pour établir un environnement local de manière simple, j’ai créé une configuration docker-compose. Voici un lien vers le fichier docker-compose.yml : https://github.com/chrrono/Spring-Cloud-Gateway-lab/blob/master/docker-compose.yml

Tout ce que vous avez à faire est d’installer un docker sur votre machine. J’ai utilisé Docker Desktop sur ma machine Windows. Après avoir exécuté la commande “docker-compose up” à l’emplacement approprié, vous devriez voir tous les serveurs opérationnels :

Pour effectuer certains tests, j’utilise l’application Postman, Google Chrome et mes tests de bout en bout (Rest Assured, JUnit et Executor Service en Java). Faites avec ce code tout ce que vous voulez et autorisez-vous à n’avoir qu’une seule limite : votre imagination 😊

Sommaire

Spring Cloud Gateway est un sujet énorme, sans aucun doute. Dans cet article, je me suis concentré sur la présentation de certains composants de construction de base et sur l’intention générale de la passerelle et de l’interaction avec d’autres services cloud printaniers. J’espère que les lecteurs apprécieront les possibilités et le soin en décrivant le cadre. Si quelqu’un souhaite explorer Spring Cloud Gateway par vous-même, j’ai ajouté des liens vers un référentiel, qui peut être utilisé comme projet modèle pour vos explorations.