El descubrimiento de servicios es un componente fundamental en arquitecturas distribuidas y microservicios, permitiendo que las aplicaciones localicen y se comuniquen entre sí de forma automática. Al igual que un navegador web utiliza DNS para resolver nombres de dominio en direcciones IP, los servicios necesitan un mecanismo para encontrar la ubicación de otros servicios en la red sin configuraciones manuales.

Un sistema de descubrimiento de servicios eficaz debe abordar varios desafíos clave:

• Direcciones Dinámicas: Las direcciones IP y puertos de los servicios pueden cambiar frecuentemente debido a la orquestación de contenedores, escalado automático o fallos.
• Alta Disponibilidad: Debe detectar rápidamente las instancias de servicio no saludables y eliminarlas de la lista de disponibles.
• Balanceo de Carga: Debe proporcionar a los clientes la capacidad de distribuir las solicitudes entre las instancias de servicio disponibles de manera eficiente.

Generalmente, el descubrimiento de servicios se implementa junto con el balanceo de carga, y existen varias arquitecturas comunes:

1. Descubrimiento de Servicios del Lado del Cliente: El cliente es responsable de consultar un registro de servicios para obtener la lista de instancias disponibles y luego aplicar una estrategia de balanceo de carga para seleccionar una instancia.
   • Ventajas: Evita cuellos de botella en un balanceador de carga centralizado, lo que puede mejorar el rendimiento.
   • Desventajas: Cada cliente debe mantener su propia lógica de balanceo de carga y lista de servicios, lo que puede aumentar la complejidad en entornos multilingües y dificultar la actualización de políticas de balanceo de carga.
2. Descubrimiento de Servicios Basado en Proxy (o del Lado del Servidor): Los clientes envían solicitudes a un proxy o balanceador de carga central (como una puerta de enlace API) que, a su vez, consulta el registro de servicios y reenvía la solicitud a la instancia de servicio de destino.
   • Ventajas: Simplifica la lógica del cliente y centraliza la configuración del balanceo de carga.
   • Desventajas: El proxy puede convertirse en un punto único de fallo o cuello de botella si no se escala adecuadamente.
3. Proceso de Balanceador de Carga Independiente Co-ubicado: Similar al lado del cliente, pero el balanceador de carga reside en la misma máquina que el cliente como un proceso separado. Esto puede mitigar la necesidad de soporte multilingüe en la lógica del cliente.

Los componentes esenciales de un sistema de descubrimiento de servicios incluyen:

• Registro de Servicios: Una base de datos o sistema donde los servicios se registran a sí mismos.
• Proveedor de Servicios: La instancia de aplicación que ofrece uno o más servicios.
• Consumidor de Servicios (Cliente): La aplicación que necesita encontrar y comunicarse con un servicio.

Las funcionalidades clave son: registro de servicios, consulta de servicios, verificación de salud y actualizaciones dinámicas.

Descubrimiento de Servicios en gRPC

gRPC implmeenta un modelo de descubrimiento de servicios del lado del cliente, al que se refiere como Resolución de Nombres (Name Resolution). Por defecto, gRPC utiliza un resolver DNS (DNS-resolver). Una vez que el resolver obtiene una lista de direcciones IP de las instancias de servicio, un componente de balanceo de carga de gRPC se encarga de distribuir las solicitudes y establecer las conexiones.

Analicemos cómo gRPC gestiona este proceso, tomando como ejemplo un destino de servicio como localhost:50052.

Inicialización del Resolutor

Cuando una conexión cliente gRPC (ClientConn) se inicializa, el primer paso es identificar el mecanismo de resolución adecuado. El sistema gRPC intenta analizar el target para determinar el esquema (por ejemplo, dns, kubernetes, etc.) y encontrar el resolver.Builder correspondiente. Si el target no especifica un esquema (como localhost:50052), gRPC aplicará un esquema predeterminado, que usualmente es dns, transformando el target en algo como dns:///localhost:50052. Esto asegura que siempre haya un constructor de resolutores asociado al destino.

