1.application.yaml配置如下：
提供者服务配置provider:
默认快速失败cluster: failfast
# 不进行重试
retries: 0消费者调用超时，没有进行快速失败，并且进行了重试三次 2.@DubboService(cluster = "failfast",methods = {@Method(name = "test", retries = 0)}) 即使在提供者针对方法级别进行配置，还是和第一个问题产生的结果一致
我在消费者方没有进行任何配置
retry 是一个客户端行为，不会受服务端的配置所影响。
背后的原因：如果两台服务端分别配置retry 1 和 3，那客户端怎么生效。retry 是单机的 retry 还是整体负载均衡的 retry。Dubbo 选择了后者，这样可以屏蔽单点异常，这也就导致了服务端无法配置 retry 参数。
您说的在consumer配置负载和retries应该是进入dubbo3之后才开始调整的吧？我之前一直用的2.7+版本一直是在provider中配置的cluster和retries完全没有问题。 如果provider不建议配置的话，应当尽早将属性@Deprecated话。
还有一个点，我这边在provider配置timeout经过测试是有效的，consumer没有进行配置。 那么基于您阐述的这个思路，如果一个服务端timeout设置为10秒，一个设置为20秒，那客户端怎么生效
timeout 是可以的，retry 的可能得检查下，按理 2.7 也是没法生效的
timeout 的逻辑是每个 provider 如果独立定义 timeout 是可以每次请求绑定的，即使切换不同 provider 重式也是没问题的。简单来说就是 timeout 是可以绑定 provider 的，是可以服务端定义的行为；retry 生效的时候因为还没选择 provider 所以无法从 provider 获取。
谢谢，收获良多
大佬，那你后面是如何解决重复调用这个问题？
@DubboReference(cluster = "failfast", retries = 0) 我是在消费端这么去配置的，可是当服务超时，还是会触发重复调用
用的什么版本，我测试的话都是没问题的