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吗？

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

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

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

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

我们上篇已经知道PollingServerListUpdater有可能是负责与Eureka交互定时获取服务列表的，本篇我们就剖析下这个组件相关的逻辑。