Placement régulier
1. Désactivez Eureka.
Après avoir ajouté l'annotation @LoadBalanced à RestTemplate, nous pouvons utiliser le nom du service pour appeler l'interface. Lorsqu'il y a plusieurs services, l'équilibrage de charge peut également être effectué.
En effet, les informations de service dans Eureka ont été extraites localement sur le client. Si nous ne voulons pas intégrer Eureka, nous pouvons les désactiver via la méthode de configuration suivante.
# 禁用 Eureka
ribbon.eureka.enabled=false
Lorsque nous désactivons Eureka, le nom du service ne peut pas être utilisé pour appeler l'interface et l'adresse du service doit être spécifiée.
2. Configurez la liste d'adresses de l'interface. Comme
nous l'avons mentionné ci-dessus, Eureka peut être désactivé. Après la désactivation, vous devez configurer manuellement l'adresse du service appelant. La configuration est la suivante:
# 禁用 Eureka 后手动配置服务地址
ribbon-config-demo.ribbon.listOfServers=localhost:8081,localhost:8083
Cette configuration concerne des services spécifiques. Le préfixe est le nom du service. Après la configuration, vous pouvez utiliser le nom du service pour appeler l'interface comme auparavant.
3. Configurer la stratégie d'équilibrage de charge La stratégie
par défaut de Ribbon est l'interrogation Comme le montre la sortie de l'exemple que nous avons expliqué précédemment, Ribbon fournit de nombreuses stratégies, qui seront expliquées plus loin. Grâce à la configuration, nous pouvons spécifier la stratégie utilisée par le service pour effectuer les opérations de chargement.
4 **. Délai d'expiration **
Il existe deux paramètres liés au temps dans le ruban, à savoir le délai d'expiration de la connexion de la demande et le délai d'expiration du traitement de la demande. Les règles de configuration sont les suivantes:
# 请求连接的超时时间
ribbon.ConnectTimeout=2000
# 请求处理的超时时间
ribbon.ReadTimeout=5000
也可以为每个Ribbon客户端设置不同的超时时间, 通过服务名称进行指定：
ribbon-config-demo.ribbon.ConnectTimeout=2000
ribbon-config-demo.ribbon.ReadTimeout=5000
5. Paramètres de concurrence
# 最大连接数
ribbon.MaxTotalConnections=500
# 每个host最大连接数
ribbon.MaxConnectionsPerHost=500
Ruban de configuration de code
Le moyen le plus simple de configurer le ruban consiste à utiliser des fichiers de configuration. Bien sûr, nous pouvons également le configurer par le biais de code.
Pour configurer la stratégie de chargement précédemment personnalisée via le code, vous devez d'abord créer une classe de configuration et initialiser la stratégie personnalisée. Le code est illustré ci-dessous.
@Configuration
public class BeanConfiguration {
@Bean
public MyRule rule() {
return new MyRule();
}
}
Créez une classe de configuration client Ribbon, associez BeanConfiguration, utilisez name pour spécifier le nom du service appelé, le code est affiché ci-dessous.
@RibbonClient(name = "ribbon-config-demo", configuration = BeanConfiguration.class)
public class RibbonClientConfig {
}
Vous pouvez supprimer la configuration de stratégie dans le fichier de configuration précédent, puis redémarrer le service et accéder à l'interface pour voir le même effet qu'auparavant.
Configurer le ruban en mode fichier de configuration
En plus d'utiliser le code pour configurer le ruban, nous pouvons également spécifier la configuration correspondante pour le ruban via le fichier de configuration:
<clientName>.ribbon.NFLoadBalancerClassName: Should implement ILoadBalancer(负载均衡器操作接口)
<clientName>.ribbon.NFLoadBalancerRuleClassName: Should implement IRule(负载均衡算法)
<clientName>.ribbon.NFLoadBalancerPingClassName: Should implement IPing(服务可用性检查)
<clientName>.ribbon.NIWSServerListClassName: Should implement ServerList(服务列表获取)
<clientName>.ribbon.NIWSServerListFilterClassName: Should implement ServerListFilter(服务列表的过滤)
Mécanisme de nouvelle tentative
Dans un environnement de cluster, plusieurs nœuds sont utilisés pour fournir des services et il est inévitable qu'un nœud tombe en panne. Lorsque vous utilisez Nginx pour l'équilibrage de charge, si votre application est sans état et peut être publiée sur une base continue, vous devez redémarrer l'application une par une, de sorte que l'impact sur les utilisateurs est en fait relativement faible, car Nginx ne parvient pas à transmettre la demande La demande sera redirigé vers une autre instance.
Étant donné qu'Eureka est construit sur la base du principe AP, au détriment de la cohérence des données, chaque service Eureka enregistrera les informations de service enregistrées. Lorsque le battement de cœur entre le client enregistré et Eureka ne peut pas être maintenu, cela peut être dû au réseau ou au service J'ai raccroché.
Dans ce cas, Eureka enregistrera également les informations d'enregistrement pendant un certain temps. À ce stade, le client peut obtenir les informations de service qui ont raccroché, de sorte que le ruban peut obtenir les informations de service qui ont expiré, ce qui entraînera un échec de la demande.
Nous pouvons utiliser le mécanisme de nouvelle tentative pour éviter ce genre de problème. Le mécanisme de nouvelle tentative consiste à demander à nouveau un autre service lorsque le ruban constate que le service demandé est inaccessible.
**1. RetryRule 重试**
解决上述问题，最简单的方法就是利用 Ribbon 自带的重试策略进行重试，此时只需要指定某个服务的负载策略为重试策略即可：
ruban-config-demo.ribbon.NFLoadBalancerRuleClassName = com.netflix.loadbalancer.RetryRule
**2. Spring Retry 重试**
除了使用 Ribbon 自带的重试策略，我们还可以通过集成 Spring Retry 来进行重试操作。
在 pom.xml 中添加 Spring Retry 的依赖，代码如下所示。
