Spring Boot - Différents systèmes (eureka, zuul, ribbon, nginx,) utilisés pour quoi?

Question

J'ai travaillé avec spring et j'aimerais maintenant apprendre spring boot et microservices. Je comprends ce qu'est microservice et comment cela fonctionne. En parcourant les documents, je suis tombé sur de nombreuses choses utilisées pour développer microservices avec spring boot que je suis très confus.

J'ai énuméré les systèmes ci-dessous et les questions:

Netflix Eureka - Je comprends qu'il s'agit d'une plateforme de découverte de services. Tous les services seront enregistrés sur le serveur eureka et tous les microservices sont eureka clients. Maintenant, mon doute est que, sans avoir de passerelle API, y a-t-il une utilité avec ce registre de service? Il s'agit de comprendre l'utilisation réelle du registre de services.
passerelle ZUULApi - Je comprends que ZUUL peut être utilisé comme passerelle API qui est essentiellement un équilibreur de charge, qui appelle le microservice approprié correspondant à l'URL de la demande. Cette hypothèse est-elle correcte? la passerelle API interagira-t-elle avec Eureka pour obtenir le microservice approprié?
NGINX - J'ai lu NGINX peut également être utilisé comme passerelle API? Est-ce possible? Aussi, j'ai lu certains endroits où, comme NGINX, peuvent être utilisés comme registre de service, c'est-à-dire comme alternative à Eureka! Alors, qui a raison? Passerelle Api ou registre de service ou les deux? Je sais que nginx est un serveur Web et reverse proxies peut être puissamment configuré.
AWS api gateway - Est-ce que cela peut également être utilisé comme alternative pour ZUUL?
RUBAN - pour quoi ribbon est utilisé? Je n'ai pas compris!
AWS ALB - Cela peut également être utilisé pour l'équilibrage de charge. Nous avons donc besoin de ZUUL si nous avons AWS ALB?

Veuillez aider

vipin cp · Accepted Answer

Différents systèmes pouvant être utilisés pour le fonctionnement de microservices, accompagnés d'une botte à ressort:

Eureka: Probablement le premier microservice à être UP. Eureka est un registre de services, cela signifie qu'il sait quels microservices sont en cours d'exécution et dans quel port. Eureka se déploie en tant qu'application sperate et nous pouvons utiliser @EnableEurekaServer annotation avec @SpringBootAPplication pour faire de cette application un serveur eureka. Donc, notre registre de services eureka est UP et fonctionne. Désormais, tous les microservices seront enregistrés sur ce serveur eureka en utilisant @EnableDiscoveryClient annotation avec @SpringBootAPplication dans tous les microservices déployés.
Zuul: ZUUL est un load balancer, routing application et reverse proxy serveur également. C'est avant d'utiliser Apache pour les choses de proxy inverse, maintenant, pour les microservices, nous pouvons utiliser ZUUL. L'avantage est que, dans ZUUL, nous pouvons définir des configurations par programmation, comme si/client/* vient sur ce microservice comme ça. ZUUL peut également servir d'équilibreur de charge, qui choisira le microservice approprié à la manière d'un round robin. SO comment le ZUUL connaît-il les détails des microservices, la réponse est eureka. Cela fonctionnera avec eureka pour obtenir les détails du microservice. Et en fait, ce ZUUL est aussi un Eureka client où nous devons marquer en utilisant @EnableDiscoveryClient, c'est ainsi que ces 2 applications (Eureka et zuul) se sont liées.
Ruban: Utilisation du ruban pour l'équilibrage de charge. Ceci est déjà disponible dans ZUUL, dans lequel zuul utilise le ruban pour l'équilibrage de charge. Les microservices sont identifiés par nom-service dans le fichier de propriétés. Si nous exécutons 2 instances d'un microservice dans un port différent, cela sera identifié par Eureka et avec Ribbon (Inside zuul), les demandes seront redirigées de manière équilibrée.
Aws ALB, NGINX, passerelle AWS Api etc: Il existe des alternatives pour toutes les choses mentionnées ci-dessus. Aws possède son propre équilibreur de charge, découverte de service, passerelle api, etc. Non seulement AWS toutes les plates-formes cloud, comme Azure, en ont. Cela dépend de celui à utiliser.
Ajout d'une question générale également, Comment ces microservices se communiquent: En utilisant Resttemplate ou Feignclient l'API réelle de repos peut être appelée ou des files d'attente de messages comme Rabbit MQ etc peut être utilisé.

