在工作实际开发中需要开发一个消息模块对外提供统一的接口feign调用提供消息加载到MQ队列的服务，采用泛型的形式。

刚开始搭建好之后，正好需要做一个全局的日志添加到zuul网关中，通过网关feign MQ模块发送到队列（这个操作是异步的，不会影响主要业务流程），随后log模块需要监听这个channel。之前消息模块刚搭建起来的时候是没有问题的，但是在我写统一的日志记录的时候，发生了意外情况。

情况一：Feign请求直接进入熔断而非处理器

上午排查了2个小时feign的调用过程中也没有发生报错，*本身是GET 请求也就是意味着是URI 传参后来因为特殊类型比较多，log传参采用的 body传参，记住这个点，破案的重点。

后来尝试body去了，继续采用GET请求仍然不行 * 这是另外一个情况造成的。

情况一：

无意间把body的传参给删除了，没有方向的时候也百度不到答案只能尝试从源码中找调用的问题但是没有研究过Feign的调用过程但是知道其最终肯定也是发送Http请求进行数据的交互，于是直接在Log模块中的dispatchServlet打上断点（因为从feign的请求过来 直接进入熔断，但是传参有值说明接收到了请求），接着一步一步的走过去发现竟然走通了，进入了最终的处理器，十分的震惊多次请求不敢相信，结果都通过了。后来不知道在哪里尝试重新传参，无意间发现Jackson序列化会提前将body，我的请求数据格式：{"name":"name", "age":"20", "user":{}}会直接将user 优先转换为LinkedHashMap，导致进入传参时会数据类型转换失败。后来将接收改成了Map 解决了问题。

情况二：

后来想到为什么之前也尝试了GET，把body传参去除为什么收不到消息呢？甚至会存在第一次channel收到，第二次channel没有收到。于是打开rabbitmq的管理端，发现log——channel 存在2个消费者，*** 但是我清晰的知道我就采用了一个消费者进行队列的监听。** 经过重启消费者全部清空，但是没过一会又会新增几个。突发奇想我目前开发环境使用了jrebel的热部署插件不会对项目重启而是重新加载修改的class并对bean进行重新加载，因为rabbitmq默认的consumer-tag 是随机的导致没有覆盖原有的消费者，形成了负载均衡和消息不可达。

经过实践测试原因找到并解决。