Microservices Engine:Enrutamiento

Enrutamiento de servicio único

El gateway nativo de la nube reenvía las solicitudes a un servicio de backend específico según las reglas de enrutamiento. Para obtener más información sobre cómo configurar servicios, consulte Add a service.

El gateway compara las solicitudes con las reglas de enrutamiento que configuró. Por ejemplo:

• El gateway reenvía todas las solicitudes que coinciden con la regla de enrutamiento /user al servicio de usuarios.

• El gateway reenvía todas las solicitudes que coinciden con la regla de enrutamiento /order al servicio de pedidos.

Enrutamiento basado en porcentaje

El gateway nativo de la nube distribuye las solicitudes entre varios servicios de backend según el peso configurado para cada servicio. Los escenarios comunes incluyen:

• Multiple Registry Centers

  Al cambiar los registros de servicios, despliegue una réplica del servicio que utilice el nuevo registro y conserve el servicio y registro originales. El tráfico se desvía gradualmente del servicio original al nuevo. Tras comprobar la estabilidad del nuevo servicio, reenvíele todo el tráfico. La migración permite revertir los cambios si el nuevo servicio no cumple con sus requisitos.

  La siguiente figura muestra un ejemplo donde el servicio de usuarios cambia de Nacos al CoreDNS integrado para Kubernetes. CoreDNS debe usarse junto con los recursos del servicio.

  

• O&M System Differences

  Tradicionalmente, la mayoría de los servicios se ejecutan en máquinas virtuales, como instancias de Elastic Compute Service (ECS) de Alibaba Cloud. A medida que más empresas migran a plataformas basadas en Kubernetes, como Container Service for Kubernetes (ACK) de Alibaba Cloud, puede desplegar una réplica del servicio en un clúster de Kubernetes y registrarlo con un nombre nuevo en el registro. Así coexisten dos servicios con funciones idénticas: uno en una instancia de ECS y otro en un clúster de Kubernetes. El tráfico se desvía gradualmente de ECS a Kubernetes; además, puede ajustar el porcentaje o revertir el proceso en cualquier momento.

  Por ejemplo, suponga que desea migrar un servicio de usuarios que usa Nacos como registro desde ECS hacia la plataforma ACK de Alibaba Cloud.

  

Enrutamiento basado en etiquetas

El gateway nativo de la nube reenvía las solicitudes a diferentes versiones de un servicio según el peso configurado para cada versión. Para obtener más información sobre cómo configurar versiones de servicio, consulte Manage service versions. Los escenarios comunes incluyen:

• Canary release

  Una canary release desvía una pequeña cantidad de tráfico hacia una nueva versión del servicio para su verificación. Si el resultado cumple con las expectativas, el resto del tráfico se migra gradualmente a la nueva versión.

  Por ejemplo, el servicio de usuarios desplegado en un clúster de ACK ejecuta actualmente la v1, y se planea lanzar la v2. Puede realizar una canary release de las siguientes maneras:

  • By ratio

    El enrutamiento basado en etiquetas reenvía las solicitudes /user al servicio de usuarios v1. Agregue el servicio de usuarios v2 en la página de gestión de servicios en la consola de Microservices Engine (MSE) y luego añádalo a los servicios de destino para el enrutamiento basado en etiquetas. Configure un peso para determinar el porcentaje de tráfico que se reenvía al servicio de usuarios v2.

    

  • Tags

    El enrutamiento basado en etiquetas reenvía las solicitudes /user al servicio de usuarios v1. Agregue una ruta /user y configure una etiqueta que indique que esta ruta se usa para una canary release. Por ejemplo, la etiqueta puede ser el encabezado stage con el valor gray. Esta ruta reenvía solicitudes con dichos encabezados al servicio de usuarios v2.

    

• Tag-based routing

  En un entorno de producción, pueden coexistir varias versiones de un servicio durante un periodo prolongado, y cada versión gestiona distintos tipos de solicitudes. Por ejemplo, las solicitudes con diferentes valores de encabezado pueden reenviarse a distintas versiones del servicio. El enrutamiento basado en etiquetas también aplica cuando coexisten varios entornos (pruebas, preproducción y producción), y se usan etiquetas para distinguir las solicitudes de cada entorno.

  Por ejemplo, en la siguiente aplicación, un servicio de usuarios utiliza el servicio de contenedores K8s para el descubrimiento de servicios y cuenta con tres entornos de desarrollo (test, pre y online). La configuración para las solicitudes a /user es la siguiente:

  • Si el valor del encabezado stage es test, el tráfico se reenvía al servicio de usuarios en el entorno de pruebas.

  • Si el valor del encabezado stage es pre, el tráfico se reenvía al servicio de usuarios en el entorno de preproducción.

  • Si el valor del encabezado stage es online, el tráfico se reenvía al servicio de usuarios en el entorno de producción.

  

• High-availability deployment

  Para garantizar la disponibilidad del servicio, pueden desplegarse servicios idénticos en varios clústeres de Kubernetes. Gestione las instancias de servicio por clúster según los metadatos del nodo y ajuste el peso para distribuir el tráfico entre los clústeres. Si un clúster falla, establezca su peso en 0 para reenviar todo el tráfico a los clústeres restantes.

  Por ejemplo, en el siguiente sistema de aplicaciones, se descubre el servicio de usuarios desplegado en los clústeres de ACK A y B. Para las solicitudes /user, el 80 % del tráfico se reenvía al servicio de usuarios desplegado en el clúster A, y el 20 % restante se reenvía al servicio de usuarios desplegado en el clúster B.

  

Enrutamiento mock

El enrutamiento mock devuelve una respuesta fija para una ruta, lo que le permite comprobar si las solicitudes se reenvían correctamente. Esto facilita que el desarrollo de frontend y backend avance en paralelo.

Por ejemplo, cuando el servicio de usuarios del backend aún no está terminado, configure una respuesta fija para sus operaciones de API a fin de que los desarrolladores de frontend prueben el proceso de enrutamiento. Una vez que el servicio de backend esté listo, cambie el tipo de ruta de Mock al servicio real para depurar conjuntamente.

Enrutamiento de redirección

El gateway nativo de la nube puede redirigir solicitudes a un nombre de dominio o ruta diferente. Esto se usa comúnmente en migraciones de nombres de dominio y cambios de API.

Por ejemplo, si el nombre de dominio actual del servicio es old.example.com y la ruta actual es /test, el gateway nativo de la nube redirige una solicitud de old.example.com/test a new.example.com/dev.