Jose Martinez · Answer

sans avoir une passerelle API est-il utile avec ce registre de services?

Oui. Par exemple, vous pouvez l'utiliser pour localiser (IP et port) tous vos microservices. Cela est pratique pour le travail de type devops. Par exemple, sur un projet sur lequel j'ai travaillé, nous avons utilisé Eureka pour trouver toutes les instances de nos microservices et les cingler pour leur état (/ health,/info).

Je comprends que ZUUL peut être utilisé comme passerelle API qui est essentiellement un équilibreur de charge, qui appelle le microservice approprié correspondant à l'URL de demande. Cette hypothèse est-elle correcte?

Oui, mais cela peut faire beaucoup plus. Essentiellement parce que Zuul est plus un framework/bibliothèque que vous transformez en microservice, vous pouvez le coder pour implémenter tout type de logique de routage que vous pouvez trouver. Il est très puissant en ce sens. Par exemple, supposons que vous souhaitiez modifier la façon dont vous routez en fonction de l'heure de la journée ou de tout autre facteur externe, avec Zuul, vous pouvez le faire.

la passerelle API interagira-t-elle avec Eureka pour obtenir le microservice approprié?

Oui. Vous configurez Zuul pour pointer vers Eureka. Il devient un client d'Eureka et s'abonne même à Eureka pour les mises à jour en temps réel (que les instances ont rejoint ou quitté).

J'ai lu que NGINX peut également être utilisé comme passerelle API? J'ai également lu certains endroits où NGINX peut être utilisé comme registre de services, c'est-à-dire comme alternative à Eureka! Alors, qui a raison? Passerelle Api ou registre de service ou les deux?

Nginx est assez puissant et peut faire un travail de type passerelle API. Mais il existe quelques différences majeures. AFAIK, les microservices ne peuvent pas s'enregistrer dynamiquement avec Nginx, veuillez me corriger si je me trompe ... comme ils le peuvent avec Eureka. Deuxièmement, même si je sais que Nginx est hautement (très hautement) configurable, je soupçonne que ses capacités de configuration ne sont pas proches des capacités de routage de Zuul (en raison de la mise à disposition de la langue Java Java dans Zuul pour codez votre logique de routage). Il peut arriver que des solutions de découverte de service fonctionnent avec Nginx. Nginx prendra donc en charge le routage, mais la découverte de service nécessitera toujours une solution.

Est-ce que cela peut également être utilisé comme alternative à ZUUL?

Oui, AWS API Gateway peut être utilisé comme remplacement Zuul. Le problème ici, tout comme Nginx, est la découverte de services. AWS API Gateway vous permet d'appliquer une logique à votre routage ... mais pas aussi ouvert que Zuul.

pour quel ruban est utilisé?

Bien que vous puissiez utiliser la bibliothèque de ruban directement, considérez-la comme une dépendance interne de Zuul. Cela aide Zuul à faire l'équilibrage de charge simple qu'il fait. Veuillez noter que ce projet est en mode maintenance et n'est plus recommandé.

Cela peut également être utilisé pour l'équilibrage de charge. Ainsi avons-nous besoin de ZUUL si nous avons AWS ALB?

Vous pouvez utiliser ALB avec ECS (service de conteneurs élastiques) pour remplacer Eureka/Zuul. ECS s'occupera du service découvert pour vous et mappera toutes les instances d'un service particulier à un groupe cible. Votre table de routage ALB peut ensuite être acheminée vers des groupes cibles en fonction de règles de routage simples. Les règles de routage dans ALB sont cependant très simples, mais s'améliorent avec le temps.