web-services - carga - configurar balanceador aws

Descubrimiento de servicios vs balanceo de carga (4)

AWS ELB y Eureka difieren en muchos puntos:

Servicios de Edge vs Servicios de nivel medio
AWS ELB es una solución de equilibrio de carga para servicios perimetrales expuestos al tráfico web del usuario final. Eureka satisface la necesidad de equilibrio de carga de nivel medio.
El servidor de nivel medio se refiere a un servidor de aplicaciones que se encuentra entre la máquina del usuario y el servidor de la base de datos donde se realiza el procesamiento. El servidor de nivel medio ejecuta la lógica empresarial.
Si bien teóricamente puede poner sus servicios de nivel medio detrás de AWS ELB, en EC2 Classic los expone al mundo exterior y, por lo tanto, pierde toda la utilidad de los grupos de seguridad de AWS.

Equilibrio de carga del lado del cliente vs dedicado
AWS ELB también es una solución tradicional de equilibrio de carga basada en proxy, mientras que con Eureka es diferente en que el equilibrio de carga se realiza a nivel de instancia / servidor / host de forma rotatoria. Las instancias de los clientes conocen toda la información sobre los servidores con los que necesitan hablar.
Si está buscando una sesión de usuario persistente (todas las solicitudes de un usuario durante la sesión se envían a la misma instancia), el equilibrio de carga que ofrece AWS ahora, Eureka no ofrece una solución lista para usar.

Interruptores del equilibrador de carga
Otro aspecto importante que diferencia el equilibrio de carga basado en proxy del equilibrio de carga con Eureka es que su aplicación puede ser resistente a las interrupciones de los equilibradores de carga, ya que la información sobre los servidores disponibles se almacena en caché en el cliente Eureka.
Esto requiere una pequeña cantidad de memoria pero compra mejor resistencia. El cliente de Eureka obtiene toda la información de registro de una vez y, en solicitudes posteriores al servidor de Eureka, solo recibe el delta, es decir, los cambios en la información de registro en lugar de toda la información de registro. Además, los servidores Eureka pueden operar en modo de clúster donde cada par no se ve afectado por el desempeño de otros.

Escala y conveniencia.
Además, imagine que se ejecutan miles de microservicios y cada uno tiene múltiples instancias. Necesitará 1000 ELB, uno para cada microservicio o algo así como HAProxy que se encuentra detrás del ELB para tomar decisiones de capa 7 basadas en el nombre de host, etc. y luego reenviar el tráfico a un subconjunto de instancias. Mientras que con Eureka, solo juegas con el nombre de la aplicación, que es mucho menos complicado.

Estoy tratando de entender en qué escenario debería elegir un registro de servicio sobre un equilibrador de carga.

A mi entender, ambas soluciones cubren la misma funcionalidad.

Por ejemplo, si consideramos consul.io como una lista de características tenemos:

Descubrimiento de servicios
Chequeo de salud
Tienda de clave / valor
Multi Datacenter

Donde un equilibrador de carga como Amazon ELB, por ejemplo, tiene:

Configurable para aceptar tráfico solo desde su equilibrador de carga
acepte el tráfico utilizando los siguientes protocolos: HTTP, HTTPS (HTTP seguro), TCP y SSL (TCP seguro)
Distribuir solicitudes a instancias de EC2 en múltiples zonas de disponibilidad.
El número de conexiones se escala con el número de solicitudes simultáneas que recibe el equilibrador de carga
configure las comprobaciones de estado que Elastic Load Balancing utiliza para monitorear el estado de las instancias de EC2 registradas con el equilibrador de carga para que pueda enviar solicitudes solo a las instancias en buen estado.
Puede usar el cifrado de tráfico de extremo a extremo en aquellas redes que usan conexiones seguras (HTTPS / SSL)
[EC2-VPC] Puede crear un equilibrador de carga orientado a Internet, que recibe solicitudes de clientes a través de Internet y las enruta a sus instancias de EC2, o un equilibrador de carga interno, que recibe solicitudes de clientes en su VPC y las enruta a las instancias de EC2 en sus subredes privadas. Los balanceadores de carga en EC2-Classic siempre están orientados a Internet.
[EC2-Classic] Los equilibradores de carga para EC2-Classic admiten direcciones IPv4 e IPv6. Los equilibradores de carga para una VPC no admiten direcciones IPv6.
Puede supervisar su equilibrador de carga usando métricas de CloudWatch, registros de acceso y AWS CloudTrail.
Puede asociar su equilibrador de carga orientado a Internet con su nombre de dominio.
etc.

Entonces, en este escenario, no entiendo por qué elegiría algo como consul.io o netflix eureka sobre Amazon ELB para el descubrimiento del servicio.

Tengo el presentimiento de que esto podría deberse a la implementación del descubrimiento del servicio del lado del cliente frente al descubrimiento del servicio del lado del servidor , pero no estoy muy seguro.

Debe pensar en ello como el equilibrio de carga del lado del cliente frente al equilibrio de carga dedicado.

Los equilibradores de carga del lado del cliente incluyen Baker Street ( http://bakerstreet.io ); SmartStack ( http://nerds.airbnb.com/smartstack-service-discovery-cloud/ ); o Proxy de Consul HA ( https://hashicorp.com/blog/haproxy-with-consul.html ).

Los LB del lado del cliente usan un componente de descubrimiento de servicio (Baker Street usa un mecanismo de descubrimiento de pub / sub servicio sin estado; SmartStack usa ZooKeeper; el cónsul HA Proxy usa el cónsul) como parte de su implementación, pero proporcionan la funcionalidad de verificación de estado / extremo a extremo probablemente estás buscando

El componente Service Discovery generalmente tiene un componente de notificación. No es un equilibrador de carga, aunque algunos pueden tener la capacidad de hacerlo. Puede notificar a los clientes registrados sobre los cambios, por ejemplo, un equilibrador de carga que se apaga.

Un cliente puede consultar un registro / descubrimiento de servicios para obtener un equilibrador de carga que se esté ejecutando. Mientras que un equilibrador de carga no pone en peligro a un cliente cuando está inactivo.

También deberías leer sobre EUREKA

Amazon ELB proporciona las instancias de EC2 a sus solicitudes de servicio basadas en el equilibrador de carga y las direcciones IP de las instancias de EC2 no son coherentes, por lo que también puede utilizar EUREKA, que hace el mismo trabajo, pero se basa en el registro de servicios y el equilibrio de carga del lado del cliente El cliente de la aplicación para cada región tiene el registro. Puede leer más sobre esto aquí: https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance