Entrevistador: ¿Por qué Fingir es tan lento para la primera llamada?

  • prefacio

  • Cómo se carga la cinta

  • RibbonClientConfiguration

  • Equilibrador de carga ZoneAware

  • Estrategia de equilibrio de carga de la cinta

  • Modo Ribbon-eager-load (carga hambrienta)

  • Habilitar la carga de hambre de la cinta

  • Resumir


prefacio

En primer lugar, debemos comprender cómo Feign realiza llamadas remotas, incluida la relación entre el registro, el equilibrio de carga y FeignClient. Los microservicios se pueden registrar en el servidor a través de eureka o nacos. Finge depende de Ribbon para la carga. Y Ribbon necesita obtener la lista de servicios del centro de registro, almacena en caché la carga del servicio localmente y luego llama el cliente FeignClient, que probablemente sea un proceso de este tipo.

Un blog separado de front-end y back-end basado en Spring Boot + MyBatis Plus + Vue 3.2 + Vite + Element Plus, que incluye un sistema de gestión en segundo plano que admite funciones como artículos, categorías, gestión de etiquetas y paneles.

  • Dirección de GitHub: https://github.com/weiwosuoai/WeBlog

  • Dirección de la casa rural: https://gitee.com/AllenJiang/WeBlog

 
 

Cómo se carga la cinta

En primer lugar necesitamos saber cómo se carga el Ribbon, es decir, cómo obtener la lista de servicios de nacos y eureka, que es muy importante.

imagen

Cómo se carga la cinta

RibbonClientConfiguration

A través de LoadBalancer en la clase RibbonClientConfiguration, sabemos que la cinta se basa en LoadBalancer para realizar la carga, que no es más que el método de la interfaz ILoadBalancer, seguido de agregar un nuevo servicio, seleccionar un servicio en el balanceador de carga, marcar ServerDown servicio fuera de línea, obtener la lista de servicios y obtener el servidor sobreviviente, obtener todos los servidores (tanto en buen estado como en mal estado)

imagen

Interfaz ILoadBalancer

Equilibrador de carga ZoneAware

El loadBalancer predeterminado es el balanceador de carga ZoneAwareLoadBalancer. Al heredar el método restOfInit de la clase principal DynamicServerListLoadBalancer, hay dos métodos más importantes, enableAndInitLearnNewServersFeature y

método updateListOfServers

imagen

método restOfInit

método enableAndInitLearnNewServersFeature.

LOGGER.info("Using serverListUpdater {}", serverListUpdater.getClass().getSimpleName());
serverListUpdater.start(updateAction);

Veamos la implementación del método ServerListUpdater.start y obténgalo a través de un subproceso personalizado, que es obtener la lista de servicios.

imagen

ServerListUpdater.inicio

Estrategia de equilibrio de carga de la cinta

Se ha mencionado la adquisición de la lista de servicios, por supuesto, también es necesario hablar sobre la estrategia de balanceo de carga, hay siete tipos principales;

  • RoundRobinRule (estrategia de sondeo, que se llama a su vez según el orden de los servicios)

  • WeightedResponseTimeRule (estrategia de relación de peso, dar prioridad a los servicios con una relación de peso alta, es decir, servicios con un tiempo de respuesta corto, cuanto mayor sea el tiempo de respuesta, menor será la relación de peso)

  • RandomRule (estrategia aleatoria, seleccione aleatoriamente un servicio de la lista de proveedores de servicios)

  • BestAvailableRule (estrategia de número mínimo de conexiones, obtener la instancia de servicio con el menor número de conexiones en la lista de servicios)

  • RetryRule (estrategia de reintento, reintentar para obtener servicios no válidos, devolver NULL si no se obtiene el tiempo especificado)

  • AvailabilityFilteringRule (política sensible a la disponibilidad, filtrar instancias de servicio en mal estado, seleccionar lianji)

  • ZoneAvoidanceRule (política sensible a la zona)

En cuanto a la estrategia de balanceo de carga personalizado, no pertenece al alcance de este artículo. Si está interesado, consulte: https://t.zsxq.com/0fPeLWdXo.

Un blog separado de front-end y back-end basado en Spring Boot + MyBatis Plus + Vue 3.2 + Vite + Element Plus, que incluye un sistema de gestión en segundo plano que admite funciones como artículos, categorías, gestión de etiquetas y paneles.

  • Dirección de GitHub: https://github.com/weiwosuoai/WeBlog

  • Dirección de la casa rural: https://gitee.com/AllenJiang/WeBlog

 
 

Modo Ribbon-eager-load (carga hambrienta)

La cinta para el cliente de carga se crea después de que se inicia el servicio y cuando se produce una llamada

Cliente, por lo que cuando se produce la primera llamada de solicitud http, no solo se debe contar el tiempo de solicitud http, sino también el tiempo de creación del cliente, por lo que la primera llamada será muy lenta, escriba una llamada de método.

El servicio del sistema llama al servicio System2

@GetMapping("/requestSystem2Api")
public String requestSystem2Api(){
    long startTime = System.currentTimeMillis();
    R<String> stringR = iTestServiceClient.testRequestMethod();
    if (null !=stringR){
        log.info("接口返回:"+stringR.getMsg());
    }
    long needTime = System.currentTimeMillis() - startTime;
    log.info("接口调用需要的时间:"+needTime);
    return "";
}

Se puede ver en el registro de llamadas que cuando se llama al servicio System2 por primera vez, DynamicServerListLoadBalancer de Ribbon cargará el cliente ficticio y luego realizará una llamada. El tiempo para la primera llamada será más largo y la segunda llamada puede ser directamente solicitado El tiempo de llamada es rápido.

imagen

Lento la primera vez, rápido la segunda

Habilitar la carga de hambre de la cinta

ribbon:
nacos:
  enabled: true # 开启naocos轮询
eager-load:
 enabled: true  # 开启Ribbon的饥饿加载模式(防止第一次请求超时的问题)
 clients: Lxlxxx-system2 # 指定需要开启的服务(需要开启Ribbon的饥饿加载模式)
 ReadTimeout: 10000
 ConnectTimeout: 10000
 MaxAutoRetries: 0
 MaxAutoRetriesNextServer: 1
 OkToRetryOnAllOperations: false

Cuando se inicia el proyecto, puede ver en el registro que el servicio Lxlxxx-system2 se ha cargado, evitando así el tiempo de espera de la primera solicitud.

imagen

Habilitar la carga de hambre de la cinta

Resumir

De hecho, este modo de carga por inanición es similar a una operación de "calentamiento de carga del cliente". Se carga cuando el proyecto comienza para evitar que las llamadas entre servicios provoquen un tiempo de espera de la interfaz debido al volumen de datos y la complejidad del procesamiento de la lógica empresarial. Si su servicio Llamar al procesamiento comercial entre llamadas es complicado y lento, por lo que también puede probar esta solución.

 
 
 
 
 
 
 
 
 

Supongo que te gusta

Origin blog.csdn.net/2301_78588786/article/details/131901617
Recomendado
Clasificación