问题描述

项目使用spring cloud gateway作为网关，nacos作为微服务注册中心，项目搭建好后正常访问都没问题，但是有个很烦人的小瑕疵：

• 当某个微服务重启后，通过网关调用这个服务时有时会出现503 Service Unavailable(服务不可用)的错误，但过了一会儿又可以访问了，这个等待时间有时很长有时很短，甚至有时候还不会出现
• 导致每次重启某个项目都要顺便启动gateway项目才能保证立即可以访问，时间长了感觉好累，想彻底研究下为什么，并彻底解决

接下来介绍我在解决整个过程的思路，如果没兴趣，可以直接跳到最后的最终解决方案

gateway感知其它服务上下线

首先在某个微服务上下线时，gateway的控制台可以立即看到有对应的输出

某服务下线gateway输出

某服务上线gateway输出

这说明nacos提供了这种监听功能，在注册中心服务列表发生时可以第一时间通知客户端，而在我们的依赖spring-cloud-starter-alibaba-nacos-discovery中显然已经帮我们实现了这个监听

所以也就说明gateway是可以立即感知其它服务的上下线事件，但问题是明明感知到某个服务的上线，那为什么会出现503 Service Unavailable的错误，而且上面的输出有时出现了很久，但调用依然是503 Service Unavailable，对应的某服务明明下线，这是应该是503 Service Unavailable状态，可有时确会有一定时间的500错误

ribbon

为了调查事情的真相，我打开了gateway的debug日志模式，找到了503的罪魁祸首

503的控制台输出

在503错误输出前，有一行这样的日志Zone aware logic disabled or there is only one zone，而报这个信息的包就是ribbon-loadbalancer，也就是gateway默认所使用的负载均衡器

我的gateway配置文件路由方面设置如下

