05篇 Nacos Client服务订阅之事件机制剖析

程序新视界
学习不用那么功利,二师兄带你从更高维度轻松阅读源码~

上篇文章,我们分析了Nacos客户端订阅的核心流程:Nacos客户端通过一个定时任务,每6秒从注册中心获取实例列表,当发现实例发生变化时,发布变更事件,订阅者进行业务处理,然后更新内存中和本地的缓存中的实例。

这篇文章为服务订阅的第二篇,我们重点来分析,定时任务获取到最新实例列表之后,整个事件机制是如何处理的。

回顾整个流程

先回顾一下客户端服务订阅的基本流程:

nacos

在第一步调用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中的业务逻辑处理。先看流程图,然后看代码。

nacos

上述逻辑简单说就是:判断一下新的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中的核心流程如下:

nacos

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

阅读 241

长期从事第三方支付行业,拥有支付账户、支付网关、账 务系统、清结算系统、风控反洗钱系统等经验,后期...

128 声望
25 粉丝
0 条评论
你知道吗?

长期从事第三方支付行业,拥有支付账户、支付网关、账 务系统、清结算系统、风控反洗钱系统等经验,后期...

128 声望
25 粉丝
宣传栏