Feign的运行时

实验

• 服务提供者ServiceA，5个实例，端口8081~8085
• 服务消费者ServiceB，1个实例，端口9000
• 注册中心，eureka-server，2个实例
• SpringCloud版本，Hoxton.RELEASE
• SpringBoot版本，2.2.1.RELEASE
• SpringCloudStarterOpenFeign版本，2.2.0.RELEASE

其实我们上文已经剖析到了Feign整合Ribbon后是依赖Ribbon的ZoneAwareLoadBalancer从ServerList中选出一个Server后，再替换服务名为IP+Port，然后调用Feign底层的HTTP客户端发起最后的真实的请求。

上文已经完整的分析了FeignClient被创建的过程，每个服务消费者被注入的ServiceAClient，其实都是他的动态代理实例，对ServiceAClient的任何方法调用，都会被委托给动态代理实例来完成，也就是SynchronousMethodHandler#invoke方法。本文就分析一下该方法的执行原理

上文我们已经分析到FeignClientFactoryBean#getTarget()方法，这里完成了FeignClient动态代理的创建。但并未分析具体的创建过程，本文将深入Feign Core将FeignClient到底是如何被创建出来的给摸清楚。

按照SpringCloud集成套路寻找线索

按照Spring的套路，肯定是提供一个EnableXXX的注解开启某项技术，Feign当然也不例外，还记得我们在入门篇里的EnableFeignClients吗？

Feign解决了什么问题

一个服务里要调用别的HTTP接口，每次要手写一些重复的HTTP处理逻辑，比如我们如果单独用Ribbon调用别的服务，就需要每次写这样一坨代码

String result = restTemplate.getForObject("http://ServiceName/InterfacePath", String.class);
虽然Spring的RestTemplate已经将HTTP调用的代码成本降到很低了，但如果极致一些，完全不写行不行？答案是可以。Feign就是提我们完成这件事情的不二之选。

终于，到了和Ribbon系列说再见的时候，笔者任务Ribbon的源码逻辑虽然比Eureka简单一些，但与Spring集成上稍微有点儿绕，主要是自动配置的执行顺序那块儿，如果采用静态代码阅读的方式的话，很难发现问题。不过，这也让笔者对Spring的自动配置机制有了更深的了解。

这篇文章算是前面三篇的一个总结，从一个请求被执行的角度，将Spring以及Ribbon的关键组件串起来思考。

Ribbon + Eureka感知故障实例的滞后性

我们先用一张图回顾一下Eureka客户端去Eureka Server拉取服务注册表的情况