Dubbo 超时和重试的默认值，坑了我们一次

现象：下游一次慢查询发布，我们服务线程池瞬间打满熔断。复盘发现 Dubbo 默认配置是帮凶——超时 1000ms，retries 2，总尝试 3 次。下游 RT 涨到 1.2 秒后，每次调用要 3 秒多才放弃，还自动换实例重试两次，失败流量放大三倍，线程全挂在等待里。

修正的配置：

dubbo:
  consumer:
    timeout: 800        # 参考下游 P99 的 1.5 倍收紧
    retries: 0          # 全局关闭重试
    loadbalance: roundrobin
  provider:
    threads: 200        # 服务端执行线程上限
    threadpool: fixed

重试的分界线是幂等：查询可以 retries 1；写操作默认 0，个别要重试的写接口先做幂等再在方法级覆盖。超时值两边要对齐一个认知：Dubbo 在消费端计时，消费端放弃后提供端可能还在跑，白耗资源，所以 provider 也要配自己的执行超时兜底。

另外两个实战参数：cluster 容错模式，默认 failover 会重试切换实例，写操作用 failfast，日志上报这类可丢的用 failsafe；actives 限制单方法并发，防一个慢方法吃光线程池——线程池隔离的思路在 RPC 层同样成立。改完之后同类下游抖动再现时，我们侧只是错误率短时上升，不再连坐线程池。超时和重试是稳定性的一对基线参数，默认值只适合 demo，生产必须显式声明。