// Pseudocódigo conceptual que ilustra la selección del resolver.Builder
func inicializarConexionCliente(target string) (*ClientConn, error) {
    var builderResolver Builder
    parsedTarget := analizarTarget(target)

    if parsedTarget.TieneEsquema() {
        builderResolver = obtenerBuilderPorEsquema(parsedTarget.Esquema)
    } else {
        // Si no hay esquema, usar el predeterminado, ej. "dns"
        esquemaDefecto := obtenerEsquemaPorDefecto()
        parsedTarget = analizarTarget(esquemaDefecto + ":///" + target)
        builderResolver = obtenerBuilderPorEsquema(parsedTarget.Esquema)
    }

    if builderResolver == nil {
        return nil, fmt.Errorf("No se pudo encontrar un resolver.Builder")
    }

    // El builderResolver se guarda para ser usado más tarde
    cc.resolverBuilder = builderResolver
    return cc, nil
}

Construcción del Resolutor

El resolver.Builder no construye el resolutor inmediatamente. Esta acción se pospone hasta que la conexión cliente sale de un estado inactivo. Esto ocurre generalmente con la primera invocación de una llamada RPC.

// Pseudocódigo que ilustra la construcción del resolutor
func activarResolutor(cc *ClientConn) error {
    // ...
    // Aquí el resolver.Builder se usa para crear una instancia de resolver
    resolverInstancia, err := cc.resolverBuilder.Build(cc.parsedTarget, cc, resolver.BuildOptions{})
    if err != nil {
        return err
    }
    cc.resolver = resolverInstancia
    // ...
    return nil
}

La transición de la conexión de un estado de inactividad a activo desencadena la construcción y el inicio del resolutor. Este proceso está encapsulado en un componente de gRPC llamado idlenessMgr. Cuando se inicia la primera llamada RPC, el idlenessMgr invoca un método para salir del modo inactivo, lo que a su vez llama a la función para construir y arrancar el resolutor.

Mecanismo de Resolución DNS

Cuando se utiliza el dnsBuilder de gRPC, el proceso de construcción del resolutor implica:

1. Análisis de Host y Puerto: Extraer el nombre de host y el puerto del destino.
2. Manejo de IPs Directas: Si el host es una dirección IP, no se necesita resolución DNS. El resolutor simplemente informa esta dirección a la conexión cliente.
3. Creación del dnsResolver: Para nombres de host (no IPs), se crea un objeto dnsResolver que gestionará la resolución. Este objeto encapsula el contexto para la resolución y un canal para notificar actualizaciones.
4. Resolver de Red Subyacente: Se inicializa un resolver de red real (como el net.DefaultResolver de Go, que utiliza /etc/hosts y /etc/resolv.conf).
5. Monitorización Continua: Se lanza una goroutine (un hilo ligero) llamada watcher. Este watcher es crucial, ya que se encarga de sondear periódicamente el DNS para detectar cambios en las direcciones de servicio.

// Pseudocódigo conceptual para el dnsBuilder.Build
func (b *dnsBuilder) Build(target Target, clienteConexion ClientConn, opts BuildOptions) (Resolver, error) {
    host, puerto := extraerHostPuerto(target)

    if esDireccionIP(host) {
        clienteConexion.ActualizarEstado(Estado{Direcciones: []Direccion{{host + ":" + puerto}}})
        return &resolverDirecto{}, nil // Resolver que no necesita hacer lookups
    }

    resolutor := &dnsResolver{
        host: host,
        puerto: puerto,
        cc: clienteConexion,
        // ... otros campos
    }

    resolutor.netResolver = crearNetResolver(host) // Usar el resolver de red estándar
    go resolutor.iniciarWatcher() // Iniciar goroutine para monitorear cambios
    return resolutor, nil
}

El watcher y las Actualizaciones Dinámicas

