解决gateway使用nacos重启报503 Service Unavailable问题

最新推荐文章于 2025-05-15 12:45:08 发布

jmysql

最新推荐文章于 2025-05-15 12:45:08 发布

阅读量1.4w

点赞数 15

CC 4.0 BY-SA版权

分类专栏： java 文章标签： gateway java 开发语言

本文链接：https://blog.csdn.net/jmysql/article/details/124501738

本文详细描述了在使用Spring Cloud Gateway作为网关、Nacos作为注册中心时遇到的服务重启后偶尔出现503 Service Unavailable的问题。问题原因是Ribbon的缓存更新机制，它依赖于定时任务，默认每30秒更新一次。解决方案是通过自定义ServerListUpdater监听Nacos服务变更事件，实现实时更新Ribbon的缓存，避免了不必要的延迟。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

问题描述

项目使用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 ConcurrentHas