Service Discovery

Resumen

En una arquitectura de microservicios, las instancias aparecen y desaparecen constantemente: un deploy agrega pods nuevos, una falla mata instancias, el auto-scaling responde a picos de carga. Configurar manualmente las direcciones de cada servicio es imposible. Service Discovery resuelve esto: cada servicio se registra al iniciar y los demás lo consultan cuando necesitan comunicarse.

Hay dos patrones principales:

Client-side discovery: el cliente consulta un registro —por ejemplo, Consul o Eureka— para obtener la lista de instancias disponibles y elige una (generalmente con un balanceador de carga local).

Server-side discovery: el cliente hace la solicitud a un balanceador de carga —por ejemplo, AWS ALB o un sidecar como Envoy—, que consulta el registro y reenvía al backend. El cliente no necesita saber cuántas instancias hay ni dónde están.

Alcance y supuestos

Este paquete cubre el concepto a nivel arquitectónico: qué es, qué problema resuelve, cómo se relaciona con otros patrones del ecosistema, y en qué contexto tiene sentido aplicarlo. No cubre detalles de implementación específicos de cada tecnología ni configuraciones de proveedores cloud concretos. Asume que el lector entiende los fundamentos de sistemas distribuidos y arquitectura de software.

Modelo mental

Una central de taxis antes y después de las apps. Antes, llamabas a la central, pedías un taxi, y la central te decía «el coche 47 va para allá». La central conocía la ubicación de todos los coches y decidía cuál te asignaba —server-side discovery—. Con las apps modernas, tu teléfono consulta un registro de conductores cercanos y elige uno —client-side discovery—. En ambos casos, vos no necesitás saber qué conductores existen: el sistema de discovery te da la respuesta.

Uso práctico

• ✅ Registro automático: cada instancia se registra al iniciar y se da de baja al detenerse, manteniendo el registro actualizado sin intervención manual.
• ✅ Health checks: el discovery solo devuelve instancias saludables.
• ✅ Balanceo integrado: discovery + balanceo de carga suelen ir juntos.
• ❌ No reemplaza la necesidad de manejar fallas de red: si una instancia se cae después del health check, el cliente igual recibe un error.

Tecnologías: Consul, etcd, Eureka (client-side); Kubernetes Services + CoreDNS, AWS Cloud Map, Envoy + xDS (server-side).

Ejemplo trabajado: descubrimiento en Kubernetes

Un microservicio order-service necesita llamar a payment-service. En lugar de configurar la IP del payment service —que cambia en cada deploy—, order-service usa el nombre DNS payment-service.default.svc.cluster.local. CoreDNS de Kubernetes resuelve ese nombre a la IP de uno de los pods saludables del payment service. Si un pod se cae, Kubernetes lo reemplaza con una IP nueva, y CoreDNS actualiza el registro. order-service nunca se enteró del cambio.

Evidencia

• Wikipedia, Service discovery cubre los patrones client-side y server-side, los protocolos de registro y descubrimiento, y su rol en la arquitectura de microservicios.