La goroutine watcher se ejecuta en un bucle continuo, realizando la función lookup() para resolver el nombre de host. Si hay un error, lo reporta a la conexión cliente y aplica un retroceso exponencial antes de reintentar. Si la resolución es exitosa, actualiza el estado de la conexión cliente con las nuevas direcciones y espera un intervalo mínimo antes de la próxima resolución.

// Pseudocódigo conceptual para el watcher
func (d *dnsResolver) iniciarWatcher() {
    defer d.wg.Done()
    indiceRetroceso := 1
    for {
        estadoActual, err := d.ejecutarLookup() // Realiza la resolución DNS
        if err != nil {
            d.cc.ReportarError(err)
            d.esperarConRetroceso(&indiceRetroceso) // Espera con retroceso exponencial
        } else {
            d.cc.ActualizarEstado(*estadoActual) // Notifica a la conexión cliente
            d.reiniciarRetroceso()
            d.esperar(IntervaloMinimoResolucion) // Espera un tiempo fijo
        }
        // ... Lógica para manejar cancelación y señales de actualización
    }
}

La función lookup() es el corazón de la resolución, donde se consultan los registros DNS. gRPC no solo utiliza registros A para obtener direcciones IP, sino que también puede aprovechar otros tipos de registros DNS para funcionalidades más avanzadas:

Registros A (Address)

El método básico, net.Resolver.LookupHost, simplemente devuelve una lista de direcciones IP asociadas con un nombre de host. Esta es la forma más sencilla de descubrimiento, adecuada para servicios con una configuración estática de IP o cuando solo se necesita una lista plana de IPs.

Registros SRV (Service)

Para escenarios más complejos, gRPC puede consultar registros SRV. Un registro SRV proporciona metadatos adicionales como Target (el nombre de host de la instancia del servicio), Port, Priority y Weight. Esto es particularmente útil para:

• Descubrir múltiples instancias de un servicio.
• Identificar balanceadores de carga de gRPC (grpclb). El proceso es el siguiente: primero se buscan registros SRV para el servicio (por ejemplo, _grpclb._tcp.mi-servicio.com). Luego, para cada Target (nombre de host) obtenido de los registros SRV, se realiza una búsqueda de registros A para obtener su dirección IP real. Estas direcciones se combinan con el puerto del registro SRV para formar las direcciones de servicio completas, incluyendo el ServerName para posibles enrutamientos.

// Pseudocódigo conceptual para lookupSRV
func (d *dnsResolver) obtenerDireccionesSRV(ctx context.Context) ([]Address, error) {
    if !habilitarBusquedasSRV {
        return nil, nil
    }

    srvRecords, err := d.netResolver.BuscarSRV(ctx, "grpclb", "tcp", d.host)
    if err != nil {
        return nil, manejarErrorDNS(err, "SRV")
    }

    var direccionesEncontradas []Address
    for _, srv := range srvRecords {
        ipsLB, err := d.netResolver.BuscarHost(ctx, srv.Target)
        if err != nil {
            manejarErrorDNS(err, "A")
            continue
        }
        for _, ip := range ipsLB {
            direccionCompleta := ip + ":" + strconv.Itoa(int(srv.Port))
            direccionesEncontradas = append(direccionesEncontradas, Address{Addr: direccionCompleta, ServerName: srv.Target})
        }
    }
    return direccionesEncontradas, nil
}

Registros TXT (Text)

Finalmente, gRPC también puede buscar registros TXT. Estos registros pueden contener una cadena JSON que define la ServiceConfig del cliente. La ServiceConfig es un conjunto de configuraciones que el cliente gRPC utiliza al interactuar con el servicio, incluyendo políticas de balanceo de carga, configuraciones por método RPC, políticas de reintentos, y configuraciones de verificación de salud.

Una vez que todas las búsquedas de DNS (A, SRV, TXT) se completan, el resolver empaqueta los resultados (direcciones, configuraciones de servicio) en un objeto State. Este State se pasa a la conexión cliente a través de cc.UpdateState(), lo que permite que otros componentes de gRPC, como el balanceador de carga, se adapten dinámicamente a los cambios en la topología del servicio.