Découverte de service vs équilibrage de charge
J'essaie de comprendre dans quel scénario je devrais choisir un registre de services plutôt qu'un équilibreur de charge.
A ma connaissance, les deux solutions couvrent la même fonctionnalité.
Par exemple, si nous considérons consul.io comme une liste de fonctionnalités, nous avons:
- Découverte de service
- Bilan de santé
- Magasin de clés/valeur
- Multi Datacenter
Lorsqu'un équilibreur de charge tel que Amazon ELB , par exemple, a:
- configurable pour accepter uniquement le trafic de votre équilibreur de charge
- accepter le trafic en utilisant les protocoles suivants: HTTP, HTTPS (HTTP sécurisé), TCP et SSL (TCP sécurisé)
- distribuer des demandes aux instances EC2 dans plusieurs zones de disponibilité
- Le nombre de connexions varie en fonction du nombre de demandes simultanées reçues par l'équilibreur de charge.
- configurer les contrôles de santé qu'Elastic Load Balancing utilise pour surveiller la santé des instances EC2 enregistrées avec l'équilibreur de charge afin qu'il puisse envoyer des demandes uniquement aux instances saines
- Vous pouvez utiliser le cryptage de trafic de bout en bout sur les réseaux qui utilisent des connexions sécurisées (HTTPS/SSL).
- [EC2-VPC] Vous pouvez créer un équilibreur de charge Internet, qui prend les demandes des clients par Internet et les achemine vers vos instances EC2, ou un équilibreur de charge interne, qui prend les demandes des clients de votre VPC et les achemine aux instances EC2 dans vos sous-réseaux privés. Les équilibreurs de charge dans EC2-Classic sont toujours connectés à Internet.
- [EC2-Classic] Les équilibreurs de charge pour EC2-Classic prennent en charge les adresses IPv4 et IPv6. Les équilibreurs de charge pour un VPC ne prennent pas en charge les adresses IPv6.
- Vous pouvez surveiller votre équilibreur de charge à l'aide de métriques CloudWatch, de journaux d'accès et d'AWS CloudTrail.
- Vous pouvez associer votre équilibreur de charge Internet à votre nom de domaine.
- etc.
Ainsi, dans ce scénario, je ne comprends pas pourquoi je choisirais quelque chose comme consul.io ou netflix eureka sur Amazon ELB pour la découverte de service.
J'ai l'impression que cela pourrait être dû à la mise en œuvre de découverte de services côté client vs découverte de services côté serveur , mais je ne suis pas tout à fait sûr.
Vous devriez le considérer comme un équilibrage de la charge côté client par rapport à un équilibrage de charge dédié.
Baker Street ( http://bakerstreet.io ) est l’équilibreur de charge côté client; SmartStack ( http://nerds.airbnb.com/smartstack-service-discovery-cloud/ ); ou Consul HA Proxy ( https://hashicorp.com/blog/haproxy-with-consul.html ).
Les LB côté client utilisent un composant de découverte de service (Baker Street utilise un mécanisme de découverte de service de pub/sous-service sans état; SmartStack utilise ZooKeeper; le proxy Consul HA utilise Consul) dans le cadre de leur implémentation, mais fournit la vérification de l'intégrité/la fonctionnalité de bout en bout. vous cherchez probablement.
Le composant Service Discovery a généralement un composant de notification. Ce n'est pas un équilibreur de charge, même si certains en ont la capacité. Il peut notifier les modifications aux clients enregistrés, par exemple, un équilibrage de charge en panne.
Un client peut interroger une découverte de service/registre pour obtenir un équilibreur de charge en cours d'exécution. Considérant qu’un équilibreur de charge ne noit pas un client lorsqu’il est en panne.
AWS ELB et Eureka diffèrent sur de nombreux points:
Services Edge vs services de niveau intermédiaire
AWS ELB est une solution d’équilibrage de charge pour les services Edge exposés au trafic Web des utilisateurs finaux. Eureka répond au besoin d'équilibrage de charge de niveau intermédiaire.
Serveur de niveau intermédiaire désigne un serveur d'applications situé entre la machine de l'utilisateur et le serveur de base de données sur lequel le traitement a lieu. Le serveur de niveau intermédiaire exécute la logique métier.
Tandis que vous pouvez théoriquement placer vos services de niveau intermédiaire derrière AWS ELB, dans EC2 Classic, vous les exposez au monde extérieur, perdant ainsi toute utilité des groupes de sécurité AWS.
Dédié à l'équilibrage de charge côté client
AWS ELB est également une solution classique d’équilibrage de la charge basée sur un proxy, alors qu’Eureka est différent en ce sens que l’équilibrage de la charge s’effectue au niveau instance/serveur/hôte de manière alternée. Les instances de client connaissent toutes les informations sur les serveurs avec lesquels elles doivent parler.
Si vous recherchez une session utilisateur rémanente (toutes les demandes d’un utilisateur au cours de la session sont envoyées à la même instance) en fonction de l’équilibrage de charge proposé par AWS, Eureka ne propose pas de solution immédiate.
Pannes de Load Balancer
Un autre aspect important qui distingue l’équilibrage de la charge basé sur le proxy de l’équilibrage de charge avec Eureka est que votre application peut résister aux pannes des équilibreurs de charge, car les informations concernant les serveurs disponibles sont mises en cache sur le client Eureka.
Cela nécessite une petite quantité de mémoire mais permet d’obtenir une meilleure résilience. Le client Eureka reçoit toutes les informations du registre en une fois et dans les requêtes ultérieures adressées au serveur Eureka, il ne reçoit que le delta, c’est-à-dire les modifications apportées aux informations du registre plutôt que l’ensemble des informations du registre. De plus, les serveurs Eureka peuvent fonctionner en mode cluster, chaque homologue n'étant pas affecté par les performances des autres homologues.
Échelle et commodité
En outre, imaginez des milliers de microservices en cours d’exécution, chacun ayant plusieurs instances. Vous aurez besoin de 1 000 ELB, un pour chaque microservice, ou de quelque chose comme HAProxy situé derrière l'ELB pour prendre des décisions concernant la couche 7 en fonction du nom d'hôte, etc., puis transférer le trafic à un sous-ensemble d'instances. Avec Eureka, vous ne jouez qu'avec le nom de l'application qui est beaucoup moins compliqué.