routes:
        - id: auth
          uri: lb://demo-auth
          predicates:
            - Path=/auth/**
          filters:
            - StripPrefix=1

其中在uri这一行，使用了lb:// ,代表使用了gateway的ribbon负载均衡功能，官方文档说明如下
Note that this example also demonstrates (optional) Spring Cloud Netflix Ribbon load-balancing (defined the lb prefix on the destination URI)

ribbon再调用时首先会获取所有服务列表(ip和端口信息)，然后根据负载均衡策略调用其中一个服务，选择服务的代码如下

package com.netflix.loadbalancer;
public class ZoneAwareLoadBalancer<T extends Server> extends DynamicServerListLoadBalancer<T> {
    // 选择服务的方法
    public Server chooseServer(Object key) {
            if (!ENABLED.get() || getLoadBalancerStats().getAvailableZones().size() <= 1) {
                logger.debug("Zone aware logic disabled or there is only one zone");
                return super.chooseServer(key);
            }
    ...     

这就是上面的Zone aware logic..这行日志的出处，经调试发现在getLoadBalancerStats().getAvailableZones()这一步返回的服务是空列表，说明这里没有存储任何服务信息，所以才导致最终的503 Service Unavailable
继续跟进去看getAvailableZones的代码，如下

public class LoadBalancerStats implements IClientConfigAware {
    // 一个缓存所有服务的map
    volatile Map<String, List<? extends Server>> upServerListZoneMap = new ConcurrentHashMap<String, List<? extends Server>>();
    // 获取可用服务keys
    public Set<String> getAvailableZones() {
        return upServerListZoneMap.keySet();
    }

可以看到ribbon是在LoadBalancerStats中维护了一个map来缓存所有可用服务，而问题的原因也大概明了了：gateway获取到了服务变更事件，但并没有及时更新ribbon的服务列表缓存

ribbon的刷新缓存机制

现在的实际情况是：gateway获取到了服务变更事件，但并没有马上更新ribbon的服务列表缓存，但过一段时间可以访问说明缓存又刷新了，那么接下来就要找到ribbon的缓存怎么刷新的，进而进一步分析为什么没有及时刷新

在LoadBalancerStats查找到更新缓存的方法是updateZoneServerMapping

public class LoadBalancerStats implements IClientConfigAware {
    // 一个缓存所有服务的map
    volatile Map<String, List<? extends Server>> upServerListZoneMap = new ConcurrentHashMap<String, List<? extends Server>>();
    // 更新缓存
    public void updateZoneServerMapping(Map<String, List<Server>> map) {
        upServerListZoneMap = new ConcurrentHashMap<String, List<? extends Server>>(map);
        // make sure ZoneStats object exist for available zones for monitoring purpose
        for (String zone: map.keySet()) {
            getZoneStats(zone);
        }
    }

那么接下来看看这个方法的调用链，调用链有点长，最终找到了DynamicServerListLoadBalancer下的updateListOfServers方法，首先看DynamicServerListLoadBalancer翻译过来"动态服务列表负载均衡器"，说明它有动态获取服务列表的功能，那我们的bug它肯定难辞其咎，而updateListOfServers就是它刷新缓存的手段，那么就看看这个所谓的"动态服务列表负载均衡器"是如何使用updateListOfServers动态刷新缓存的

public class DynamicServerListLoadBalancer<T extends Server> extends BaseLoadBalancer {
    // 封装成一个回调
    protected final ServerListUpdater.UpdateAction updateAction = new ServerListUpdater.UpdateAction() {
        @Override
        public void doUpdate() {
            updateListOfServers();
        }
    };
    // 初始化
    public DynamicServerListLoadBalancer(IClientConfig clientConfig, IRule rule, IPing ping,
                                         ServerList<T> serverList, ServerListFilter<T> filter,
                                         ServerListUpdater serverListUpdater) {
        ...
        this.serverListUpdater = serverListUpdater; // serverListUpdate赋值
        ...
        // 初始化时刷新服务
        restOfInit(clientConfig);
    }
    
    void restOfInit(IClientConfig clientConfig) {
        ...
        // 开启动态刷新缓存
        enableAndInitLearnNewServersFeature();
        // 首先刷新一遍缓存
        updateListOfServers();
        ...
    }
    
    // 开启动态刷新缓存
    public void enableAndInitLearnNewServersFeature() {
        // 把更新的方法传递给serverListUpdater
        serverListUpdater.start(updateAction);
    }

可以看到初始化DynamicServerListLoadBalancer时，首先updateListOfServers获取了一次服务列表并缓存，这只能保证项目启动获取一次服务列表，而真正的动态更新实现是把updateListOfServers方法传递给内部serverListUpdater.start方法，serverListUpdater翻译过来就是“服务列表更新器”，所以再理一下思路：

DynamicServerListLoadBalancer只所以敢自称“动态服务列表负载均衡器”，是因为它内部有个serverListUpdater(“服务列表更新器”)，也就是serverListUpdater.start才是真正为ribbon提供动态更新服务列表的方法，也就是罪魁祸首

那么就看看ServerListUpdater到底是怎么实现的动态更新，首先ServerListUpdater是一个接口，它的实现也只有一个PollingServerListUpdater，那么肯定是它了，看一下它的start方法实现

public class PollingServerListUpdater implements ServerListUpdater {
    @Override
    public synchronized void start(final UpdateAction updateAction) {
        if (isActive.compareAndSet(false, true)) {
            // 定义一个runable，运行doUpdate放
            final Runnable wrapperRunnable = new Runnable() {
                @Override
                public void run() {
                    ....
                    try {
                        updateAction.doUpdate(); // 执行更新服务列表方法
                        lastUpdated = System.currentTimeMillis();
                    } catch (Exception e) {
                        logger.warn("Failed one update cycle", e);
                    }
                }
            };

            // 定时执行
            scheduledFuture = getRefreshExecutor().scheduleWithFixedDelay(
                    wrapperRunnable,
                    initialDelayMs,
                    refreshIntervalMs, // 默认30 * 1000
                    TimeUnit.MILLISECONDS
            );
        } else {
            logger.info("Already active, no-op");
        }
    }

至此真相大白了，原来ribbon默认更新服务列表依靠的是定时任务，而且默认30秒一次，也就是说假如某个服务重启了，gateway的nacos客户端也感知到了，但是ribbon内部极端情况需要30秒才会重新获取服务列表，这也就解释了为什么会有那么长时间的503 Service Unavailable问题

而且因为定时任务，所以等待时间是0-30秒不等，有可能你刚重启完就获取了正常调用没问题，也有可能刚重启完时刚获取完一次，结果就得等30秒才能访问到新的节点

解决思路

问题的原因找到了，接下来就是解决了，最简单暴力的方式莫过于修改定时任务的间隔时间，默认30秒，可以改成10秒，5秒，1秒，只要你机器配置够牛逼

但是有没有更优雅的解决方案，我们的gateway明明已经感知到服务的变化，如果通知ribbon直接更新，问题不就完美解决了吗，这种思路定时任务都可以去掉了，性能还优化了

具体解决步骤如下

• 写一个新的更新器，替换掉默认的PollingServerListUpdater更新器
• 更新器可以监听nacos的服务更新
• 收到服务更新事件时，调用doUpdate方法更新ribbon缓存

接下来一步步解决

首先看上面DynamicServerListLoadBalancer的代码，发现更新器是构造方法传入的，所以要找到构造方法的调用并替换成自己信息的更新器

在DynamicServerListLoadBalancer构造方法上打了个断点，看看它是如何被初始化的(并不是gateway启动就会初始化，而是首次调用某个服务，给对应的服务创建一个LoadBalancer，有点懒加载的意思)

构造方法断点

debugger

看一下debugger的函数调用，发现一个doCreateBean>>>createBeanInstance的调用，其中createBeanInstance执行到如下地方

createBeanInstance

熟悉spring源码的朋友应该看得出来DynamicServerListLoadBalancer是spring容器负责创建的，而且是FactoryBean模式。

这个bean的定义在spring-cloud-netflix-ribbon依赖中的RibbonClientConfiguration类

package org.springframework.cloud.netflix.ribbon;
@Configuration(proxyBeanMethods = false)
@EnableConfigurationProperties
@Import({ HttpClientConfiguration.class, OkHttpRibbonConfiguration.class,
        RestClientRibbonConfiguration.class, HttpClientRibbonConfiguration.class })
public class RibbonClientConfiguration {
    ...
    @Bean
    @ConditionalOnMissingBean
    public ServerListUpdater ribbonServerListUpdater(IClientConfig config) {
        return new PollingServerListUpdater(config);
    }
    ...
}

也就是通过我们熟知的@Configuration+@Bean模式创建的PollingServerListUpdater更新器，而且加了个注解@ConditionalOnMissingBean

也就是说我们自己实现一个ServerListUpdater更新器，并加入spring容器，就可以代替PollingServerListUpdater成为ribbon的更新器

最终解决方案

我们的更新器是要订阅nacos的，收到事件做update处理，为了避免ribbon和nacos耦合抽象一个监听器再用nacos实现

1.抽象监听器

/**
 * @Author pq
 * @Date 2022/4/26 17:19
 * @Description 抽象监听器
 */
