项目使用spring cloud gateway作为网关,nacos作为微服务注册中心,项目搭建好后正常访问都没问题,但是有个很烦人的小瑕疵:
503 Service Unavailable(服务不可用)
的错误,但过了一会儿又可以访问了,这个等待时间有时很长有时很短,甚至有时候还不会出现接下来介绍我在解决整个过程的思路,如果没兴趣,可以直接跳到最后的最终解决方案
首先在某个微服务上下线时,gateway的控制台可以立即看到有对应的输出
某服务下线gateway输出
某服务上线gateway输出
这说明nacos提供了这种监听功能,在注册中心服务列表发生时可以第一时间通知客户端,而在我们的依赖spring-cloud-starter-alibaba-nacos-discovery
中显然已经帮我们实现了这个监听
所以也就说明gateway是可以立即感知其它服务的上下线事件,但问题是明明感知到某个服务的上线,那为什么会出现503 Service Unavailable
的错误,而且上面的输出有时出现了很久,但调用依然是503 Service Unavailable
,对应的某服务明明下线,这是应该是503 Service Unavailable
状态,可有时确会有一定时间的500
错误
为了调查事情的真相,我打开了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 extends DynamicServerListLoadBalancer {
// 选择服务的方法
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> upServerListZoneMap = new ConcurrentHashMap>();
// 获取可用服务keys
public Set getAvailableZones() {
return upServerListZoneMap.keySet();
}
可以看到ribbon是在LoadBalancerStats中维护了一个map来缓存所有可用服务,而问题的原因也大概明了了:gateway获取到了服务变更事件,但并没有及时更新ribbon的服务列表缓存
现在的实际情况是:gateway获取到了服务变更事件,但并没有马上更新ribbon的服务列表缓存,但过一段时间可以访问说明缓存又刷新了,那么接下来就要找到ribbon的缓存怎么刷新的,进而进一步分析为什么没有及时刷新
在LoadBalancerStats查找到更新缓存的方法是updateZoneServerMapping
public class LoadBalancerStats implements IClientConfigAware {
// 一个缓存所有服务的map
volatile Map> upServerListZoneMap = new ConcurrentHashMap>();
// 更新缓存
public void updateZoneServerMapping(Map> map) {
upServerListZoneMap = new ConcurrentHashMap>(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 extends BaseLoadBalancer {
// 封装成一个回调
protected final ServerListUpdater.UpdateAction updateAction = new ServerListUpdater.UpdateAction() {
@Override
public void doUpdate() {
updateListOfServers();
}
};
// 初始化
public DynamicServerListLoadBalancer(IClientConfig clientConfig, IRule rule, IPing ping,
ServerList serverList, ServerListFilter 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直接更新,问题不就完美解决了吗,这种思路定时任务都可以去掉了,性能还优化了
具体解决步骤如下
接下来一步步解决
首先看上面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