应用系统定制开发解决gateway使用nacos重启报503 Service Unavailable问题

问题描述

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

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

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

gateway感知其它服务上下线

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

某服务下线gateway输出

某服务上线gateway输出

这说明提供了这种监听功能，在注册中心服务列表发生时可以第一时间通知客户端，而在我们的依赖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配置文件路由方面设置如下

  1. routes:
  2.         - id: auth
  3.           uri: lb://demo-auth
  4.           predicates:
  5.             - Path=/auth/**
  6.           filters:
  7.             - 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和端口信息)，然后根据负载均衡策略调用其中一个服务，选择服务的代码如下

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

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

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

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

ribbon的刷新缓存机制

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

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

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

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

  1. public class DynamicServerListLoadBalancer<T extends Server> extends BaseLoadBalancer {
  2.     // 封装成一个回调
  3.     protected final ServerListUpdater.UpdateAction updateAction = new ServerListUpdater.UpdateAction() {
  4.         @Override
  5.         public void doUpdate() {
  6.             updateListOfServers();
  7.         }
  8.     };
  9.     // 初始化
  10.     public DynamicServerListLoadBalancer(IClientConfig clientConfig, IRule rule, IPing ping,
  11.                                          ServerList<T> serverList, ServerListFilter<T> filter,
  12.                                          ServerListUpdater serverListUpdater) {
  13.         ...
  14.         this.serverListUpdater = serverListUpdater; // serverListUpdate赋值
  15.         ...
  16.         // 初始化时刷新服务
  17.         restOfInit(clientConfig);
  18.     }
  19.     
  20.     void restOfInit(IClientConfig clientConfig) {
  21.         ...
  22.         // 开启动态刷新缓存
  23.         enableAndInitLearnNewServersFeature();
  24.         // 首先刷新一遍缓存
  25.         updateListOfServers();
  26.         ...
  27.     }
  28.     
  29.     // 开启动态刷新缓存
  30.     public void enableAndInitLearnNewServersFeature() {
  31.         // 把更新的方法传递给serverListUpdater
  32.         serverListUpdater.start(updateAction);
  33.     }

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

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

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

  1. public class PollingServerListUpdater implements ServerListUpdater {
  2.     @Override
  3.     public synchronized void start(final UpdateAction updateAction) {
  4.         if (isActive.compareAndSet(false, true)) {
  5.             // 定义一个runable，运行doUpdate放
  6.             final Runnable wrapperRunnable = new Runnable() {
  7.                 @Override
  8.                 public void run() {
  9.                     ....
  10.                     try {
  11.                         updateAction.doUpdate(); // 执行更新服务列表方法
  12.                         lastUpdated = System.currentTimeMillis();
  13.                     } catch (Exception e) {
  14.                         logger.warn("Failed one update cycle", e);
  15.                     }
  16.                 }
  17.             };
  18.  
  19.             // 定时执行
  20.             scheduledFuture = getRefreshExecutor().scheduleWithFixedDelay(
  21.                     wrapperRunnable,
  22.                     initialDelayMs,
  23.                     refreshIntervalMs, // 默认30 * 1000
  24.                     TimeUnit.MILLISECONDS
  25.             );
  26.         } else {
  27.             logger.info("Already active, no-op");
  28.         }
  29.     }

至此真相大白了，原来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类

  1. package org.springframework.cloud.netflix.ribbon;
  2. @Configuration(proxyBeanMethods = false)
  3. @EnableConfigurationProperties
  4. @Import({ HttpClientConfiguration.class, OkHttpRibbonConfiguration.class,
  5.         RestClientRibbonConfiguration.class, HttpClientRibbonConfiguration.class })
  6. public class RibbonClientConfiguration {
  7.     ...
  8.     @Bean
  9.     @ConditionalOnMissingBean
  10.     public ServerListUpdater ribbonServerListUpdater(IClientConfig config) {
  11.         return new PollingServerListUpdater(config);
  12.     }
  13.     ...
  14. }

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

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

最终解决方案

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

1.抽象监听器

  1. /**
  2.  * @Author pq
  3.  * @Date 2022/4/26 17:19
  4.  * @Description 抽象监听器
  5.  */
  6. public interface ServerListListener {
  7.     /**
  8.      * 监听
  9.      * @param serviceId 服务名
  10.      * @param eventHandler 回调
  11.      */
  12.     void listen(String serviceId, ServerEventHandler eventHandler);
  13.  
  14.     @FunctionalInterface
  15.     interface ServerEventHandler {
  16.         void update();
  17.     }
  18. }

