Spring Cloud - 错误信息:NUMBEROF_RETRIES_NEXTSERVER_EXCEEDED

本文介绍了解决Feign中因重试机制导致的NUMBEROF_RETRIES_NEXTSERVER_EXCEEDED错误的方法,并提供了一个示例来展示如何通过配置禁用Feign的默认重试功能。

今天在系统出现一个错误信息,如下:

Whitelabel Error Page

This application has no explicit mapping for /error, so you are seeing this as a fallback.

Thu Feb 08 10:21:23 CST 2018
There was an unexpected error (type=Internal Server Error, status=500).
NUMBEROF_RETRIES_NEXTSERVER_EXCEEDED

查资料才知道:

NUMBEROF_RETRIES_NEXTSERVER_EXCEEDED:超过重试服务器数量
NUMBEROF_RETRIES_EXCEEDED:超过重试数量

在使用Feign中,查看 Feign.java 发现有默认重试机制,默认重试5次

public Default() {
  this(100, SECONDS.toMillis(1), 5);
}

public Default(long period, long maxPeriod, int maxAttempts) {
  this.period = period;
  this.maxPeriod = maxPeriod;
  this.maxAttempts = maxAttempts;
  this.attempt = 1;
 }


解决的办法

1.可以禁止重试

/**
	 * @Title: feignRetryer
	 * @Description: 禁止重试
	 * @return
	 */
	@Bean
	Retryer feignRetryer() {
		return new Retryer() {
			@Override
			public void continueOrPropagate(RetryableException e) {
				throw e;
			}

			@Override
			public Retryer clone() {
				return this;
			}
		};
	}



