|
目录
导言
问题一
问题二
方案初步提出
解决方案实现
导言
使用Eureka作为服务注册中心时，项目从Eureka下线和关闭的时候，都有短时间的延迟，导致当有新请求进来时会遇到以下问题。
问题一
微服务A从Eureka下线，Zuul无法及时感知到A已下线，请求依然发送到A上，导致从Zuul [从不知道微服务A已下线到知道A已下线] 的 这段时间内 所接收到的部分请求会请求失败。
即Eureka下线延迟或Zuul感知延迟。
问题二
微服务A进行优雅关闭时，从Eureka下线到微服务A所有Bean被销毁
中间又有延迟的时间，导致部分已经进入微服务A的请求会请求失败。
方案初步提出
解决问题一：Zuul开启重试机制
微服务从Eureka下线分为三个阶段
1）微服务未从Eureka下线（下线前）
2）微服务从Eureka下线，Zuul不知道微服务已从Eureka下线（下线中）
3）微服务从Eureka下线，Zuul知道了微服务已从Eureka下线（下线后）
开启Zuul重试机制后，下线前的请求依然会根据注册中心的服务实例来进行路由选择，或A..或B..或C...；下线中的请求，假设A下线中，但由于Zuul不知道，该请求最初也会进入到A当中，但由于A已从Eureka下线，会导致请求失败，此时会调起重试机制，将该请求重试到B..C..其他微服务；下线后的请求，由于Zuul已经知道A已下线，那么请求只会被转发到B..C.....其他微服务里面。
解决问题二：
先主动让微服务A从Eureka下线，等待若干秒后，再利用actuator或kill -15等其他方式关闭微服务。
那么在问题二所描述的请求，会在等待若干秒的这段时间内处理完，而不会由于微服务正在关闭而导致请求失败。
解决方案实现
日后有空再实现吧，以上都是本人无聊写的，也不知道对不对。
Eureka下线延迟 https://blog.csdn.net/qq_20601529/article/details/94653761#comments_13720140
zuul开启重试机制 https://www.jianshu.com/p/f94a590856f5
eureka 的几种主动下线服务的方式 https://www.cnblogs.com/frankltf/p/12673568.html
SpringBoot利用actuator进行优雅关闭_简析 https://blog.csdn.net/qq_42390424/article/details/108777256
| 
转播
