Descubrimiento de servicios

Visión General

El service discovery es el mecanismo por el cual los microservicios se localizan y comunican entre sí en ambientes en vivo donde las direcciones IP cambian constantemente. En lugar de hardcodear endpoints, los servicios se registran en un registro y los clientes lo consultan para encontrar instancias saludables. Combinado con health checks, habilita sistemas auto-curativos que rutean alrededor de fallas automáticamente.

Cuándo Usar

Usa este recurso cuando:

• Ejecutas microservicios en Kubernetes, ECS o auto-scaling groups donde las IPs son efímeras
• Necesitas failover automático cuando instancias de servicio fallan o se vuelven unhealthy
• Balanceas carga entre múltiples instancias sin actualizaciones manuales de configuración
• Implementas despliegues blue-green o canary releases que requieren routing en vivo de tráfico

Solución

Registro de Servicio con Consul (Go)

import "github.com/hashicorp/consul/api"

func registerService(consulAddr, serviceID, name, host string, port int) error {
    config := api.DefaultConfig()
    config.Address = consulAddr
    client, err := api.NewClient(config)
    if err != nil {
        return err
    }

    registration := &api.AgentServiceRegistration{
        ID:      serviceID,
        Name:    name,
        Address: host,
        Port:    port,
        Check: &api.AgentServiceCheck{
            HTTP:     fmt.Sprintf("http://%s:%d/health", host, port),
            Interval: "10s",
            Timeout:  "5s",
        },
    }

    return client.Agent().ServiceRegister(registration)
}

DNS-Based Discovery (Kubernetes)

apiVersion: v1
kind: Service
metadata:
  name: payment-service
spec:
  selector:
    app: payment
  ports:
    - port: 8080
      targetPort: 8080

# Los servicios se descubren vía DNS
PAYMENT_URL=http://payment-service:8080

Client-Side Load Balancing con Eureka (Java/Spring)

@SpringBootApplication
@EnableDiscoveryClient
public class OrderService {
    @Bean
    @LoadBalanced
    public WebClient.Builder webClientBuilder() {
        return WebClient.builder();
    }
}

@Service
public class OrderProcessor {
    @Autowired
    private WebClient.Builder webClientBuilder;

    public Mono<PaymentResult> processPayment(PaymentRequest request) {
        return webClientBuilder.build()
            .post()
            .uri("lb://payment-service/payments")
            .bodyValue(request)
            .retrieve()
            .bodyToMono(PaymentResult.class);
    }
}

Explicación

Tres patrones de discovery:

Patrón	Mecanismo	Ideal Para
Client-side	Cliente consulta registry; elige instancia	Alto performance; language-native
Server-side	Load balancer consulta registry; cliente usa una URL	Clientes más simples; control central
DNS-based	Nombres de servicio resuelven a IPs vía DNS	Kubernetes; zero cambios en clientes

Integración de health checks:

• Los servicios se registran con un endpoint de health
• El registry hace polling de health checks periódicamente
• Las instancias unhealthy se remueven del pool
• Los clientes cachean datos del registry y refrescan ante fallas

Variantes

Herramienta	Modelo	Lenguaje	Capacidades Destacadas
Consul	Client + server	Cualquiera	Multi-datacenter; KV store; ACLs
Eureka	Client-side	Java	Netflix OSS; integración Spring
etcd	Server-side	Cualquiera	Default de Kubernetes; consenso Raft
Zookeeper	Server-side	Cualquiera	Maduro; consistencia fuerte
AWS Cloud Map	Server-side	Cualquiera	AWS-native; integración ECS

Lo que funciona

• Heartbeat con TTL: Los servicios deben renovar su registro o ser auto-deregistrados
• Cache con fallback: Los clientes deben cachear listas de instancias y usar datos stale brevemente si el registry no está disponible
• Routing zone-aware: Preferir instancias en la misma AZ para reducir latencia y costos de transferencia de datos
• Metadata para routing: Etiquetar instancias con versiones para habilitar canary y A/B testing
• Seguridad con mTLS: Encriptar comunicación service-to-service; autenticar servicios registrados. Consulta API security checklist.

Errores Comunes

1. Sin health checks: Instancias muertas no deregistradas siguen recibiendo tráfico
2. Thundering herd: Todos los clientes consultando el registry simultáneamente bajo carga
3. Ignorar deregistration: Servicios crashados permanecen en el pool hasta que expire el TTL
4. Hard-codear fallback IPs: Anula el propósito del discovery en vivo
5. Omitir retries: Una instancia fallida debería disparar un retry en otra, no fallar el request. Usa retry con backoff exponencial para clientes resilientes.

Errores Comunes Adicionales

1. Registry como single point of failure. Si el registry cae, todo el service discovery falla. Ejecuta registries en clusters (Consul: 3-5 nodos, Eureka: peer-to-peer) y cachea listas de instancias client-side.

2. Sin connection pooling con endpoints descubiertos. Crear una nueva conexión HTTP por request a una instancia descubierta es costoso. Pool conexiones por instancia y recíclalas:

import requests
from requests.adapters import HTTPAdapter

class PooledServiceClient:
    def __init__(self):
        self.sessions: dict[str, requests.Session] = {}

    def get_session(self, instance_url: str) -> requests.Session:
        if instance_url not in self.sessions:
            session = requests.Session()
            adapter = HTTPAdapter(pool_connections=10, pool_maxsize=100)
            session.mount('http://', adapter)
            self.sessions[instance_url] = session
        return self.sessions[instance_url]

3. Ignorar race conditions de arranque. Un servicio que se registra antes de estar listo para aceptar tráfico recibirá requests que no puede manejar. Registra solo después de pasar los checks de arranque, y usa readiness probes en Kubernetes para gatear el tráfico.