Equilibrio de carga de Spring Cloud Gateway
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 Netty, por lo que no funcionará correctamente cuando Spring Cloud Gateway se ejecute en Netty, por lo que no funcionará correctamente en un contenedor de servlet tradicional o como un paquete de guerra.
Gateway tiene dos balanceadores de carga de cliente: LoadBalancerClientFilter y ReactiveLoadBalancerClientFilter. LoadBalancerClientFilter usa Ribbon para bloquear LoadBalancerClient, Gateway recomienda usar ReactiveLoadBalancerClientFilter. Puede cambiar a ReactiveLoadBalancerClientFilter configurando spring.cloud.loadbalancer.ribbon.enabled=false. Ya sea que use Ribbon o LoadBalancer, el lb configurado en Ruta es el mismo
LoadBalancerClientFilter en el sitio web oficial
Si el URI comienza con lb, como lb en la configuración anterior:// servicio de usuario, Spring Cloud Gateway utilizará ReactiveLoadBalancerClientFilter para resolver el host y el puerto reales de la instancia con el nombre de servicio servicio de usuario y realizar el equilibrio de carga del clúster.
El sitio web oficial dice que se debe utilizar el formulario lb://lakerservice, pero no surte efecto después de configurarlo. El sitio web oficial no explica esto en detalle, ni tampoco el material fuente. Finalmente, descubrí que tenía que agregar las siguientes dependencias:
Cliente----gt; Gateway----gt; Ribbion Load Balancing Tomar servicio A ----gt;
Spring Cloud Ribbon se ha eliminado en versiones posteriores
RouteRececord es un servicio utilizado por el servicio Ribbion, pero no funciona. >
RouteRecordGlobalFilter Este filtro global se utiliza principalmente para registrar la dirección proxy real después del enrutamiento y el tiempo de llamada consumido. Si miramos la descripción de RouteToRequestUrlFilter, vemos que la dirección de ruta real se guarda en ServerWebExchange a través de un atributo llamado ServerWebExchangeUtils.GATEWAY_REQUEST_URL_ATTR.
La clase de configuración automática GatewayLoadBalancerClientAutoConfiguration en la puerta de enlace.
Esta clase de configuración automática debe ejecutarse después de la clase de configuración automática RibbonAutoConfiguration, y la clase de configuración automática RibbonAutoConfiguration es parte de la clase de configuración automática spring-cloud-netflix-ribbon, por lo que debe introducir lo siguiente dependencias del paquete jar
p>
Utilice el área funcional predeterminada y la configuración del área funcional es la siguiente
Sitio web oficial de Spring Cloud LoadBalancer
Spring Cloud Load Balancer no es un proyecto independiente, sino spring- Un módulo de cloud-commons, por lo que se pueden encontrar muchas configuraciones y clases en spring-cloud-commons. Clases de configuración automática en la puerta de enlace ReactiveLoadBalancerClientAutoConfiguration
Spring Cloud proporciona su propia abstracción e implementación del balanceador de carga del cliente. Para los mecanismos de equilibrio de carga, ReactiveLoadBalancer agrega interfaces y proporciona implementaciones aleatorias y por turnos. Para obtener una instancia, seleccione de una lista de proveedores de instancias de servicio reactivo (ServiceInstanceListSupplier). Actualmente admitimos una implementación basada en el descubrimiento de servicios, ServiceInstanceListSupplier, que recupera instancias disponibles del descubrimiento de servicios utilizando el cliente de descubrimiento disponible en el classpath.
Introduzca dependencias:
La configuración es la siguiente:
Leer servicios de archivos de configuración en lugar de descubrir servicios automáticamente desde el registro de servicios
Nota: Si hay clases relacionadas con Spring Cloud Ribbon en la ruta de clases del proyecto, debe deshabilitar la función Ribbon mediante la configuración. Debido a que Spring Cloud prefiere Ribbon de forma predeterminada, spring.cloud.loadbalancer.ribbon.Ribbon.ServiceInstanceListSupplier estará deshabilitado. cloud.loadbalancer.ribbon.enabled deshabilitará la llamada Ribbon, que también se menciona arriba.
Sitio web oficial de SimpleDiscoveryClient
SimpleDiscoveryClient se puede utilizar en combinación con el registro o se puede configurar de forma estática. Si no hay ninguna instancia de DiscoveryClient en la ruta de clase que admita el descubrimiento de servicios del registro, se usa una instancia de SimpleDiscoveryClient, que usa SimpleDiscoveryProperties para obtener información sobre el servicio y la instancia. Consulte la configuración en el archivo de configuración anterior.
Configuración de propiedades de instancia de servicio SimpleDiscoveryProperties
DefaultServiceInstance Definición de instancia de servicio predeterminada
ReactiveLoadBalancer utiliza la implementación de RoundRobinLoadBalancer de forma predeterminada. Para cambiar a una implementación diferente para servicios seleccionados o para todos los servicios, puede utilizar un mecanismo de configuración personalizado de LoadBalancer.
Por ejemplo, puede pasar la siguiente configuración a través de la anotación @LoadBalancerClient para cambiar al uso de RandomLoadBalancer:
Comprobación del estado de la instancia del sitio web oficial de LoadBalancer
Puede habilitar la programación de comprobación del estado de LoadBalancer. Para ello, proporcionamos un HealthCheckServiceInstanceListSupplier. Verificará periódicamente que la instancia proporcionada por ServiceInstanceListSupplier del delegado todavía exista y solo devolverá instancias en buen estado a menos que no haya ninguna, luego devolverá todas las instancias recuperadas.
Este mecanismo es particularmente útil cuando se utiliza SimpleDiscoveryClient. Para los clientes respaldados por el registro de servicios real, no es necesario utilizar esto ya que ya tenemos una instancia en buen estado después de consultar el ServiceDiscovery externo.
Este proveedor también se recomienda para configuraciones con solo una pequeña cantidad de instancias por servicio para evitar volver a intentar instancias si falla una llamada.