背景随着业务体量的增长，我们近期完成了交易核心链路的微服务拆分。为了在保证性能的同时维持数据一致性，我们经过调研，最终锁定了 Seata (AT模式) 作为分布式事务解决方案。 目前的业务场景是：用户下单（OrderService）-> 扣减积分（PointsService）。看似简单的链路，上线后却收到了客诉：订单创建成功了，但积分没扣。 首先我们来分析一下接入Seata后的理想通讯...

背景随着公司业务体量的增长，我们将核心交易系统从单体架构拆分为微服务架构。在拆分过程中，跨服务的数据库事务一致性成为了必须跨越的鸿沟。 经过对 XA、TCC、Saga 等主流方案的调研，鉴于团队目前的开发人力资源以及对旧系统的兼容需求，我们锁定了号称“零代码侵入”的 Seata AT 模式。 官方文档看起来非常美好：只需要一个注解 @GlobalTransactional，就能像使用本地事务...

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的自动配置机制有了更深的了解。