Spring Cloud Gateway integra Nacos para implementar enrutamiento de servicios y equilibrio de carga del clúster

Todos sabemos que Spring Cloud Gateway es una puerta de enlace de alto rendimiento construida sobre Spring Boot, Spring WebFlux y Project Reactor, cuyo objetivo es proporcionar enrutamiento API simple y eficiente.

Spring Cloud Gateway se ejecuta en base a Netty, por lo que no puede ejecutarse normalmente en un contenedor de servlet tradicional o empaquetado en un paquete de guerra.

Aquí nuestro centro de registro elige Nacos. Si Nacos aún no se ha instalado, consulte: Instalación e implementación rápida de Nacos.

Si el URI comienza con ==lb==, como lb://user-service en la configuración anterior, Spring Cloud Gateway utilizará ReactiveLoadBalancerClientFilter para resolver el host real y la instancia correspondiente del servicio denominado puerto de servicio de usuario y realizar equilibrio de carga del clúster.

Esta función se implementa a través del filtro global ReactiveLoadBalancerClientFilter. La descripción del sitio web oficial es la siguiente:

[Error en la carga de la imagen...(image-b13395-1655546589820)]

RouteRecordGlobalFilter Este filtro global se utiliza principalmente para registrar la dirección proxy real después del enrutamiento y el tiempo de llamada.

Si miramos la descripción de RouteToRequestUrlFilter, encontraremos que la dirección de enrutamiento real se guardará a través del atributo llamado ServerWebExchangeUtils.GATEWAY_REQUEST_URL_ATTR en ServerWebExchange.

[Error en la carga de la imagen...(image-a33940-1655546589820)]

Parte del código fuente de RouteToRequestUrlFilter es el siguiente:

Iniciar api- puerta de enlace y especifique El perfil inicia dos instancias de servicio de servicio de usuario y dos instancias de servicio de servicio de mensajes. Vea la consola de Nacos.

[Error en la carga de la imagen...(image-34bdc6-1655546589820)]

Puedes ver que api-gateway inició una instancia de servicio, tanto de servicio de usuario como de servicio de mensajes. Se inician las instancias de servicio.

Visite continuamente http://localhost:9000/user/info y podrá ver que se está llamando a la instancia del servicio de clúster de servicio de usuario en el sondeo.

Visite http://localhost:9000/user/info y http://localhost:9000/message/info respectivamente. Podemos ver que la distribución de rutas de servicio basada en la coincidencia de rutas es exitosa.