Spring Boot集成Consul启动报No cluster leader错误原因及解决方案咨询

1. Consul集群请求路由的偶发异常：你使用的是Consul的Headless Service域名作为连接地址，K8s Headless Service会将请求轮询转发到所有Consul集群节点，当ConsulCatalogWatch的强一致性读请求刚好转发到还未完成raft日志同步的Follower节点、或者集群刚完成Leader选举的瞬间，就会触发该No cluster leader报错。该错误属于单次请求失败，下一次定时调度的watch任务会自动重试成功，因此应用本身运行不受影响。
2. 依赖版本的重试机制缺陷：你使用的spring-cloud-starter-consul-discovery:2.2.7.RELEASE依赖的consul-api:1.4.5版本，对集群状态异常的请求默认重试次数仅为1次，没有冗余重试逻辑，遇到上述偶发场景就会直接抛出ERROR级别的日志。
3. 配置拼写错误：你提供的配置中存在笔误，spring.cloud.consule.port=8500的属性名多写了一个e，正确属性名为spring.cloud.consul.port，只是因为Consul默认端口就是8500，所以暂时没有触发连接异常。

• 修正配置笔误：将spring.cloud.consule.port=8500替换为正确的spring.cloud.consul.port=8500，避免后续调整Consul端口时出现连接问题。
• 配置请求重试策略：在配置文件中添加如下重试配置，提升异常场景的容错能力：

# Consul请求重试配置
spring.cloud.consul.retry.enabled=true
spring.cloud.consul.retry.max-attempts=5
spring.cloud.consul.retry.initial-interval=1000
spring.cloud.consul.retry.max-interval=5000
spring.cloud.consul.retry.multiplier=1.2

• 优化Consul请求路由：可以在K8s中额外部署一个只指向Consul Leader节点的Service，将spring.cloud.consul.host修改为该Leader Service的域名，避免请求转发到未同步完成的Follower节点触发异常。
• 轻量兼容方案：如果不想修改业务配置，也可以调整日志输出级别，将org.springframework.cloud.consul.discovery.ConsulCatalogWatch的日志级别设置为WARN，过滤偶发的ERROR日志，该错误本身不影响业务正常运行，不需要额外处理也可正常使用。

内容的提问来源于stack exchange，提问作者Dolphin