关于springcloud openfeign core 3.3.0-M3 实现服务单元动态化指定服务名

关于springcloud openfeign core 3.3.0-M3 实现服务单元动态化指定服务名
首先感谢这篇文章：[Spring-cloud-openfeign3.0服务单元化动态指定服务名]
以及楼主点拨，之前没往哪想，总觉得这个新技术，Spring-cloud-openfeign3.0源码少了一个参数！

关于动态化指定服务名，起源是，因需要实现多个节点的互通，但是类似阿里 淘宝的节点 的 单元化架构。

因为节点类似，所以首先有共性了。但是他们又不是copy，所以有自己的特性。单纯的靠feign实现的负载均衡，已经不适用了，但是多节点时，又需要大量代码。那么有没有办法实现类似负载均衡，一样的方便性？

 答案：有的。

在大量节点时，我们的便捷就很重要了。所以引出了，openfeign动态化实现节点指定。

当你需要路由一个节点，但是你又不清楚，某时刻是那个节点。当传统的固定写法很繁琐，不适用后。动态化应运而生。

一个动态化的节点互通，尤其是有多级节点的情况下。极大减少代码量、方便了你的开发和后期节点变动的维护。不需要频繁的停机更新。
此处关于代码？有些不想写。我提到的文章里面代码已经有了，毕竟人家前辈已经写了。后面看想不想加进来。

想说的是，关于引入这个新的依赖，造成的冲突和依赖的引入。

1.引入： 你需要亲自去maven官网，仓库下载。手动奥！放入你的仓库，自己放，然后一些文件会自动生成，一个需要自己复制粘贴修改一下。
自动习惯了，手动都忘了，结果卡了半天，网 也不怎么好。

2.冲突： 引入必然和你的依赖相互冲突。此处，如果你是大佬请直接掠过。
冲突后，吧冲突的依赖先屏蔽掉，也就是这个引得依赖。然后看idea中（暂时只有这个，其他我不清楚）。依赖是什么，他所依赖的隐形依赖是哪个。
吧隐形依赖，复制出来。先放着！
然后吧冲突的依赖放开，看那里冲突。吧冲突的，部分，记下。
在原依赖里面吧冲突的部分屏闭掉，然后看还冲突不，后者报路径不存在。
那个就吧记下的，还有复制的。对比，将后面这个加入的依赖缺失的部分，单独引入。基本可以解决。
剩下的就是你自己的项目的问题了。

2. 关于这个Spring-cloud-openfeign3.0源码有个bug，挺恼火的，因为少参数，导致我耽搁好几天，还是对这套流程不熟悉，导致出问题，开始找不到思路，
3. 因为源码少个传参，导致动态无法确定目标，在这里停了两三天，甚至源码都研究了一天，发现少参数。
4. 那么问题来了，少参数，怎么解决，》》》获取header，从这里面取，这下是不是豁然开朗？这后面就不写了。因为获取header他这个挺简单的，但是当时一时间没转过弯，主要是跟这个配合时没想到。参数有了，你在写写逻辑，实现一下哎，不就能动态确定你的目标了吗？
5. 到这里基本就写完了。源码上面的文章有，自己的逻辑，需要你自己实现，我把遇到的坑给大家踩踩 ！ 少走冤枉路。这是最好的，

提一句因为少个参数，就为这个，我加了两个配置类，两个工具类，也是够了。后面看开发团队改进不！
实际上我这里遇到这问题，主要还是因为zuul网关，引入springcloud starter openfeign 依赖，需要整合，cloud体系，网关，导致的。如果像前辈那种直接只是用的Spring-cloud-openfeign3.0，不用zuul网关这套体系，为团体应该没这么多，那套体系我没试，直接上的我这套体系，前辈的思路截鉴参考了！

如果有问题可以提问，看到会回答的 ，奥对了，因为这个技术还没整合到springcloud体系中，所以，按照前辈的引入方式会冲突，我自己的方式和前辈的简单方式都试了，我的暂时没有什么问题。