一、使用Feign的原因
有ribbon还不香么？ribbon有那么多的算法：负载均衡、随机、最佳选择等等。
但是ribbon写代码第一是比较冗余，多冗余呢？
restTemplate.opsFor("serviceUrl, 返回值")
而我们微服务其实讲究面向接口编程，更加喜欢这种操作，比如下面的：
serviceInterfaceA.doSth()
第二，ribbon没有类似于熔断的功能，在面对高并发的时候，无法合理进行熔断。严重的时候甚至可能会影响服务的上下游，引起服务链路的瘫痪。至于为啥说会引起瘫痪。这个可能不是我们这个章节关心的重点。
而FEIGN，除了整合了Ribbon， 还另外融入了Hystrix（熔断框架），并且也是面向接口编程，更加符合我们的编程习惯。
二、Feign的整体流程图
我们知道，Feign有以下几个特点：
- 面向接口编程
- 整合ribbon和hystrix
- 作为spring cloud 的远程通讯组件
大白话：
服务A想调用服务B的功能， 服务B的interface打成一个jar, 然后服务A引用了服务B的jar。
注意的是，服务A是只会对这个服务B的interface进行调用，而不能去管B的interface实现。
玩过微服务的大概知道我说什么...
然后feign底层将服务B的interface进行了动态代理，动态代理的类是和ribbon和hystrix整合的
在没被熔断的情况下，走ribbon的访问算法，包括 轮询，随机访问 等等。然后就是利用@FeignClient上注解的value
来访问服务B对应的地址，就完成了所谓spring cloud下的rpc调用了。
