背景近期在重构公司的核心交易链路查询服务。与普通的资讯类业务不同，该服务涉及到用户资产维度的查询，对数据的一致性极其敏感。 目前的系统面临着经典的“读多写少”场景，但核心约束在于： 数据零容忍：用户充值或交易后，必须立刻看到余额变化，不允许出现“充值成功但余额未变”的客诉。 高并发洪峰：在活动期间，QPS 会瞬间飙升，数据库无法独立承担所有流量，必须依赖 Redis。 解耦诉求：业务代码已...

1. 始于业务场景：当“流量”变成“洪峰”两周前的季度大促，我们的核心交易链路遭遇了一次“惊魂时刻”。 在零点秒杀开启的瞬间，流量激增至日常峰值的 15 倍。虽然我们预备了自动扩容策略，但数据库连接池在扩容完成前就被打满，紧接着是应用层的线程池耗尽。最终，API 响应时间从平均 50ms 飙升至 3s 以上，前端大量报错，核心服务陷入“雪崩”。 事后复盘，我们意识到单纯依赖“弹性扩容”处理脉...

背景近期负责重构公司的核心积分商城系统。与传统电商不同，该商城的业务背景是债权置换资产。用户使用积分（债权）兑换实物，这不仅是一次交易，更是一次金融刚性兑付。 目前系统面临的核心约束有三点： 信任极度脆弱：用户为存量债权人，对“下单失败”或“回滚”极度敏感。 刚性资产：库存即抵债资产，无法补货，绝不允许超卖。 高并发读写：存在高价值硬通货（如黄金、3C）的抢购场景，且用户会高频刷新确认库存...

背景随着业务体量的增长，我们近期完成了交易核心链路的微服务拆分。为了在保证性能的同时维持数据一致性，我们经过调研，最终锁定了 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到底是如何被创建出来的给摸清楚。