Service Discovery vs Load Balancing

Question

Ich versuche zu verstehen, in welchem ​​Szenario ich eine Service-Registrierung über einen Lastenausgleich auswählen sollte.

Aus meiner Sicht decken beide Lösungen die gleiche Funktionalität ab.

Zum Beispiel, wenn wir consul.io als Feature-Liste betrachten wir haben:

• Service Discovery
• Health Checking
• Schlüssel/Wert-Shop
• Multi Datacenter

Wo ein Load Balancer wie Amazon ELB zum Beispiel hat:

• konfigurierbare Datenverkehr zu akzeptieren nur von Ihrem Lastenausgleich
• akzeptiert Verkehr folgende Protokolle: HTTP, HTTPS (Secure HTTP), TCP und SSL (Secure TCP)
• verteilen Anforderungen an EC2-Instanzen in mehreren Availability Zones
• Die Anzahl der Verbindungen skaliert mit der Anzahl gleichzeitiger Anfragen, die der Load Balancer empfängt
• Konfigurieren Sie die Systemdiagnosen, die der Elastic Load Balancing zum Überwachen des Status der EC2-Instanzen verwendet registriert mit dem Load Balancer, so dass es Anfragen nur an die fehlerfreien Instanzen senden kann
• Sie können die Ende-zu-Ende-Verkehrsverschlüsselung in solchen Netzwerken verwenden, die sichere (HTTPS/SSL) Verbindungen
[EC2-VPC] Sie verwenden Sie können ein internetbasiertes Lastenausgleichsmodul erstellen, das Anfragen von Clients über das Internet entgegennimmt und an Ihre EC2-Instances weiterleitet, oder ein internes Lastenausgleichsmodul, das Anforderungen von Clients in Ihrer VPC entgegennimmt und diese an EC2-Instanzen in Ihrem privaten Computer weiterleitet Subnetze. Load Balancer in EC2-Classic sind immer mit dem Internet verbunden.
• [EC2-Classic] Load Balancer für EC2-Classic unterstützen sowohl IPv4- als auch IPv6-Adressen. Load Balancer für eine VPC unterstützen keine IPv6-Adressen.
• Sie können Ihren Lastenausgleich mithilfe von CloudWatch-Messwerten, Zugriffsprotokollen und AWS CloudTrail überwachen.
• Sie können Ihren internetbasierten Load Balancer mit Ihrem Domänennamen verknüpfen.
• usw.

Also in diesem Szenario, das ich versagt habe zu verstehen, warum ich so etwas wie consul.io oder netflix eureka über Amazon ELB für Service Discovery holen würde.

Ich habe das Gefühl, dass dies zur Umsetzung Client Service Discovery vs Server-Seite Service Discovery, aber ich bin nicht ganz sicher, auf Grund sein könnte.

Answer 1

Sie sollten darüber nachdenken, wie der Lastenausgleich auf der Clientseite im Vergleich zum dedizierten Lastenausgleich erfolgt.

Clientseitige Load Balancer gehören Baker Street (http://bakerstreet.io); SmartStack (http://nerds.airbnb.com/smartstack-service-discovery-cloud/); oder Consul HA Proxy (https://hashicorp.com/blog/haproxy-with-consul.html).

Clientseitige LBs verwenden eine Dienstentdeckungskomponente (Baker Street verwendet einen zustandslosen Pub/Sub-Dienstentdeckungsmechanismus; SmartStack verwendet ZooKeeper; Konsul HA-Proxy verwendet Konsul) als Teil ihrer Implementierung, aber sie bieten die Statusüberprüfung/-ende Funktionalität, nach der Sie wahrscheinlich suchen.

Answer 2

Die Service Discovery-Komponente hat normalerweise eine Benachrichtigungskomponente. Es ist kein Load Balancer, obwohl einige möglicherweise dazu in der Lage sind. Es kann registrierte Clients über Änderungen informieren, zum Beispiel wenn ein Loadbalancer abstürzt.

Ein Client kann eine Service Discovery/Registrierung abfragen, um einen Load Balancer zu erhalten, der ausgeführt wird. Während ein Load-Balancer einen Client im Falle eines Ausfalls nicht notiert.

Answer 3

Sie auch über EUREKA

---

Amazon ELB bietet die EC2-Instanzen auf Ihre Service-Anfragen basierend auf Lastenausgleich und die IP-Adressen der EC2-Instanzen sind nicht konsistent, so dass Sie auch EUREKA verwenden können, lesen sollen, welche tut Derselbe Job basiert jedoch auf der Service-Registrierung und dem Lastenausgleich auf der Clientseite, wobei der Anwendungsclient für jede Region über die Registrierung verfügt. Sie können mehr darüber lesen Sie hier: https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance