配置feign+ribbon+hystrix踩坑记录 _接口

先前公司使用的是在开源微服务框架的基础上二次开发的，后来伴随着业务不断增多，逐渐发现项目规模大到一定程度，其实天天解决的并不是BUG，而是执行效率问题，整天被time-out问题困扰，我逐渐有了需要重新捋一遍框架的冲动，这里多说一句，现在开源微服务框架很多，很多公司项目工期紧张，会直接购买或者拿开源的框架搭建业务平台，我对这点不是很认同，因为别人的框架，咱们学习一下还行，直接用的话，出了问题都不清楚如何解决，特别是微服务类平台，就是java技术及相关组件的大杂烩，如果项目当天晚上要发版，突然出现个问题，因为使用别人的框架，不晓得问题出在哪？咋办呢？跑路都来不及，所以还是需要一点一点搭建框架，虽然慢点，但心里踏实。最近研究微服务间通信，涉及feign、、，原来一直用，但一直没过多关注，反正就是在yml里配一山的东西，这么多配置信息，就属它的配置多。打算好好看一看，至于看它的原因，是因为日常工作中服务间通信效率问题实在是把我坑死了。这次又是搞了一天才搞定，踩了很多坑，担心后面忘了，记录一下，分享出来给大家看看
一、第一坑
一般网上的资料或教程在配置的时候，都是直接在启动类上直接加上注解@，由于我的框架场景不是这样，说个题外话哈，我玩微服务也有些时间了，根据以往经验，我认为微服务框架中的服务可以大体分为三类，第一类是工具服务，比如说网关、、、nacos等，第二类是可以写成通用功能的微服务，最典型的就是认证中心、鉴权中心还有管理客户信息的客户中心，这类服务就是固定的业务，就拿认证中心来说把，其实就是干一件事，用户是谁的问题吗？其实就是搞一些如何生成token以及如何解析token的那些事，但有了网关之后，这部分功能就放在网关层了，因为token是无状态的，如果是，还要判断token本身的失效时间以及缓存刷新时间，说实话，代码不复杂，逻辑有点复杂，后面我会拿单独的一篇文章聊聊。像这类服务如果肯用点心的话，完全可以写成通用的，暴露出接口之后，可以远程支撑其他业务服务，相信我，只要用心一定是可以做到的。另外还有一类服务就是业务服务，这就得根据项目现用现写了，带过团队的人都知道，你不可能保证团队的所有开发人员都是高手，大部分人还是整天干CRUD的活的，但像网关、认证中心、鉴权中心等核心服务，最好不要让他们接触到，不定谁手贱给你改了代码，查问题很困难，所以我搭建架构的原则是：1、最核心的代码封装在jar包里依赖（的自动注入是个好东西，哈哈）；2、核心的微服务要在独立的一个maven工程里的，除了核心骨干人员，其他人就不要接触了；3、普通的业务微服务也是一个独立的maven工程，这样一般的开发人员就老老实实干CRUD的活吧，干成狗屎也影响不了大局。
正因为上述原因，我将提供端的feign接口单独在放在一个jar文件里，通过maven把依赖暴露出来，然后在调用端里引入依赖，这样就实现了彻底解耦，而且再有其他调用端调用的话，直接引入依赖调用接口就行了，但也因为如此，我的坑也就随之而来了.......
1、提供端代码片段
2、调用端代码片段
在调用端测试类调用的时候，日志报feign接口没有对应的实现bean，日志我看明白了，但问题不晓得出在哪，最后才发现，原来由于feign接口提供端以及调用端已经不再一个工程目录了，根本就扫描不到，也就没法进行生成bean进行注入，于是我就在提供端的启动类和调用端的启动类上加上了扫描路径：
1、接口提供端启动类