自定义ServerListUpdater

  1. public class NotificationServerListUpdater implements ServerListUpdater {
  2.  
  3.     private static final Logger logger = LoggerFactory.getLogger(NotificationServerListUpdater.class);
  4.  
  5.     private final ServerListListener listener;
  6.  
  7.     public NotificationServerListUpdater(ServerListListener listener) {
  8.         this.listener = listener;
  9.     }
  10.  
  11.     /**
  12.      * 开始运行
  13.      * @param updateAction
  14.      */
  15.     @Override
  16.     public void start(UpdateAction updateAction) {
  17.         // 创建监听
  18.         String clientName = getClientName(updateAction);
  19.         listener.listen(clientName, ()-> {
  20.             logger.info("{} 服务变化, 主动刷新服务列表缓存", clientName);
  21.             // 回调直接更新
  22.             updateAction.doUpdate();
  23.         });
  24.     }
  25.  
  26.     /**
  27.      * 通过updateAction获取服务名，这种方法比较粗暴
  28.      * @param updateAction
  29.      * @return
  30.      */
  31.     private String getClientName(UpdateAction updateAction) {
  32.         try {
  33.             Class<?> bc = updateAction.getClass();
  34.             Field field = bc.getDeclaredField("this$0");
  35.             field.setAccessible(true);
  36.             BaseLoadBalancer baseLoadBalancer = (BaseLoadBalancer) field.get(updateAction);
  37.             return baseLoadBalancer.getClientConfig().getClientName();
  38.         } catch (Exception e) {
  39.             e.printStackTrace();
  40.             throw new IllegalStateException(e);
  41.         }
  42.     }

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

  1. @Slf4j
  2. @Component
  3. public class NacosServerListListener implements ServerListListener {
  4.  
  5.     @Autowired
  6.     private NacosServiceManager nacosServiceManager;
  7.  
  8.     private NamingService namingService;
  9.  
  10.     @Autowired
  11.     private NacosDiscoveryProperties properties;
  12.  
  13.     @PostConstruct
  14.     public void init() {
  15.         namingService =  nacosServiceManager.getNamingService(properties.getNacosProperties());
  16.     }
  17.  
  18.     /**
  19.      * 创建监听器
  20.      */
  21.     @Override
  22.     public void listen(String serviceId, ServerEventHandler eventHandler) {
  23.         try {
  24.             namingService.subscribe(serviceId, event -> {
  25.                 if (event instanceof NamingEvent) {
  26.                     NamingEvent namingEvent = (NamingEvent) event;
  27. //                    log.info("服务名：" + namingEvent.getServiceName());
  28. //                    log.info("实例：" + namingEvent.getInstances());
  29.                     // 实际更新
  30.                     eventHandler.update();
  31.                 }
  32.             });
  33.         } catch (NacosException e) {
  34.             e.printStackTrace();
  35.         }
  36.     }
  37. }

把自定义Updater注入bean

  1. @Configuration
  2. @ConditionalOnRibbonNacos
  3. public class RibbonConfig {
  4.     @Bean
  5.     public ServerListUpdater ribbonServerListUpdater(NacosServerListListener listener) {
  6.         return new NotificationServerListUpdater(listener);
  7.     }
  8. }

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

总结

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

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

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

网站建设定制开发 软件系统开发定制 定制软件开发 软件开发定制 定制app开发 app开发定制 app开发定制公司 电商商城定制开发 定制小程序开发 定制开发小程序 客户管理系统开发定制 定制网站 定制开发 crm开发定制 开发公司 小程序开发定制 定制软件 收款定制开发 企业网站定制开发 定制化开发 android系统定制开发 定制小程序开发费用 定制设计 专注app软件定制开发 软件开发定制定制 知名网站建设定制 软件定制开发供应商 应用系统定制开发 软件系统定制开发 企业管理系统定制开发 系统定制开发