バックグラウンド
しばらく前に、同僚が問題に遭遇しSpringCloud、のFeign呼び出しSpringCloudでカスタムURLを使用する必要がありました。カスタムURLが必要になる場合があります。
ただし、特別なものもあります。たとえば、ここでToBシーンURL、各販売者向けにカスタマイズされたものを呼び出す必要があります。
ネイティブFeignまたはOKHTTP Client、これらのソリューションは別の方法で作成する必要があります。
既存のものを使っSpringCloud OpenFeignてですが、結局のところ、ネイティブのFeignは実際にこの関数をサポートしてSpringCloud OpenFeignおり、これに基づいてレイヤーをカプセル化するだけです。
インターフェース宣言にURIパラメーターのでURI、動的URLの呼び出しごとに異なるパラメーターを渡すことができます。
アイデアは単純ですが、実際にはそれほど多くはありません。擬似コードは次のとおりです。
@FeignClient(name = "dynamic")
interface DynamicClient {
@GetMapping("/")
String get(URI uri);
}
dynamicClient.get(URI.create("https://github.com"));
复制代码実行後、負荷分散の例外がスローされます。
java.lang.RuntimeException: com.netflix.client.ClientException:
Load balancer does not have available server for client: github.com
复制代码この例外も理解できます。つまり、githubサービスが見つかりません。結局、それは内部的に登録されたサービスではないため、見つからないのは合理的です。
しかしFeign、のURIこのパラメーターがインターフェースで宣言されている限り、カスタマイズすることができます。同時に、ネイティブのFeignでテストしたので、問題はありません。
デバッグ
その問題はSpringCloud OpenFeign、あります;同僚の検索の後、私は問題を解決したインターネット上のブログを見つけました。
記事によると、実際にはURLパラメータを追加して値を設定するだけで済みますが、理由は不明です。
本着打破砂锅问到底的精神，我个人也想知道 OpenFeign 是如何处理的，只要 url 有值就可以，这完全是个黑盒，而且在官方的注释中并没有对这种情况有特殊说明。
所以我准备从源码中找到答案。
既然是 url 有值就能正常运行，那一定是在运行过程中获取了这个值；
但我在源码中查看 url 所使用的地方，并没有在单测之外找到哪里有所应用，说明源码中并没有直接调用
url() 这个函数来获取值。
但 org.springframework.cloud.openfeign.FeignClient 这个注解总会使用吧，于是我又查询这个注解的使用情况。
最终在这里查到了使用的痕迹。
这里查阅源码时也有一些小技巧，比如如果我们直接查询时，IDEA 默认的查询范围是整个项目和所有依赖库，会有许多干扰信息。
比如我这里就需要只看项目源码，单测这些都不用看；所以在查询的时候可以过滤一下，这样干扰信息就会少很多。
左边的工具栏还有许多过滤条件，大家可以自行研究一下。
接着从源码中进行阅读，会发现是将 @FeignClient 中的所有数据都写到一个 Map 里进行使用的。 最终会发现这个 url 被写入到了
FeignClientFactoryBean 中的 url 成员变量中了。
查看哪里在使用这个 url 就知道背后的原理了。
在这里打个断点会发现：当 url 为空时会返回一个 LoadBalance 的 client，也就是会从注册中心获取 url 的客户端，而 url 有值时则会获取一个默认的客户端，这样就不会走负载均衡了。
所以我们如果想在 OpenFeign 中使用动态 url 时就得让 @Feign 的 url 有值才行，无论是什么都可以。
Feign 的实现
既然已经看到这一步了，我也比较好奇 Feign 是如何做到只要有 URI 参数就使用指定的 URL 呢？
这里也分享一个读源码的小技巧，如果我们跟着程序执行的思路去一步步
debug的话会非常消耗时间，毕竟这类成熟库的代码量也不小。
这里我们从官方文档中可以得知只要在接口参数中使用了 java.net.URI 便会走自定义的 url，所以我们反过来只要在源码中找到哪里在使用 java.net.URI 便能知道关键源码。
毕竟使用 java.net.URI 的场景也不会太多。
所以只需要在这个依赖的地方
cmd+shift+f 全局搜索 java.net.URI 就能查到结果，果然不多，只有两处使用。
再结合使用场景猜测大概率是判断参数中是否是有
URL.class 这样的条件，或者是 url 对象；总之我们先用 URL 这样关键字在这两个文件中搜索一下，记得勾选匹配大小写；最后会发现的确是判断了参数中是否有 URL 这个类，同时将这个索引位置记录了下来。
想必后续会通过这个索引位置读取最终的 url 信息。
最终通过这个索引的使用地方查询到了核心源码，如果有值时就取这个 URI 中所指定的地址作为 target。
到此为止这个问题的背后原理都已经分析完毕了。
总结
其实本文重点是分析了一些 debug 和阅读源码的一些小技巧，特别是在读关于 Spring 相关的代码时一定不能 debug 跟踪到细节中，因为调用链通常是很长的，稍不留神就把自己都绕晕了，只需要知道核心、关键源码是如何处理的即可。
最后对于 OpenFeign 处理动态 url 的方案确实也有些疑惑，是一个典型的约定大于配置的场景，但问题就在于我们并不知道这个约定是 @Feign 的 url 得有值。
所以我也提了一个 PR 给 OpenFeign，感兴趣的朋友也可以查看一下：