Información general sobre Directorio de servicios

Service Directory es un servicio cubierto por las obligaciones de Google que se establecen en la Adenda sobre Tratamiento de Datos de Cloud.

Directorio de servicios es un lugar unificado para publicar, descubrir y conectarse a servicios de forma coherente y fiable, independientemente de su entorno. Admite servicios que están en Google Cloudy en entornos multinube y on-premise, y se puede escalar verticalmente hasta miles de servicios y puntos finales para un mismo proyecto.

Service Directory tiene las siguientes funciones:

Por qué usar Directorio de servicios

A medida que las aplicaciones adoptan servicios, resulta más difícil resolver la ubicación de un servicio cuando cambian los endpoints de esos servicios. Los servicios implementados en entornos híbridos presentan obstáculos adicionales, ya que es posible que no compartan el mismo sistema de nomenclatura, lo que dificulta la resolución y la conexión de servicios. Para ilustrar el problema, considera lo siguiente.

Imagina que estás creando una API sencilla y que tu código necesita llamar a otra aplicación. Cuando la información de los endpoints permanece estática, puedes codificar estas ubicaciones en tu código o almacenarlas en un archivo de configuración pequeño. Sin embargo, con los microservicios y la multinube, este problema es mucho más difícil de resolver, ya que las instancias, los servicios y los entornos pueden cambiar.

Directorio de servicios sin balanceador de carga (haz clic para ampliar)
Diferentes servicios cambiantes (haz clic en la imagen para ampliarla)

Con Directorio de servicios, puedes registrar todos tus servicios en un solo lugar y resolverlos mediante HTTP, gRPC y DNS.

Volvamos al diagrama anterior, pero esta vez añadiendo Directorio de servicios. En el siguiente diagrama, cada instancia de servicio se registra en Directorio de servicios. Estos registros se reflejan inmediatamente en el DNS y se pueden consultar mediante HTTP o gRPC, independientemente de su implementación y entorno.

Directorio de servicios con un balanceador de carga (haz clic para ampliar)
Directorio de servicios con un balanceador de carga (haz clic en la imagen para ampliarla)

Puedes crear un nombre de servicio universal que funcione en todos los productos, como App Engine y GKE. Google CloudPuedes hacer que estos servicios estén disponibles a través de DNS. Puedes aplicar controles de acceso a los servicios en función de la red, el proyecto y los roles de gestión de identidades y accesos de las cuentas de servicio.

Directorio de servicios resuelve los siguientes problemas:

  1. Interoperabilidad: Service Directory es un servicio de nomenclatura universal que funciona en Google Cloud, multinube y on-premise. Puedes migrar servicios entre estos entornos y seguir usando el mismo nombre de servicio para registrar y resolver endpoints.
  2. Gestión de servicios: Service Directory es un servicio gestionado. Tu organización no tiene que preocuparse por la alta disponibilidad, la redundancia, la escalabilidad ni el mantenimiento de su propio registro de servicios.
  3. Control de acceso: con el directorio de servicios, puedes controlar quién puede registrar y resolver tus servicios mediante la gestión de identidades y accesos. Asigna roles de Service Directory a equipos, cuentas de servicio y organizaciones.
  4. Limitaciones del DNS puro: las resoluciones de DNS pueden no ser fiables en cuanto al respeto de los TTLs y el almacenamiento en caché, no pueden gestionar tamaños de registros más grandes y no ofrecen una forma sencilla de servir metadatos a los usuarios. Además de la compatibilidad con DNS, Service Directory ofrece APIs HTTP y gRPC para consultar y resolver servicios.

Usar Cloud DNS con Service Directory

Cloud DNS es un servicio de sistema de nombres de dominio (DNS) rápido, escalable y fiable que se ejecuta en la infraestructura de Google.

Además de las zonas DNS públicas, Cloud DNS también ofrece una solución de DNS interno gestionada para redes privadas enGoogle Cloud. Las zonas DNS privadas te permiten asignar nombres internos a tus instancias de máquina virtual (VM), balanceadores de carga u otros recursos. Las consultas de DNS de esas zonas de DNS privadas están restringidas a tus redes privadas.

En el siguiente diagrama se muestra cómo puedes usar las zonas de Service Directory para que los nombres de servicio estén disponibles mediante búsquedas de DNS.

Usar Cloud DNS con Directorio de servicios (haz clic en la imagen para ampliarla)
Usar Cloud DNS con Service Directory (haz clic en la imagen para ampliarla)

Descripción general de los componentes individuales:

  1. Los endpoints se registran directamente en Directorio de servicios mediante la API Service Directory. Puedes registrar serviciosGoogle Cloud y noGoogle Cloud en Directorio de servicios.
  2. Tanto los clientes externos como los internos pueden consultar esos servicios en https://servicedirectory.googleapis.com.
  3. Para habilitar las solicitudes DNS, crea una zona de Directorio de servicios en Cloud DNS que esté asociada a un espacio de nombres de Directorio de servicios.
  4. Los clientes internos pueden resolver este servicio mediante DNS, HTTP y gRPC. Los clientes externos (clientes que no están en la red privada) deben usar HTTP o gRPC para resolver nombres de servicio.

Configuración de ejemplo

Cómo exponer un servicio a través de DNS

En el siguiente diagrama se muestra cómo se modela una arquitectura de microservicios en Service Directory y cómo se pone a disposición mediante DNS. Ten en cuenta que Directorio de servicios mantiene los servicios y los endpoints por completo, pero la zona privada está en Cloud DNS.

Exponer un servicio a través de DNS (haz clic en la imagen para ampliarla)
Exponer un servicio a través de DNS (haz clic en la imagen para ampliarla)

En este diagrama (lado izquierdo), el servicio payments se registra en un espacio de nombres con el nombre backend-namespace, la región us-east1 y el proyecto gcp-project. El espacio de nombres está vinculado a la zona privada example.com.

Para hacer una búsqueda de DNS, el cliente solicita el registro SRV del nombre de dominio _payments._tcp.payments.example.com, que se resuelve en los números de puerto y los registros de dirección de los endpoints del servicio de pago.

Siguientes pasos