前段产品自测阶段，发现了一个令人头疼的问题，服务启动之后，总是在一段时间之内time out。扒拉了许久代码，发现是网关中ribbon的超时配置不管用，还是默认配置，而本地环境启动访问太多，总是时不时就超时了。于是，决定深入研究一下。
配置如下：
ribbon发现无论如何都不生效，总是超时。手动黑人问号脸！！！
无奈，翻源码吧。
得益于idea的强大，没多久就找到了DefaultClientConfigImpl，进而找到了IClientConfig、CommonClientConfigKey、RibbonProperties、HttpClientRibbonConfiguration等类。
首先，DefaultClientConfigImpl各种逻辑，就一段最重要：
怎么办？打上个断点，调戏一番。咳咳，错了错了，是调试，调试，粗鲁了。
进入其取值方法，进一步跟踪：
一番调试（*&.~<>，差点又没忍住！！！），果然发现是默认值50，而不是预先配置的500。（二营长，你他娘的意大利炮呢？）
算了，忍一时风平浪静。经过一番探秘，好像发现了一点门道。CommonClientConfigKey中对这些配置项的定义都是UpperCamel，如图所示：
难道不支持自动转换吗？又去cloud源码spring-cloud-starter-netflix-ribbon、spring-cloud-netflix-ribbon中找了一通，发现了一段逻辑：
都是从原生配置类中获取参数值，而原生ribbon获取配置逻辑如下：
至于ConfigurationManager是个什么鬼，看下代码：
不管是啥，反正是获取系统配置。获取完配置以后，再设置到系统变量中。
看到这里，应该就明白了，这货竟然使用的是自己CommonClientConfigKey配置类的原始UpperCamel格式的property name，WTF？改改试试吧：
ribbon再次调试（这次忍住了，哈哈哈哈！）
大功告成！！！另外，稍微解释一下ribbon的配置格式，借用ribbon原生默认配置类DefaultClientConfigImpl的注释，说的很明白：
本文系【银河架构师】原创，如需转载请在文章明显处注明作者及出处。
微信搜索【银河架构师】，发现更多精彩内容。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
