05篇 Nacos Client服务订阅之事件机制剖析
学习不用那么功利，二师兄带你从更高维度轻松阅读源码～
上篇文章，我们分析了Nacos客户端订阅的核心流程：Nacos客户端通过一个定时任务，每6秒从注册中心获取实例列表，当发现实例发生变化时，发布变更事件，订阅者进行业务处理，然后更新内存中和本地的缓存中的实例。
这篇文章为服务订阅的第二篇，我们重点来分析，定时任务获取到最新实例列表之后，整个事件机制是如何处理的。
回顾整个流程
先回顾一下客户端服务订阅的基本流程：
在第一步调用subscribe方法时，会订阅一个EventListener事件。而在定时任务UpdateTask定时获取实例列表之后，会调用ServiceInfoHolder#processServiceInfo方法对ServiceInfo进行本地处理，这其中就包括和事件处理。
监听事件的注册
在subscribe方法中，通过如下方式进行了监听事件的注册：
@Override
public void subscribe(String serviceName, String groupName, List<String> clusters, EventListener listener)
throws NacosException {
if (null == listener) {
return;
}
String clusterString = StringUtils.join(clusters, ",");
changeNotifier.registerListener(groupName, serviceName, clusterString, listener);
clientProxy.subscribe(serviceName, groupName, clusterString);
}
这里的changeNotifier.registerListener便是进行具体的事件注册逻辑。追进去看一下实现源码：
// InstancesChangeNotifier
public void registerListener(String groupName, String serviceName, String clusters, EventListener listener) {
String key = ServiceInfo.getKey(NamingUtils.getGroupedName(serviceName, groupName), clusters);
ConcurrentHashSet<EventListener> eventListeners = listenerMap.get(key);
if (eventListeners == null) {
synchronized (lock) {
eventListeners = listenerMap.get(key);
if (eventListeners == null) {
eventListeners = new ConcurrentHashSet<EventListener>();
// 将EventListener缓存到listenerMap
listenerMap.put(key, eventListeners);
}
}
}
eventListeners.add(listener);
}
可以看出，事件的注册便是将EventListener存储在InstancesChangeNotifier的listenerMap属性当中了。
这里的数据结构为Map，key为服务实例信息的拼接，value为监听事件的集合。
事件注册流程就这么简单。这里有一个双重检查锁的实践案例，不知道你留意到没？可以学习一下。
ServiceInfo的处理
上面完成了事件的注册，现在就追溯一下触发事件的来源。UpdateTask中获取到最新实例会进行本地化处理，部分代码如下：
// 获取缓存的service信息
ServiceInfo serviceObj = serviceInfoHolder.getServiceInfoMap().get(serviceKey);
if (serviceObj == null) {
// 根据serviceName从注册中心服务端获取Service信息
serviceObj = namingClientProxy.queryInstancesOfService(serviceName, groupName, clusters, 0, false);
serviceInfoHolder.processServiceInfo(serviceObj);
lastRefTime = serviceObj.getLastRefTime();
return;
}
这部分逻辑在上篇文章中已经分析过了，这里重点看serviceInfoHolder#processServiceInfo中的业务逻辑处理。先看流程图，然后看代码。
上述逻辑简单说就是：判断一下新的ServiceInfo数据是否正确，是否发生了变化。如果数据格式正确，且发生的变化，那就发布一个InstancesChangeEvent事件，同时将ServiceInfo写入本地缓存。
下面看一下代码实现：
public ServiceInfo processServiceInfo(ServiceInfo serviceInfo) {
String serviceKey = serviceInfo.getKey();
if (serviceKey == null) {
return null;
}
ServiceInfo oldService = serviceInfoMap.get(serviceInfo.getKey());
if (isEmptyOrErrorPush(serviceInfo)) {
//empty or error push, just ignore
return oldService;
}
// 缓存服务信息
serviceInfoMap.put(serviceInfo.getKey(), serviceInfo);
// 判断注册的实例信息是否已变更
boolean changed = isChangedServiceInfo(oldService, serviceInfo);
if (StringUtils.isBlank(serviceInfo.getJsonFromServer())) {
serviceInfo.setJsonFromServer(JacksonUtils.toJson(serviceInfo));
}
// 通过prometheus-simpleclient监控服务缓存Map的大小
MetricsMonitor.getServiceInfoMapSizeMonitor().set(serviceInfoMap.size());
// 服务实例已变更
if (changed) {
NAMING_LOGGER.info("current ips:(" + serviceInfo.ipCount() + ") service: " + serviceInfo.getKey() + " -> "
+ JacksonUtils.toJson(serviceInfo.getHosts()));
// 添加实例变更事件，会被推动到订阅者执行
NotifyCenter.publishEvent(new InstancesChangeEvent(serviceInfo.getName(), serviceInfo.getGroupName(),
serviceInfo.getClusters(), serviceInfo.getHosts()));
// 记录Service本地文件
DiskCache.write(serviceInfo, cacheDir);
}
return serviceInfo;
}
可以对照流程图和代码中的注释部分进行理解这个过程。
我们要讲的重点是服务信息变更之后，发布的InstancesChangeEvent，也就是流程图中标红的部分。
事件追踪
上面的事件是通过NotifyCenter进行发布的，NotifyCenter中的核心流程如下：
NotifyCenter中进行事件发布，发布的核心逻辑是：
- 根据InstancesChangeEvent事件类型，获得对应的CanonicalName；
- 将CanonicalName作为Key，从NotifyCenter#publisherMap中获取对应的事件发布者（EventPublisher）；
- EventPublisher将InstancesChangeEvent事件进行发布。
NotifyCenter中的核心代码实现如下：
private static boolean publishEvent(final Class<? extends Event> eventType, final Event event) {
if (ClassUtils.isAssignableFrom(SlowEvent.class, eventType)) {
return INSTANCE.sharePublisher.publish(event);
}
// 根据InstancesChangeEvent事件类型，获得对应的CanonicalName；
final String topic = ClassUtils.getCanonicalName(eventType);
// 将CanonicalName作为Key，从NotifyCenter#publisherMap中获取对应的事件发布者（EventPublisher）；
EventPublisher publisher = INSTANCE.publisherMap.get(topic);
if (publisher != null) {
// EventPublisher将InstancesChangeEvent事件进行发布。
return publisher.publish(event);
}
LOGGER.warn("There are no [{}] publishers for this event, please register", topic);
return false;
}
上述代码中的INSTANCE为NotifyCenter的单例模式实现。那么，这里的publisherMap中key（CanonicalName）和value（EventPublisher）之间的关系是什么时候建立的呢？
这个是在NacosNamingService实例化时调用init方法中进行绑定的：
// Publisher的注册过程在于建立InstancesChangeEvent.class与EventPublisher的关系。 NotifyCenter.registerToPublisher(InstancesChangeEvent.class, 16384);
registerToPublisher方法默认采用了DEFAULT_PUBLISHER_FACTORY来进行构建。
public static EventPublisher registerToPublisher(final Class<? extends Event> eventType, final int queueMaxSize) {
return registerToPublisher(eventType, DEFAULT_PUBLISHER_FACTORY, queueMaxSize);
}
如果查看NotifyCenter中静态代码块，会发现DEFAULT_PUBLISHER_FACTORY默认构建的EventPublisher为DefaultPublisher。
至此，我们得知，在NotifyCenter中它维护了事件名称和事件发布者的关系，而默认的事件发布者为DefaultPublisher。
DefaultPublisher的事件发布
查看DefaultPublisher的源码，会发现它继承自Thread，也就是说它是一个线程类。同时，它又实现了EventPublisher，也就是我们前面提到的发布者。
public class DefaultPublisher extends Thread implements EventPublisher {}
在DefaultPublisher的init方法实现如下：
@Override
public void init(Class<? extends Event> type, int bufferSize) {
// 守护线程
setDaemon(true);
// 设置线程名字
setName("nacos.publisher-" + type.getName());
this.eventType = type;
this.queueMaxSize = bufferSize;
// 阻塞队列初始化
this.queue = new ArrayBlockingQueue<>(bufferSize);
start();
}
也就是说，当DefaultPublisher被初始化时，是以守护线程的方式运作的，其中还初始化了一个阻塞队列，队列的默认大小为16384。
最后调用了start方法：
@Override
public synchronized void start() {
if (!initialized) {
// start just called once
super.start();
if (queueMaxSize == -1) {
queueMaxSize = ringBufferSize;
}
initialized = true;
}
}
start方法中调用了super.start，此时等于启动了线程，会执行对应的run方法。
run方法中只调用了如下方法：
void openEventHandler() {
try {
// This variable is defined to resolve the problem which message overstock in the queue.
int waitTimes = 60;
// for死循环不断的从队列中取出Event，并通知订阅者Subscriber执行Event
// To ensure that messages are not lost, enable EventHandler when
// waiting for the first Subscriber to register
for (; ; ) {
if (shutdown || hasSubscriber() || waitTimes <= 0) {
break;
}
ThreadUtils.sleep(1000L);
waitTimes--;
}
for (; ; ) {
if (shutdown) {
break;
}
// // 从队列取出Event
final Event event = queue.take();
receiveEvent(event);
UPDATER.compareAndSet(this, lastEventSequence, Math.max(lastEventSequence, event.sequence()));
}
} catch (Throwable ex) {
LOGGER.error("Event listener exception : ", ex);
}
}
这里写了两个死循环，第一个死循环可以理解为延时效果，也就是说线程启动时最大延时60秒，在这60秒中每隔1秒判断一下当前线程是否关闭，是否有订阅者，是否超过60秒。如果满足一个条件，就可以提前跳出死循环。
而第二个死循环才是真正的业务逻辑处理，会从阻塞队列中取出一个事件，然后通过receiveEvent方法进行执行。
那么，队列中的事件哪儿来的呢？此时，你可能已经想到刚才DefaultPublisher的发布事件方法被调用了。来看看它的publish方法实现：
@Override
public boolean publish(Event event) {
checkIsStart();
boolean success = this.queue.offer(event);
if (!success) {
LOGGER.warn("Unable to plug in due to interruption, synchronize sending time, event : {}", event);
receiveEvent(event);
return true;
}
return true;
}
可以看到，DefaultPublisher的publish方法的确就是往阻塞队列中存入事件。这里有个分支逻辑，如果存入失败，会直接调用receiveEvent，和从队列中取出事件执行的方法一样。可以理解为，如果向队列中存入失败，则立即执行，不走队列了。
最后，再来看看receiveEvent方法的实现：
void receiveEvent(Event event) {
final long currentEventSequence = event.sequence();
if (!hasSubscriber()) {
LOGGER.warn("[NotifyCenter] the {} is lost, because there is no subscriber.");
return;
}
// 通知订阅者执行Event
// Notification single event listener
for (Subscriber subscriber : subscribers) {
// Whether to ignore expiration events
if (subscriber.ignoreExpireEvent() && lastEventSequence > currentEventSequence) {
LOGGER.debug("[NotifyCenter] the {} is unacceptable to this subscriber, because had expire",
event.getClass());
continue;
}
// Because unifying smartSubscriber and subscriber, so here need to think of compatibility.
// Remove original judge part of codes.
notifySubscriber(subscriber, event);
}
}
这里最主要的逻辑就是遍历DefaultPublisher的subscribers（订阅者集合），然后执行通知订阅者的方法。
那么有朋友要问了这subscribers中的订阅者哪里来的呢？这个还要回到NacosNamingService的init方法中：
// 将Subscribe注册到Publisher NotifyCenter.registerSubscriber(changeNotifier);
该方法最终会调用NotifyCenter的addSubscriber方法：
private static void addSubscriber(final Subscriber consumer, Class<? extends Event> subscribeType,
EventPublisherFactory factory) {
final String topic = ClassUtils.getCanonicalName(subscribeType);
synchronized (NotifyCenter.class) {
// MapUtils.computeIfAbsent is a unsafe method.
MapUtil.computeIfAbsent(INSTANCE.publisherMap, topic, factory, subscribeType, ringBufferSize);
}
// 获取时间对应的Publisher
EventPublisher publisher = INSTANCE.publisherMap.get(topic);
if (publisher instanceof ShardedEventPublisher) {
((ShardedEventPublisher) publisher).addSubscriber(consumer, subscribeType);
} else {
// 添加到subscribers集合
publisher.addSubscriber(consumer);
}
}
其中核心逻辑就是将订阅事件、发布者、订阅者三者进行绑定。而发布者与事件通过Map进行维护、发布者与订阅者通过关联关系进行维护。
发布者找到了，事件也有了，最后看一下notifySubscriber方法：
@Override
public void notifySubscriber(final Subscriber subscriber, final Event event) {
LOGGER.debug("[NotifyCenter] the {} will received by {}", event, subscriber);
// 执行订阅者Event
final Runnable job = () -> subscriber.onEvent(event);
final Executor executor = subscriber.executor();
if (executor != null) {
executor.execute(job);
} else {
try {
job.run();
} catch (Throwable e) {
LOGGER.error("Event callback exception: ", e);
}
}
}
逻辑比较简单，如果订阅者定义了Executor，那么使用它定义的Executor进行事件的执行，如果没有，那就创建一个线程进行执行。
至此，整个服务订阅的事件机制完成。
小结
整体来看，整个服务订阅的事件机制还是比较复杂的，因为用到了事件的形式，逻辑就比较绕，而且这期间还掺杂了守护线程，死循环，阻塞队列等。需要重点理解NotifyCenter对事件发布者、事件订阅者和事件之间关系的维护，而这一关系的维护的入口就位于NacosNamingService的init方法当中。
下面再梳理一下几个核心流程：
ServiceInfoHolder中通过NotifyCenter发布了InstancesChangeEvent事件；
NotifyCenter中进行事件发布，发布的核心逻辑是：
- 根据InstancesChangeEvent事件类型，获得对应的CanonicalName；
- 将CanonicalName作为Key，从NotifyCenter#publisherMap中获取对应的事件发布者（EventPublisher）；
- EventPublisher将InstancesChangeEvent事件进行发布。
InstancesChangeEvent事件发布：
- 通过EventPublisher的实现类DefaultPublisher进行InstancesChangeEvent事件发布；
- DefaultPublisher本身以守护线程的方式运作，在执行业务逻辑前，先判断该线程是否启动；
- 如果启动，则将事件添加到BlockingQueue中，队列默认大小为16384；
- 添加到BlockingQueue成功，则整个发布过程完成；
- 如果添加失败，则直接调用DefaultPublisher#receiveEvent方法，接收事件并通知订阅者；
- 通知订阅者时创建一个Runnable对象，执行订阅者的Event。
- Event事件便是执行订阅时传入的事件；
如果添加到BlockingQueue成功，则走另外一个业务逻辑：
- DefaultPublisher初始化时会创建一个阻塞（BlockingQueue）队列，并标记线程启动；
- DefaultPublisher本身是一个Thread，当执行super.start方法时，会调用它的run方法；
- run方法的核心业务逻辑是通过openEventHandler方法处理的；
- openEventHandler方法通过两个for循环，从阻塞队列中获取时间信息；
- 第一个for循环用于让线程启动时在60s内检查执行条件；
- 第二个for循环为死循环，从阻塞队列中获取Event，并调用DefaultPublisher#receiveEvent方法，接收事件并通知订阅者；
- Event事件便是执行订阅时传入的事件；
关于Nacos Client服务定义的事件机制就将这么多，下篇我们来讲讲故障转移和缓存的实现。
博主简介：《SpringBoot技术内幕》技术图书作者，酷爱钻研技术，写技术干货文章。
公众号：「程序新视界」，博主的公众号，欢迎关注~
技术交流：请联系博主微信号：zhuan2quan
关注公众号：程序新视界，一个让你软实力、硬技术同步提升的平台
除非注明，否则均为程序新视界原创文章，转载必须以链接形式标明本文链接
