Les Edge Microservices sont des microservices spécialisés dans l'orchestration des microservices centraux responsables de la logique de l'application.
Les Edge Microservices les plus populaires sont ceux publiés et utilisés par Netflix pour sa plateforme. Ils sont en grande partie regroupés sous Spring Cloud, et disposent de fonctionnalités pour fonctionner nativement ensemble.
Ces Edge Microservices répondent chacun à un problème particulier. En voici quelques-uns auxquels nous allons nous attaquer dans les prochains chapitres.
La configuration
Dans une application grandeur nature, les microservices et leurs différentes instances reposent énormément sur des fichiers de configuration tels que application.properties.
Imaginez que vous souhaitiez changer un paramètre concernant une application en production. Il faut alors arrêter toutes les instances du microservice, puis modifier et redéployer, en bloquant, de fait, l'application.
Comment éviter de bloquer l'application à chaque mise à jour de la configuration ?
La solution est Spring Cloud Config. Il va permettre de centraliser tous les fichiers de configuration dans un dépôt GIT, et se positionner comme serveur de fichiers de configuration.
Ainsi, quand vous mettez à jour un fichier de configuration dans votre dépôt GIT, Spring Cloud Config se met à servir cette nouvelle version, obligeant le microservice à le prendre en compte à la volée.
La découvrabilité
En cas de grande charge sur notre application, nous souhaitons ajouter plusieurs instances d'un microservice.
Comment garder la trace des URL des différentes instances disponibles, ainsi que leurs états ?
Pour répondre à ce problème, Eureka se propose en naming server. Grâce à une simple annotation, toute nouvelle instance de votre microservice va être enregistrée auprès d'Eureka.
Votre client n'a plus qu'à consulter ce registre pour trouver les instances disponibles d'un microservice donné.
Eureka s'occupe également de vérifier régulièrement si chaque instance enregistrée est toujours disponible, afin de mettre à jour son registre en éliminant celles qui n'existent plus.
L'équilibrage de la charge (Load Balancing)
Nous souhaitons que nos microservices soient les plus découplés et autonomes possible. Quand nous avons plusieurs instances d'un microservice, il faut équilibrer la charge entre celles-ci.
On ne peut pas utiliser un équilibreur de charge central classique, car celui-ci limiterait la résilience de notre application en créant un point de centralisation.
Comment permettre à chaque microservice de faire appel à un autre directement, sans être dépendant d'un Load Balancer central ?
La réponse est Ribbon : ce load Balancer côté client est capable d'indiquer directement, depuis le microservice, quelle instance du microservice distant appeler.
API Gateway
Imaginez que nous développions notre application e-commerce dans le cadre d'une véritable application professionnelle. L'affichage d'une fiche produit reposera alors sur des dizaines de microservices. Il y aura par exemple des microservices pour : les images, le pricing, les recommandations, les textes et caractéristiques des produits, un comparateur, la livraison, etc.
Quand notre client voudra afficher cette fiche produit, il devra faire appel à tous ces microservices. Cela implique de les identifier, de repérer leurs instances, de s'authentifier auprès de chacun d'entre eux pour accéder aux ressources, de transformer le résultat reçu pour qu'il soit adapté au type d'appareil, etc.
Avec tout cela, vous imaginez que le client deviendra méchamment complexe, d'autant plus qu'il ne s'occupe pas uniquement des fiches produits !
Comment résoudre cette complexité ?
La solution est d'installer un point d'entrée unique vers les microservices. C'est ce qu'on appelle une API Gateway.
L'API Gateway que nous allons utiliser s'appelle ZUUL. Elle va nous donner énormément d'avantages, notamment en ce qui concerne la sécurité : plus besoin de sécuriser chaque microservice, il suffit d'imposer les règles d'authentification et de sécurité à ZUUL.
Le traçage des requêtes
Reprenons l'exemple de la fiche produit : quand vous demandez celle-ci, votre requête doit traverser plusieurs microservices avant d'aboutir. Pensez, par exemple, à notre application Mcommerce, dans laquelle la requête de demande de paiement envoyée par le client déclenche dans le Microservice-produits une autre requête vers le Microservice-commandes, afin de mettre à jour le statut de la commande.
Si une erreur vous est retournée, il est difficile de savoir si elle s'est produite au niveau du Microservice-produits ou au niveau du Microservice-commandes.
Imaginez maintenant le problème quand votre requête traverse 25 microservices avant d'aboutir !
Comment identifier le microservice posant problème ?
Zipkin va vous permettre de suivre vos requêtes de microservice en microservice, et de consulter les différentes réponses et interactions afin de cibler directement le problème.
En résumé
Zipkin permet de tracer les requêtes.
Zuul est un proxy inverse qui sert de point d’entrée à nos applications.
Dans le prochain chapitre, nous allons voir comment faire pour externaliser la configuration de vos microservices. Vous êtes prêt ? Allons-y !