<think>好的,用户现在问的是在基于Apollo的热更新下,给出的这些配置是否支持热更新。首先我需要回顾之前的对话,用户之前已经确认过他们的热更新是基于Apollo的,所以这次的问题是在这个前提下的。 用户提供的配置包括Micrometer的分布统计设置和Kafka的生产者消费者配置。我需要分析每个配置项是否可以通过Apollo实现热更新。首先,Apollo本身支持动态更新配置,但具体到每个配置项是否能生效,还要看Spring Boot是否支持通过@RefreshScope来刷新这些配置。 对于Micrometer的`distribution.percentiles-histogram`相关的配置,这些属于监控指标的采集配置。通常,这类配置在应用启动时初始化,运行时修改可能不会生效,因为指标注册是静态的。需要检查Micrometer是否支持动态调整这些设置,或者是否需要重启服务才能应用更改。 接下来是Kafka的配置。生产者和消费者的参数,比如`bootstrap-servers`、`retries`、`batch-size`等,这些参数在Kafka客户端初始化时设置。如果这些配置被封装在配置类中,并且使用了@RefreshScope,那么理论上可以通过Apollo的热更新来动态修改。但需要注意,某些配置如`bootstrap-servers`如果在运行时改变,可能需要重新创建生产者或消费者的实例才能生效,否则旧的连接可能仍然使用旧的服务器地址。 另外,用户提到的`event-center`下的配置,比如线程名称和消费者ID前缀,这些可能属于自定义配置。如果这些配置在代码中通过@Value注入,并且配置类使用了@RefreshScope,那么修改后应该能触发刷新。但需要确保这些配置的变更不会影响到正在运行的线程或消费者实例,否则可能需要重启相关组件。 还需要考虑Apollo的配置推送机制。Apollo支持实时推送配置更新,但应用端需要正确集成Spring Cloud的自动刷新功能,即使用`@RefreshScope`注解,并且配置中心的配置项被正确监听。对于Kafka的配置,如果这些配置项被定义在Apollo中,并且对应的Bean被@RefreshScope修饰,那么修改后应该能触发Bean的重新创建,从而应用新的配置。 不过,有些配置可能无法热更新,比如Kafka的`bootstrap-servers`,如果在运行时修改,现有的生产者或消费者可能无法切换到新的服务器,除非重新初始化这些客户端。同样,像`max-in-flight-requests-per-connection`这样的参数,修改后可能需要重启Kafka生产者才能生效。 总结来说,需要分情况讨论:哪些配置项可以通过@RefreshScope动态刷新,哪些需要重启服务。同时,要提醒用户注意某些配置的动态更新可能带来的风险,比如连接中断或数据丢失,尤其是在Kafka消费者组重新平衡的情况下。 最后,用户可能需要具体的示例或配置方式,比如如何将这些配置项放入Apollo,并确保它们被正确监听和刷新。此外,建议用户测试关键配置的热更新效果,以确保在实际环境中不会出现问题。 </think>这些配置项在 **Apollo 配置中心** 的支持下,**部分可以热更新**,但需结合 `@RefreshScope` 注解和 Spring Boot 的动态配置能力。以下是具体分析: --- ### **1. Micrometer 指标配置(`distribution.percentiles-histogram`)** ```yaml distribution: percentiles-histogram: http_request_duration: true event_frontend_request_duration: true third_party_api_calls_duration: true ``` - **是否支持热更新**:✅ **支持**(需配合 `@RefreshScope`) - **原因**: - 这些配置属于 Micrometer 的指标采集规则,通常通过 `MeterRegistryCustomizer` 注册。 - 如果使用 `@RefreshScope` 包裹相关 Bean,修改配置后可通过 `/actuator/refresh` 接口动态刷新。 - **限制**:已注册的指标(如 `http_request_duration`)在运行时无法动态增减,需重启服务才能生效。仅未注册的新指标可热更新。 --- ### **2. Kafka 生产者/消费者配置** #### **生产者配置** ```yaml kafka: producer: servers: ${KAFKA_PRODUCER_SERVERS} max-in-flight-requests-per-connection: 5 retries: 3 ... ``` - **是否支持热更新**:✅ **部分支持** - **支持的配置项**: - `retries`、`batch-size`、`linger` 等非连接相关的参数可通过 `@RefreshScope` 动态更新。 - `servers`(即 `bootstrap-servers`):**不支持热更新**。修改后需重启 Kafka 生产者客户端才能生效。 - **原因**: - Kafka 生产者客户端在初始化后,其核心配置(如 `bootstrap-servers`)不可变。动态修改需重建生产者实例。 #### **消费者配置** ```yaml kafka: consumer: servers: ${KAFKA_CONSUMER_SERVERS} max-poll-interval: 300000 session-timeout: 10000 ... ``` - **是否支持热更新**:✅ **部分支持** - **支持的配置项**: - `max-poll-interval`、`session-timeout` 等参数可通过 `@RefreshScope` 动态更新。 - `servers`(即 `bootstrap-servers`):**不支持热更新**。修改后需重启消费者客户端。 - **原因**: - Kafka 消费者组的 `bootstrap-servers` 修改后,需重新分配分区并重新拉取数据,无法热更新。 --- ### **3. 自定义配置(`event-center.common.*`)** ```yaml event-center: common: thread-name: vms_core_server consumer-id-prefix: ${spring.application.name} ``` - **是否支持热更新**:✅ **支持**(需配合 `@RefreshScope`) - **原因**: - 如果这些配置通过 `@Value` 或 `@ConfigurationProperties` 注入到 Bean 中,并且 Bean 被 `@RefreshScope` 修饰,则修改后可热更新。 - 例如,`thread-name` 若用于线程池命名,修改后新创建的线程会应用新值,但已存在的线程仍使用旧值。 --- ### **4. 实现热更新的关键条件** - **依赖 Apollo 的动态推送**:配置项需存储在 Apollo 中,并通过 `@Value` 或 `@ConfigurationProperties` 绑定到代码。 - **使用 `@RefreshScope` 注解**:对依赖配置的 Bean 添加注解,例如: ```java @RefreshScope @ConfigurationProperties(prefix = "kafka.producer") public class KafkaProducerConfig { // ... } ``` - **触发刷新**:通过调用 `/actuator/refresh` 接口或集成 Spring Cloud Bus 实现远程刷新。 --- ### **5. 限制与注意事项** - **Kafka 核心连接参数**:`bootstrap-servers`、`group.id` 等参数无法热更新,需重启服务。 - **线程池/连接池配置**:动态修改后可能需要重建线程池或连接池实例才能生效。 - **指标注册**:Micrometer 的指标注册是静态的,动态新增指标需重启服务。 --- ### **示例场景** 假设将 `kafka.producer.retries` 配置到 Apollo 中,并添加 `@RefreshScope`: ```yaml # Apollo 配置 kafka: producer: retries: 5 ``` ```java @RefreshScope @ConfigurationProperties(prefix = "kafka.producer") public class KafkaProducerProperties { private int retries; // getter/setter } ``` 修改 `retries` 后调用 `/actuator/refresh`,新的 Kafka 生产者会应用更新后的重试次数。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值