Spring Cloud 请求重试机制核心代码分析

发布微服务的操作一般都是打完新代码的包，kill掉在跑的应用，替换新的包，启动。spring cloud 中使用eureka为注册中心，它是允许服务列表数据的延迟性的，就是说即使应用已经不在服务列表了，客户端在一段时间内依然会请求这个地址。那么就会出现请求正在发布的地址，而导致失败。我们会优化服务列表的刷新时间，以提高服务列表信息的时效性。但是无论怎样，都无法避免有那么一段时间是数据不一致的。调试代码发现registerThrowable;选出来的机子没问题，就是新的健康的机子，但是在执行retryCallback.doWithRetry代码的时候依然请求的是那台挂掉的机子。开源项目即使是优秀的项目必然也会有bug存在，不迷信，不盲目。