Hay docenas de soluciones para realizar el servicio de descubrimiento en el entorno Mesos.
Podemos dividirlos en 3 grupos por la forma en que el cliente encuentra los servicios:
- Basado en proxy
- Cuando entre los clientes y el servicio se encuentra un proxy, por ejemplo, HAProxy (marathon-lb se basa en él), fabio, traefik, nixy) que se encarga de equilibrar la carga de sus servicios según la ruta HTTP, el encabezado, el dominio, etc. Esta solución es fácil de desarrollar y brinda la oportunidad de ajustar el equilibrio de carga según la solicitud. Por otro lado, agregamos un salto adicional y, como proxy, tenemos una situación MitM.
- DNSlike (pregunte a un punto final conocido especial para la ubicación del servicio)
- Red definida por software:podemos usar IP por contenedor con SDN para que cada contenedor se exponga con una IP única y presente sus servicios usando los puertos predeterminados 80 para HTTP, 443 para HTTPS, etc. Esta es la técnica más avanzada y relativamente nueva, aunque utiliza DNS simple y antiguo para encontrar la IP del servicio. Podría ser más difícil de introducir que el proxy, pero funcionará con cualquier tipo de tráfico.
- Registro de servicio:donde cada contenedor se registra en DNS global y el cliente obtiene su IP y PUERTO mediante consultas DNS SRV. Consul Mesos DNS proporciona este tipo de servidor DNS. También algunos otros protocolos se basan en esta idea (echa un vistazo a Bonjure). Intenta obtener lo mejor de SDN y proxy. Es relativamente fácil de configurar y es independiente del protocolo.
- Otros
- Cualquier cosa que no encaje en otros tipos, p. solución desarrollada internamente, etcd o Eureka. Podría estar profundamente ajustado con la infraestructura y la aplicación proporcionando algunas optimizaciones. Vale la pena mencionar que hay algunos intentos de usar el servicio de descubrimiento basado en DHT - Meta Service Discovery
Puede encontrar más detalles sobre las herramientas que podrían usarse para crear Discovery Service aquí
Podemos dividir los servicios de descubrimiento por la forma en que se completan con las entradas de servicio:
- Poner en común
- Mesos/Marathon se consulta periódicamente sobre el estado. Así funciona Mesos DNS. Este es el método más fácil, pero causará una gran demora entre el inicio/detención del servicio y los cambios en el descubrimiento del servicio. Esto podría minimizarse mediante el uso de controles de salud.
- Basado en eventos
- Marathon tiene la capacidad de impulsar eventos con información sobre cambios de estado (también hay una iniciativa para incluir el bus de eventos int Mesos; documento de diseño. De esta manera, marathon-lb está funcionando. Marathon-consul realiza un trabajo similar, pero los datos se pasan a cónsul.
- En aplicación/contenedor
- Las soluciones anteriores son asincrónicas, por lo que podría haber un período de tiempo en el que el estado de descubrimiento de su servicio sea obsoleto, p. el servicio comenzó pero no está listo para atender las solicitudes, o el servicio acaba de fallar. Incluso con healthcheck no podíamos asumir que todo sucede con 0 tiempo de inactividad. La solución para minimizar el tiempo de inactividad es permitir que la aplicación se registre sola cuando esté lista para atender las solicitudes y anular el registro antes de que se detenga (también conocido como cierre correcto).
