spring cloud gateway+nacos 服务下线感知延迟，未及时出现503，请求依然转发到下线服务

spring cloud gateway服务下线感知延迟，未及时出现503

• 1.场景描述
• 2.分析
• • 2.1定位问题
• 3.解决方案

本篇算是配合之前的一篇了。整体问题是gateway对下线服务感知延迟，之前那篇文章是从服务角度解决自身注销的问题（使用undertow，服务停止后nacos下线注销延迟问题）。本篇是解决gateway自身发现服务问题。
这种问题大体就集中情况
1 服务端注销未正常运行（这个看一下nacos是否及时删除了节点信息就可以排查出来）
2 网关服务未及时发现节点的变化（这个可以在debug级别日志验证）
3 服务端和网关服务不互通

1.场景描述

注册中心使用的nacos，客户端版本1.4.1。
gateway版本3.0.1。
nacos服务下线（包含手动点下线和服务正常停机）gateway在短暂几秒内还回继续将流量转发到已下线的服务上导致500。过几秒之后恢复正常，响应码变成503。表面上看，应该是gateway服务没有及时发现服务的下线。

2.分析

日志级别调整到debug，发现通过netty发送的下线通知已经抵达gateway服务。这说明nacos注册中心和spring boot服务通讯和订阅是没问题的。
从转发的入口着手:ReactiveLoadBalancerClientFilter#choose 这个方法就是gateway转发时选择服务的

private Mono<Response<ServiceInstance>> choose(Request<RequestDataContext> lbRequest, String serviceId,
			Set<LoadBalancerLifecycle> supportedLifecycleProcessors) {
		ReactorLoadBalancer<ServiceInstance> loadBalancer = this.clientFactory.getInstance(serviceId,
				ReactorServiceInstanceLoadBalancer.class);
		if (loadBalancer == null) {
			throw new NotFoundException("No loadbalancer available for " + serviceId);
		}
		supportedLifecycleProcessors.forEach(lifecycle -> lifecycle.onStart(lbRequest));
		// 最后是通过ReactorLoadBalancer的实现进行选择
		return loadBalancer.choose(lbRequest);
	}

ReactorLoadBalancer是负载均衡的接口，提供了两个实现，一个随机获取，一个轮询。
默认是使用轮询实现（RoundRobinLoadBalancer）。
RoundRobinLoadBalancer中选择服务的实现逻辑

public Mono<Response<ServiceInstance>> choose(Request request) {
		ServiceInstanceListSupplier supplier = serviceInstanceListSupplierProvider
				.getIfAvailable(NoopServiceInstanceListSupplier::new);
		// 在这个get方法中返回了可选服务器的集合
		return supplier