public interface ServerListListener {
    /**
     * 监听
     * @param serviceId 服务名
     * @param eventHandler 回调
     */
    void listen(String serviceId, ServerEventHandler eventHandler);

    @FunctionalInterface
    interface ServerEventHandler {
        void update();
    }
}

自定义ServerListUpdater

public class NotificationServerListUpdater implements ServerListUpdater {

    private static final Logger logger = LoggerFactory.getLogger(NotificationServerListUpdater.class);

    private final ServerListListener listener;

    public NotificationServerListUpdater(ServerListListener listener) {
        this.listener = listener;
    }

    /**
     * 开始运行
     * @param updateAction
     */
    @Override
    public void start(UpdateAction updateAction) {
        // 创建监听
        String clientName = getClientName(updateAction);
        listener.listen(clientName, ()-> {
            logger.info("{} 服务变化, 主动刷新服务列表缓存", clientName);
            // 回调直接更新
            updateAction.doUpdate();
        });
    }

    /**
     * 通过updateAction获取服务名，这种方法比较粗暴
     * @param updateAction
     * @return
     */
    private String getClientName(UpdateAction updateAction) {
        try {
            Class<?> bc = updateAction.getClass();
            Field field = bc.getDeclaredField("this$0");
            field.setAccessible(true);
            BaseLoadBalancer baseLoadBalancer = (BaseLoadBalancer) field.get(updateAction);
            return baseLoadBalancer.getClientConfig().getClientName();
        } catch (Exception e) {
            e.printStackTrace();
            throw new IllegalStateException(e);
        }
    }

实现ServerListListener监控nacos并注入bean容器

@Slf4j
@Component
public class NacosServerListListener implements ServerListListener {

    @Autowired
    private NacosServiceManager nacosServiceManager;

    private NamingService namingService;

    @Autowired
    private NacosDiscoveryProperties properties;

    @PostConstruct
    public void init() {
        namingService =  nacosServiceManager.getNamingService(properties.getNacosProperties());
    }

    /**
     * 创建监听器
     */
    @Override
    public void listen(String serviceId, ServerEventHandler eventHandler) {
        try {
            namingService.subscribe(serviceId, event -> {
                if (event instanceof NamingEvent) {
                    NamingEvent namingEvent = (NamingEvent) event;
//                    log.info("服务名：" + namingEvent.getServiceName());
//                    log.info("实例：" + namingEvent.getInstances());
                    // 实际更新
                    eventHandler.update();
                }
            });
        } catch (NacosException e) {
            e.printStackTrace();
        }
    }
}

把自定义Updater注入bean

@Configuration
@ConditionalOnRibbonNacos
public class RibbonConfig {
    @Bean
    public ServerListUpdater ribbonServerListUpdater(NacosServerListListener listener) {
        return new NotificationServerListUpdater(listener);
    }
}

到此，大工告成，效果是gateway访问的某微服务停止后，调用马上503，启动后，马上可以调用

总结

本来想解决这个问题首先想到的是nacos或ribbon肯定留了扩展，比如说改了配置就可以平滑感知服务下线，但结果看了文档和源码，并没有发现对应的扩展点，所以只能大动干戈来解决问题，其实很多地方都觉得很粗暴，比如获取clientName，但也实在找不到更好的方案，如果谁知道，麻烦评论告诉我一下

实际上我的项目更新器还保留了定时任务刷新的逻辑，一来刚接触cloud对自己的修改自信不足，二来发现nacos的通知都是udp的通知方式，可能不可靠，不知道是否多余

nacos的监听主要使用namingService的subscribe方法，里面还有坑，还有一层缓存，以后细讲

2022Java毕业设计项目全套，进来白嫖_哔哩哔哩_bilibili