-
avant-propos
-
Comment le ruban se charge
-
RubanClientConfiguration
-
ZoneAwareLoadBalancer
-
Stratégie d'équilibrage de charge du ruban
-
Mode ruban-chargement avide (chargement affamé)
-
Activer le chargement de la faim du ruban
-
Résumer
avant-propos
Tout d'abord, nous devons comprendre comment Feign effectue des appels à distance, y compris la relation entre le registre, l'équilibrage de charge et FeignClient. Les microservices peuvent être enregistrés sur le serveur via eureka ou nacos. Feign s'appuie sur Ribbon pour le chargement. Et Ribbon doit obtenir la liste des services du centre d'enregistrement, cachez la charge du service localement, puis le client FeignClient appelle, ce qui est probablement un tel processus.
Un blog séparé front-end et back-end basé sur Spring Boot + MyBatis Plus + Vue 3.2 + Vite + Element Plus, comprenant un système de gestion d'arrière-plan qui prend en charge des fonctions telles que les articles, les catégories, la gestion des balises et les tableaux de bord.
Adresse GitHub : https://github.com/weiwosuoai/WeBlog
Adresse du gîte : https://gitee.com/AllenJiang/WeBlog
Comment le ruban se charge
Tout d'abord, nous devons savoir comment le ruban est chargé, c'est-à-dire comment obtenir la liste de service des nacos et eureka, ce qui est très important.
Comment le ruban se charge
RubanClientConfiguration
Grâce à LoadBalancer dans la classe RibbonClientConfiguration, nous savons que le ruban s'appuie sur LoadBalancer pour effectuer la charge, qui n'est rien de plus que la méthode de l'interface ILoadBalancer, suivie de l'ajout d'un nouveau service, de la sélection d'un service dans l'équilibreur de charge, du marquageServerDown service hors ligne, obtenir la liste des services et obtenir le serveur survivant, obtenir tous les serveurs (sains et non sains)
Interface ILoadBalancer
ZoneAwareLoadBalancer
Le loadBalancer par défaut est l'équilibreur de charge ZoneAwareLoadBalancer. En héritant de la méthode restOfInit de la classe parent DynamicServerListLoadBalancer, il existe deux méthodes plus importantes, enableAndInitLearnNewServersFeature et
méthode updateListOfServers
méthode restOfInitrestOfInit method
méthode enableAndInitLearnNewServersFeature.
LOGGER.info("Using serverListUpdater {}", serverListUpdater.getClass().getSimpleName());
serverListUpdater.start(updateAction);
Examinons l'implémentation de la méthode ServerListUpdater.start et obtenons-la via un thread personnalisé, qui consiste à obtenir la liste des services.
ServerListUpdater.start
Stratégie d'équilibrage de charge du ruban
L'acquisition de la liste de services a été mentionnée, bien sûr, il faut aussi parler de la stratégie d'équilibrage de charge, il en existe sept types principaux ;
-
RoundRobinRule (stratégie d'interrogation, qui est appelée à tour de rôle selon l'ordre des services)
-
WeightedResponseTimeRule (stratégie de rapport de poids, donner la priorité aux services avec un rapport de poids élevé, c'est-à-dire des services avec un temps de réponse court, plus le temps de réponse est long, plus le rapport de poids est faible)
-
RandomRule (stratégie aléatoire, sélection aléatoire d'un service dans la liste des fournisseurs de services)
-
BestAvailableRule (stratégie du nombre minimum de connexions, obtenir l'instance de service avec le plus petit nombre de connexions dans la liste des services)
-
RetryRule (réessayer la stratégie, réessayer d'obtenir des services invalides, renvoyer NULL si l'heure spécifiée n'est pas obtenue)
-
AvailabilityFilteringRule (politique sensible à la disponibilité, filtrer les instances de service non saines, sélectionner lianji)
-
ZoneAvoidanceRule (stratégie sensible à la zone)
Concernant la stratégie d'équilibrage de charge personnalisé, elle n'appartient pas au périmètre de cet article. Si vous êtes intéressé, consultez : https://t.zsxq.com/0fPeLWdXo.
Un blog séparé front-end et back-end basé sur Spring Boot + MyBatis Plus + Vue 3.2 + Vite + Element Plus, comprenant un système de gestion d'arrière-plan qui prend en charge des fonctions telles que les articles, les catégories, la gestion des balises et les tableaux de bord.
Adresse GitHub : https://github.com/weiwosuoai/WeBlog
Adresse du gîte : https://gitee.com/AllenJiang/WeBlog
Mode ruban-chargement avide (chargement affamé)
Le ruban pour le client de charge est créé après le démarrage du service et lorsqu'un appel se produit
Client, donc lorsque le premier appel de requête http se produit, non seulement le temps de requête http, mais aussi le temps de création du client doit être compté, donc le premier appel sera très lent, écrivez un appel de méthode.
Le service système appelle le service 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 "";
}
On peut voir dans le journal des appels que lorsque le service System2 est appelé pour la première fois, DynamicServerListLoadBalancer de Ribbon chargera le faux client puis passera un appel.Le temps du premier appel sera plus long et le deuxième appel pourra être directement Le temps d'appel est rapide.
Ralentir la première fois, vite la deuxième fois
Activer le chargement de la faim du ruban
ribbon:
nacos:
enabled: true # 开启naocos轮询
eager-load:
enabled: true # 开启Ribbon的饥饿加载模式(防止第一次请求超时的问题)
clients: Lxlxxx-system2 # 指定需要开启的服务(需要开启Ribbon的饥饿加载模式)
ReadTimeout: 10000
ConnectTimeout: 10000
MaxAutoRetries: 0
MaxAutoRetriesNextServer: 1
OkToRetryOnAllOperations: false
Lorsque le projet démarre, vous pouvez voir dans le journal que le service Lxlxxx-system2 a été chargé, évitant ainsi le délai d'expiration de la première requête.
Activer le chargement de la faim du ruban
Résumer
En fait, ce mode de chargement de famine est similaire à une opération de "préchauffage du chargement du client". Il est chargé au démarrage du projet pour éviter que les appels entre services ne provoquent un délai d'attente de l'interface en raison du volume de données et de la complexité du traitement de la logique métier. Si votre service Appeler le traitement des affaires entre les appels est compliqué et lent, alors autant essayer cette solution.