问题描述
项目使用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>> upSe