Balanceo de cargas de Traffic Director

Traffic Director usa proxies de sidecar o gRPC sin proxy a fin de entregar balanceo de cargas global para los microservicios internos. Puedes implementar microservicios internos (basados en proxies de sidecar o sin gRPC) con instancias en varias regiones. Traffic Director proporciona información de estado, enrutamiento y backend a los proxies de sidecar, lo que les permite realizar un enrutamiento de tráfico óptimo a varias instancias de aplicaciones en varias regiones en la nube para un servicio.

En la siguiente diagrama, el tráfico del usuario ingresa a una implementación de Google Cloud a través de un balanceador de cargas global externo. El balanceador de cargas externo distribuye el tráfico al microservicio de frontend en us-central1 o asia-southeast1, según la ubicación del usuario final.

La implementación interna cuenta con tres microservicios globales: frontend, carrito de compras y pagos. Cada servicio se ejecuta en grupos de instancias administrados en dos regiones, us-central1 y asia-southeast1. Traffic Director usa un algoritmo de balanceo de cargas global que dirige el tráfico del usuario en California a los microservicios implementados en us-central1. Las solicitudes del usuario en Singapur se dirigen a los microservicios en asia-southeast1.

Una solicitud de usuario entrante se enruta al microservicio de frontend. Luego, el proxy de servicio instalado en el host con el frontend dirige el tráfico al carrito de compras. El proxy de sidecar instalado en el host con el carrito de compras dirige el tráfico al microservicio de pagos. En un entorno de gRPC sin proxy, tu aplicación de gRPC controlaría la administración del tráfico.

Traffic Director en una implementación de balanceo de cargas global.
Traffic Director en una implementación de balanceo de cargas global (haz clic para ampliar)

En el siguiente ejemplo, si Traffic Director recibe resultados de verificación de estado que indican que las instancias de máquina virtual (VM) que ejecutan el microservicio de carrito de compras en us-central1 están en mal estado, Traffic Director le indica al proxy de sidecar para los microservicios del frontend que realice una conmutación por error del tráfico al microservicio del carrito de compras que se ejecuta en asia-southeast1. Debido a que el ajuste de escala automático está integrado con la administración de tráfico en Google Cloud, Traffic Director notifica al MIG en asia-southeast1 del tráfico adicional y el tamaño aumenta.

Traffic Director detecta que todos los backends del microservicio de pagos están en buen estado, por lo que Traffic Director le indica al proxy de Envoy que el carrito de compras debe enviar una parte del tráfico, que incluya hasta la capacidad configurada por el cliente, a asia-southeast1 y desbordar el resto del tráfico a us-central1.

Conmutación por error con Traffic Director en una implementación de balanceo de cargas global
Conmutación por error con Traffic Director en una implementación de balanceo de cargas global (haz clic para ampliar)

Componentes del balanceo de cargas en Traffic Director

Durante la configuración de Traffic Director, configuras varios componentes del balanceo de cargas:

  • El servicio de backend, que contiene valores de configuración
  • Una verificación de estado, que proporciona verificaciones de estado para las VM y los Pods de Google Kubernetes Engine (GKE) en tu implementación
  • Con las APIs de enrutamiento de servicio, un recurso Mesh o Gateway y un recurso Route.
  • Con las APIs de balanceo de cargas, una regla de reenvío global, que incluye la dirección VIP, un proxy de destino y un mapa de URL.

Un proxy de sidecar compatible con la API de xDS (como Envoy) se ejecuta en una instancia de VM de cliente o en un Pod de Kubernetes. Traffic Director sirve como plano de control y usa las APIs de xDS para comunicarse directamente con cada proxy. En el plano de datos, la aplicación envía tráfico a la dirección VIP configurada en la regla de reenvío o en el recurso Mesh. El proxy de sidecar o tu aplicación de gRPC interceptan el tráfico y lo redireccionan al backend adecuado.

En el siguiente diagrama, se muestra una aplicación que se ejecuta en VMs de Compute Engine o Pods de GKE, los componentes y el flujo de tráfico de una implementación de Traffic Director. Se muestran Traffic Director y los recursos de Cloud Load Balancing que se usan para determinar el enrutamiento de tráfico. En el diagrama, se muestran las APIs de balanceo de cargas más antiguas.

Recursos de Traffic Director que se configurarán.
Recursos de Traffic Director que se configurarán (haz clic para ampliar)

¿Qué sigue?