Vert.x源码解析 - Core

希望通过本文的解析，让读者了解Vertx的关键部分的实现原理。对诸如如下问题有一个具象的认识。

• Vertx实例的作用？一个应用是否只对应一个Vertx实例？
• Verticle是一个怎样的存在？
• 本地模式下消息是如何在EventBus上传输和响应的？
• EventBus和EventLoop是如何关联起来的？

概述

Vert.x是一个事件驱动，基于Netty库构建的高性能应用程序框架。实现了所谓的Multi-Reactor模型，能够充分利用多核CPU实现以事件循环为基础的基本编程模型。同时在此基础上构建了Verticle这样类似Actor的概念，以应对并发编程的需求。

Vert.x的核心为EventBus和EventLoop，前者用户消息传输，作为联通各个Handler的神经系统；后者作为任务执行的调度者，保证高性能。任何使用Vert.x构建的应用，都必须围绕这二者作文章。否则就失去了使用它的意义。

核心类

Vertx

Vertx是最为核心的类，创建任何Vertx组件几乎都需要Vertx类的实例。

创建一个单机实例的方法是Vertx.vertx()，然后就可以使用了。以此为入口，我们看看Vertx在创建时都做了什么。

看继承关系

Vertx是一个接口，VertxImpl是最终实现类，也是唯一的实现类。其中包含了单机和集群两种模式的实现。

// 单机实现，创建返回VertxImpl即可
static VertxImpl vertx(VertxOptions options, Transport transport) {
    
    
    VertxImpl vertx = new VertxImpl(options, transport);
    vertx.init();
    return vertx;
}
// 集群实现，创建并加入集群
static void clusteredVertx(VertxOptions options, Transport transport, Handler<AsyncResult<Vertx>> resultHandler) {
    
    
    VertxImpl vertx = new VertxImpl(options, transport);
    vertx.joinCluster(options, resultHandler);
}

看Vertx接口的功能

从Vertx接口，看Vertx能干啥。图太长，不方便放，这里只列举核心部分，也是我们用得最多的。

• 创建单机/集群版的Vertx实例
• 创建或获取上下文Context
• 指定特定的Handler运行在当前上下文中
• 获取EventBus
• 获取共享数据
• 设定定时任务
• 发布Verticle
• 执行阻塞方法

如上，Vertx类几乎撑起了所有部分。接着我们看它是如何做到的。

看VertxImpl构造方法

VertxImpl在构造时创建了很多私有对象，具体如下。

private VertxImpl(VertxOptions options, Transport transport) {
    
    
    // 创建closeHooks，CloseHooks维护了一个Closeable的Set，可向其中添加、移除任务，还有执行所有钩子的run方法啦。
    closeHooks = new CloseHooks(log);
    // 创建线程阻塞检查器，它启动一个名为vertx-blocked-thread-checker的定时器，
    checker = new BlockedThreadChecker(options.getBlockedThreadCheckInterval(), options.getBlockedThreadCheckIntervalUnit(), options.getWarningExceptionTime(), options.getWarningExceptionTimeUnit());
    // 指定一个EventLoop最长可以连续执行多久
    maxEventLoopExTime = options.getMaxEventLoopExecuteTime();
    maxEventLoopExecTimeUnit = options.getMaxEventLoopExecuteTimeUnit();
    // 创建EventLoop线程工厂，主要用于指定线程名称和线程阻塞检测器
    eventLoopThreadFactory = new VertxThreadFactory("vert.x-eventloop-thread-", checker, false, maxEventLoopExTime, maxEventLoopExecTimeUnit);
    // 创建EventLoopGroup，它又实际创建了NioEventLoopGroup，它是Netty的组件。一个EventLoopGroup，就是一个EventLoop组。在Netty中，一个EventLoop是线程和IO的结合，一个EventLoop始终绑定在同一个线程上。
    eventLoopGroup = transport.eventLoopGroup(Transport.IO_EVENT_LOOP_GROUP, options.getEventLoopPoolSize(), eventLoopThreadFactory, NETTY_IO_RATIO);
    // 创建一个acceptor EventLoopGroup，创建方式和上面类似。
    ThreadFactory acceptorEventLoopThreadFactory = new VertxThreadFactory("vert.x-acceptor-thread-", checker, false, options.getMaxEventLoopExecuteTime(), options.getMaxEventLoopExecuteTimeUnit());
    acceptorEventLoopGroup = transport.eventLoopGroup(Transport.ACCEPTOR_EVENT_LOOP_GROUP, 1, acceptorEventLoopThreadFactory, 100);
    // 创建worker线程池
    ExecutorService workerExec = new ThreadPoolExecutor(workerPoolSize, workerPoolSize,
                                                        0L, TimeUnit.MILLISECONDS, new LinkedTransferQueue<>(),
                                                        new VertxThreadFactory("vert.x-worker-thread-", checker, true, options.getMaxWorkerExecuteTime(), options.getMaxWorkerExecuteTimeUnit()));
    PoolMetrics workerPoolMetrics = metrics != null ? metrics.createPoolMetrics("worker", "vert.x-worker-thread", 	options.getWorkerPoolSize()) : null;
    workerPool = new WorkerPool(workerExec, workerPoolMetrics);
    // 创建inertnal阻塞线程池
    ExecutorService internalBlockingExec = Executors.newFixedThreadPool(options.getInternalBlockingPoolSize(),
                                                                        new VertxThreadFactory("vert.x-internal-blocking-", checker, true, options.getMaxWorkerExecuteTime(), options.getMaxWorkerExecuteTimeUnit()));
    internalBlockingPool = new WorkerPool(internalBlockingExec, internalBlockingPoolMetrics);
    // 创建文件解析器，在FileSystem中有使用，进行文件操作时使用的是java nio
    this.fileResolver = new FileResolver(options.getFileSystemOptions());
    // 创建地址解析器，在DNS解析时会用到
    this.addressResolver = new AddressResolver(this, options.getAddressResolverOptions());
    // 创建发布管理器，用于发布Verticle
    this.deploymentManager = new DeploymentManager(this);
    if (options.getEventBusOptions().isClustered()) {
    
    
        // 创建集群管理器和集群的EventBus
        this.clusterManager = getClusterManager(options);
        this.eventBus = new ClusteredEventBus(this, options, clusterManager);
    } else {
    
    
        // 创建本地EventBus
        this.clusterManager = null;
        this.eventBus = new EventBusImpl(this);
    }
    // 创建sharedData，允许你在整个应用中共享你的数据，包括集群范围内
    this.sharedData = new SharedDataImpl(this, clusterManager);
}

上面太复杂，整理成思维导图会好看很多。

EventBus用于进行消息传输；

EventLoopGroup为事件循环组，是Netty库中的类，每当有新的任务都会被提交到该组中执行；

而另一个EventLoopGroup——acceptorEventLoopGroup专用于网络服务的创建，目的是避免上面的eventLoopGroup的阻塞造成服务响应不及时；

WorkerPool为单独开的线程池，负责执行阻塞操作；

FileSystem用于操作文件；

AddressResolver用于进行DNS地址解析；

SharedData用于在整个Vertx应用内部共享数据，包括集群模式；

ClusterManager用于进行集群管理；

DeploymentManager和VerticleManager用于发布Verticle，保证Verticle的特性。

所有上述类你可能都不是很熟悉，没关系，先有个印象，下面分析具体场景时会用到。

EventBus

EventBus的继承关系也很简单，其单机版实现类为EventBusImpl，ClusteredEventBus继承自它，除了服务监听和远程调用，均使用了EventBusImpl中的方法。

EventBus的能力，以及EventBusImpl持有对象如下：

出入拦截器自不必说，每次消息进来和出去都会先被拦截器处理；

vertx对象，主要用于获取发送调用代码所处的上线文环境；

handerMap是核心，以地址为key，地址上注册的Handler序列为value，存储了地址-处理器的映射管理；当触发发送动作时，就会到该映射中查找对应的处理器然后执行；对于单机应用，handlerMap就是所有；对于集群应用，则是先找到节点，再在节点中的handlerMap查找对应处理器。

sendNoContext是为了在执行发送的代码块不处于任何上下文时使用的上下文。EventBusImpl创建时使用。

EventBusImpl的构造方法没什么内容，就不提了。

public EventBusImpl(VertxInternal vertx) {
    
    
    VertxMetrics metrics = vertx.metricsSPI();
    this.vertx = vertx;
    this.metrics = metrics != null ? metrics.createEventBusMetrics() : null;
    this.sendNoContext = vertx.getOrCreateContext();
}

EventLoop

Vertx中并没有EventLoop这个类，它是Netty中的类。对Vertx的源码，与EventLoop相关的交互只有两处：创建EventLoopGroup；向EventLoopGroup提交任务。

具体内容请查找Netty相关资料进行学习。

Context

Context是真正提交任务的地方，凡Vertx中涉及到任务的执行，总是少不了Context的身影。

其核心能力主要在协调代码的运行，同时也可存储数据。其大部分逻辑都在ContextImpl中。其两个子类，仅在自我裁定、任务提交、上下文复制上有所不同。

Verticle

Verticle放在这里有一点另类，因为它并非核心组件。只是Vertx提供的actor模式实现的一个发布单元。它的actor特性由VerticleManager、EventBus、Context等一起保证。就其能力来说，也只有启动和停止两个方法。

从EventBus看Vertx工作原理

一个简单的Vertx应用如下，我们从它开始分析。

fun main() {
    
    
  val vertx = Vertx.vertx();
  vertx.eventBus().consumer<String>("helloAddress").handler{
    
    
    print(it.body())
  }
  vertx.eventBus().send("helloAddress", "hello world!")
}

Vertx.vertx()在上面已经看过了，它创建了一个VertxImpl对象，持有一堆用于组织工作的属性，包括EventBus。

// vertx实例时对eventBus赋值的快照
this.eventBus = new EventBusImpl(this);

consumer做了什么

@Override
public <T> MessageConsumer<T> consumer(String address, Handler<Message<T>> handler) {
    
    
    Objects.requireNonNull(handler, "handler");
    MessageConsumer<T> consumer = consumer(address);
    consumer.handler(handler);
    return consumer;
}
// 往里进一步
@Override
public <T> MessageConsumer<T> consumer(String address) {
    
    
    checkStarted();
    Objects.requireNonNull(address, "address");
    return new HandlerRegistration<>(vertx, metrics, this, address, null, false, null, -1);
}
// 重点在HandlerRegistration，收集地址后，开启超时回复定时器。
public HandlerRegistration(Vertx vertx, EventBusMetrics metrics, EventBusImpl eventBus, String address,
                               String repliedAddress, boolean localOnly,
                               Handler<AsyncResult<Message<T>>> asyncResultHandler, long timeout) {
    
    
    this.vertx = vertx;
    this.metrics = metrics;
    this.eventBus = eventBus;
    this.address = address;
    this.repliedAddress = repliedAddress;
    this.localOnly = localOnly;
    this.asyncResultHandler = asyncResultHandler;
    if (timeout != -1) {
    
    
        timeoutID = vertx.setTimer(timeout, tid -> {
    
    
            if (metrics != null) {
    
    
                metrics.replyFailure(address, ReplyFailure.TIMEOUT);
            }
            sendAsyncResultFailure(new ReplyException(ReplyFailure.TIMEOUT, "Timed out after waiting " + timeout + "(ms) for a reply. address: " + address + ", repliedAddress: " + repliedAddress));
        });
    }
}
// 最上面的consumer.handler(handler);调用了HandlerRegistration的handler方法，如下。可以看到最终是在eventBus上调用了注册方法。
@Override
public synchronized MessageConsumer<T> handler(Handler<Message<T>> h) {
    
    
    if (h != null) {
    
    
        synchronized (this) {
    
    
            handler = h;
            if (registered == null) {
    
    
                registered = eventBus.addRegistration(address, this, repliedAddress != null, localOnly);
            }
        }
        return this;
    }
    this.unregister();
    return this;
}
// 最终来到了EventBus的addRegistration方法。在addLocalRegistration中，创建了HandlerHolder，并将其加入EventBus的成员变量handlerMap，然后返回创建的HandlerHolder
protected <T> HandlerHolder<T> addRegistration(String address, HandlerRegistration<T> registration,
                                               boolean replyHandler, boolean localOnly) {
    
    
    Objects.requireNonNull(registration.getHandler(), "handler");
    LocalRegistrationResult<T> result = addLocalRegistration(address, registration, replyHandler, localOnly);
    addRegistration(result.newAddress, address, replyHandler, localOnly, registration::setResult);
    return result.holder;
}

要点总结

• consumer方法仅仅将给定的handler注册到EventBusImpl持有的handlerMap中，等待被消费。

send做了什么

//通过跟踪，最终会来到sendOrPubInternal，首先创建一个用于回复的HandlerRegistration，然后创建OutboundDeliveryContext，调用其next方法
public <T> void sendOrPubInternal(MessageImpl message, DeliveryOptions options,
                                  Handler<AsyncResult<Message<T>>> replyHandler) {
    
    
    checkStarted();
    HandlerRegistration<T> replyHandlerRegistration = createReplyHandlerRegistration(message, options, replyHandler);
    OutboundDeliveryContext<T> sendContext = new OutboundDeliveryContext<>(message, options, replyHandlerRegistration);
    sendContext.next();
}
// createReplyHandlerRegistration方法创建了__vertx.reply.xxx地址的响应HandlerRegistration
private <T> HandlerRegistration<T> createReplyHandlerRegistration(MessageImpl message,
                                                                  DeliveryOptions options,
                                                                  Handler<AsyncResult<Message<T>>> replyHandler) {
    
    
    if (replyHandler != null) {
    
    
        long timeout = options.getSendTimeout();
        String replyAddress = generateReplyAddress();
        message.setReplyAddress(replyAddress);
        Handler<Message<T>> simpleReplyHandler = convertHandler(replyHandler);
        HandlerRegistration<T> registration =
            new HandlerRegistration<>(vertx, metrics, this, replyAddress, message.address, true, replyHandler, timeout);
        registration.handler(simpleReplyHandler);
        return registration;
    } else {
    
    
        return null;
    }
}
protected String generateReplyAddress() {
    
    
    return "__vertx.reply." + Long.toString(replySequence.incrementAndGet());
}
// OutboundDeliveryContext类接收了消息和响应HandlerRegistration，调用next，如下。其中的iter多半是拦截器，暂时不用管。核心在sendOrPub(this)和sendReply(this, replierMessage)
@Override
public void next() {
    
    
    if (iter.hasNext()) {
    
    
        Handler<DeliveryContext> handler = iter.next();
        try {
    
    
            if (handler != null) {
    
    
                handler.handle(this);
            } else {
    
    
                next();
            }
        } catch (Throwable t) {
    
    
            log.error("Failure in interceptor", t);
        }
    } else {
    
    
        if (replierMessage == null) {
    
    
            sendOrPub(this);
        } else {
    
    
            sendReply(this, replierMessage);
        }
    }
}
// 定义io.vertx.core.eventbus.impl.EventBusImpl#sendOrPub，再定位到io.vertx.core.eventbus.impl.EventBusImpl#deliverMessageLocally,最终来到io.vertx.core.eventbus.impl.EventBusImpl#deliverMessageLocally
// 这里的关键由两个地方：一是点对点的实现——再handlerMap中找到指定地址的handlers，只取第一个进行处理；还有发布订阅的实现——对在一个地址注册的handlers全部处理；第二个关键点是消息发送的方法deliverToHandler(msg, holder)
protected ReplyException deliverMessageLocally(MessageImpl msg) {
    
    
    msg.setBus(this);
    ConcurrentCyclicSequence<HandlerHolder> handlers = handlerMap.get(msg.address());
    if (handlers != null) {
    
    
        if (msg.isSend()) {
    
    
            //Choose one
            HandlerHolder holder = handlers.next();
            if (metrics != null) {
    
    
                metrics.messageReceived(msg.address(), !msg.isSend(), isMessageLocal(msg), holder != null ? 1 : 0);
            }
            if (holder != null) {
    
    
                deliverToHandler(msg, holder);
                Handler<AsyncResult<Void>> handler = msg.writeHandler;
                if (handler != null) {
    
    
                    handler.handle(Future.succeededFuture());
                }
            }
        } else {
    
    
            // Publish
            if (metrics != null) {
    
    
                metrics.messageReceived(msg.address(), !msg.isSend(), isMessageLocal(msg), handlers.size());
            }
            for (HandlerHolder holder: handlers) {
    
    
                deliverToHandler(msg, holder);
            }
            Handler<AsyncResult<Void>> handler = msg.writeHandler;
            if (handler != null) {
    
    
                handler.handle(Future.succeededFuture());
            }
        }
        return null;
    } else {
    
    
        ... ...
    }
}
// 最终的处理函数如下：创建InboundDeliveryContext，在HandlerHolder的context环境下运行其next方法：
private <T> void deliverToHandler(MessageImpl msg, HandlerHolder<T> holder) {
    
    
    // Each handler gets a fresh copy
    MessageImpl copied = msg.copyBeforeReceive();
    DeliveryContext<T> receiveContext = new InboundDeliveryContext<>(copied, holder);

    if (metrics != null) {
    
    
        metrics.scheduleMessage(holder.getHandler().getMetric(), msg.isLocal());
    }

    holder.getContext().runOnContext((v) -> {
    
    
        try {
    
    
            receiveContext.next();
        } finally {
    
    
            if (holder.isReplyHandler()) {
    
    
                holder.getHandler().unregister();
            }
        }
    });
}
// next方法啥也没干，直接将message传入目标handler
@Override
public void next() {
    
    
    if (iter.hasNext()) {
    
    
        // ... 拦截器迭代，忽略
    } else {
    
    
        holder.getHandler().handle(message);
    }
}

要点总结

• send分为两步
  • 查询handler，调用send时马上执行，是同步的。
  • 执行handler，通过handler注册时的context执行，是异步的。
• 消息响应的实现方式是注册一个响应handler到EventBus中，名为__vertx.reply.xxx，其中xxx为单调递增数字。
• 如果同一地址注册了多个handler，则点对点传输模式下只会取第一个handler进行处理；发布模式下才会执行所有。
• 在一个上下文中注册的handler，不管被执行时机如何，最终都会在该上下文中执行。参见：holder.getContext().runOnContext(...，hodler为HandlerHolder对象，在调用consumer注册时保存了注册上下文。

和EventLoop的关系在哪？

通过consumer和send看到了EventBus是如何协调接收和发送的，但并没有看到EventLoop是如何参与的。其实它是有参与的，在holder.getContext().runOnContext(...是进行了参与。

于是我们看看EventLoopContext.runOnContext()，如下。就是向Context保存的EventLoop对象提交一个任务即可。调度的事，交给Netty来做

// 看到只调用了一个executeAsync()
@Override
public void runOnContext(Handler<Void> task) {
    
    
    try {
    
    
        executeAsync(task);
    } catch (RejectedExecutionException ignore) {
    
    
        // Pool is already shut down
    }
}
// 这里就能看到Vertx的底了，它直接将任务提交给了netty的eventLoop
void executeAsync(Handler<Void> task) {
    
    
    nettyEventLoop().execute(() -> executeTask(null, task));
}

Verticle工作机制

Vert.x推荐使用Verticle进行开发，它是一个类Actor的模型，具有如下特点。

• 同一Verticle下的所有操作均在一个EventLoop线程上执行。以此避免了线程安全问题。
• Verticle之间通过EventBus进行消息传递
• Verticle具有父子层级关系

一个典型的代码结构如下（官方starter使用Launcher启动的应用，本质上也是通过这种方式启动的）

class Verticle1 : AbstractVerticle() {
    
    
    override fun start() {
    
    
        println("Verticle 1 started")
    }
}

class Verticle2 : AbstractVerticle() {
    
    
    override fun start() {
    
    
        println("Verticle 2 started")
    }
}

fun main() {
    
    
    val vertx = Vertx.vertx();
    vertx.deployVerticle(Verticle1::class.java.canonicalName)
    vertx.deployVerticle(Verticle2::class.java.canonicalName)
}

我们需要探究的问题是

• deployVerticle时发生了什么？
• start()和stop()方法什么时候被调用？
• 如何保证一个Verticle下的所有操作都在一个EventLoop线程上执行？
• 父子层级关系如何维持？有什么作用？

要搞清楚这些问题，我们先看几个与此相关的类

Deployment

维护一个发布状态，父子状态也是由它维护的。其唯一实现类DeploymentImpl是作为DeploymentManager的私有内部类存在的。这意味着Verticle发布的所有操作都在DeploymentManager内完成。

其中可能需要解释的点是getVerticles()，这意味着一个Deployment可以有多个Verticle吗？一定程度上是，但仅当一个Verticle需要发布多个实例时，才会存在多个Verticle对象。

其中需要重点关注的方法是io.vertx.core.impl.DeploymentManager.DeploymentImpl#doUndeploy和io.vertx.core.impl.DeploymentManager.DeploymentImpl#doUndeployChildren，两个方法递归调用，完成了指定Verticle及其子Verticle的取消。

public synchronized Future<Void> doUndeploy(ContextInternal undeployingContext) {
    
    
    if (status == ST_UNDEPLOYED) {
    
    
        return Future.failedFuture(new IllegalStateException("Already undeployed"));
    }
    // 子发布不为空，则先取消子发布，成功后再取消当前发布。
    if (!children.isEmpty()) {
    
    
        status = ST_UNDEPLOYING;
        return doUndeployChildren(undeployingContext).compose(v -> doUndeploy(undeployingContext));
    } else {
    
    
        // 子发布为空、或取消子发布完成，现在来取消当前发布
        status = ST_UNDEPLOYED;
        List<Future> undeployFutures = new ArrayList<>();
        if (parent != null) {
    
    
            parent.removeChild(this);
        }
        // 为当前发布的每个Verticle实例执行此操作
        for (VerticleHolder verticleHolder: verticles) {
    
    
            ContextImpl context = verticleHolder.context;
            Promise p = Promise.promise();
            undeployFutures.add(p.future());
            // 该context是Verticle发布时就存好的，调用它保证了Verticle的stop和start方法在同一个线程运行。
            context.runOnContext(v -> {
    
    
                Promise<Void> stopPromise = Promise.promise();
                Future<Void> stopFuture = stopPromise.future();
                stopFuture.setHandler(ar -> {
    
    
                    // 从deployments映射中移除
                    deployments.remove(deploymentID);
                    VertxMetrics metrics = vertx.metricsSPI();
                    if (metrics != null) {
    
    
                        metrics.verticleUndeployed(verticleHolder.verticle);
                    }
                    context.runCloseHooks(ar2 -> {
    
    
                        if (ar2.failed()) {
    
    
                            // Log error but we report success anyway
                            log.error("Failed to run close hook", ar2.cause());
                        }
                        if (ar.succeeded()) {
    
    
                            p.complete();
                        } else if (ar.failed()) {
    
    
                            p.fail(ar.cause());
                        }
                    });
                });
                try {
    
    
                    // 执行Verticle的stop方法
                    verticleHolder.verticle.stop(stopPromise);
                } catch (Throwable t) {
    
    
                    if (!stopPromise.tryFail(t)) {
    
    
                        undeployingContext.reportException(t);
                    }
                }
            });
        }
        Promise<Void> resolvingPromise = undeployingContext.promise();
        CompositeFuture.all(undeployFutures).<Void>mapEmpty().setHandler(resolvingPromise);
        return resolvingPromise.future();
    }
}

private synchronized Future<Void> doUndeployChildren(ContextInternal undeployingContext) {
    
    
    if (!children.isEmpty()) {
    
    
        List<Future> childFuts = new ArrayList<>();
        // 对每个子发布执行doUndeploy方法
        for (Deployment childDeployment: new HashSet<>(children)) {
    
    
            Promise<Void> p = Promise.promise();
            childFuts.add(p.future());
            childDeployment.doUndeploy(undeployingContext, ar -> {
    
    
                children.remove(childDeployment);
                p.handle(ar);
            });
        }
        return CompositeFuture.all(childFuts).mapEmpty();
    } else {
    
    
        return Future.succeededFuture();
    }
}

总结如下

• 一个Verticle被取消，则其所有子Verticle都会被取消
• VerticleHolder中存储了Verticle对应的Context，因此能够保证Verticle的所有生命周期方法都在同一个Context中执行。

DeploymentManager

DeploymentManager专门用于Verticle发布。

重点方法在如下几个

• DeploymentManager#doDeploy(DeploymentOptions, Function<Verticle,String>, ContextInternal, ContextInternal,ClassLoader, Callable<io.vertx.core.Verticle>)
• DeploymentManager#undeployVerticle(String)

发布

发布代码如下

private Future<Deployment> doDeploy(String identifier,
                                    DeploymentOptions options,
                                    ContextInternal parentContext,
                                    ContextInternal callingContext,
                                    ClassLoader tccl, Verticle... verticles) {
    
    
    Promise<Deployment> promise = callingContext.promise();
    String poolName = options.getWorkerPoolName();

    Deployment parent = parentContext.getDeployment();
    // 生成发布ID
    String deploymentID = generateDeploymentID();
    // 创建Deployment对象，上面有说过它是干啥的
    DeploymentImpl deployment = new DeploymentImpl(parent, deploymentID, identifier, options);

    // 发布计数
    AtomicInteger deployCount = new AtomicInteger();
    // 失败标示
    AtomicBoolean failureReported = new AtomicBoolean();
    // 如果一个Verticle发布多个实例，则会有多个verticle对象
    for (Verticle verticle: verticles) {
    
    
        // Verticle可以被要求发布到Worker线程池还是EventLoop线程池，在这里做区分
        WorkerExecutorInternal workerExec = poolName != null ? vertx.createSharedWorkerExecutor(poolName, options.getWorkerPoolSize(), options.getMaxWorkerExecuteTime(), options.getMaxWorkerExecuteTimeUnit()) : null;
        WorkerPool pool = workerExec != null ? workerExec.getPool() : null;
        // 为每个Verticle都创建一个新的Context
        ContextImpl context = (ContextImpl) (options.isWorker() ? vertx.createWorkerContext(deployment, pool, tccl) :
                                             vertx.createEventLoopContext(deployment, pool, tccl));
        if (workerExec != null) {
    
    
            context.addCloseHook(workerExec);
        }
        // 向Deployment加入Verticle对象
        deployment.addVerticle(new VerticleHolder(verticle, context));
        // 在新创建的Context上执行Verticle生命周期
        context.runOnContext(v -> {
    
    
            try {
    
    
                // 执行init方法
                verticle.init(vertx, context);
                Promise<Void> startPromise = context.promise();
                Future<Void> startFuture = startPromise.future();
                // 执行start方法
                verticle.start(startPromise);
                startFuture.setHandler(ar -> {
    
    
                    if (ar.succeeded()) {
    
    
                        if (parent != null) {
    
    
                            // 发布成功，加入父节点
                            if (parent.addChild(deployment)) {
    
    
                                deployment.child = true;
                            } else {
    
    
                                // Orphan
                                deployment.undeploy(event -> promise.fail("Verticle deployment failed.Could not be added as child of parent verticle"));
                                return;
                            }
                        }
                        // 加入发布完成的map
                        deployments.put(deploymentID, deployment);
                        // 发布的数量和待发布的数量匹配，说明发布完成，成功结束
                        if (deployCount.incrementAndGet() == verticles.length) {
    
    
                            promise.complete(deployment);
                        }
                    } else if (failureReported.compareAndSet(false, true)) {
    
    
                        // 发布失败的回滚
                        deployment.rollback(callingContext, promise, context, ar.cause());
                    }
                });
            } catch (Throwable t) {
    
    
                if (failureReported.compareAndSet(false, true))
                    deployment.rollback(callingContext, promise, context, t);
            }
        });
    }

    return promise.future();
}

总结如下

• 对每个verticle，vertx都会创建一个新的Context，因此每个verticle之间是相互独立的(一个Context代表了一个EventLoop线程。)
• 传入init和start方法的vertx实例，是DeploymentManager中维护的，它是在Vertx.vertx()创建时赋予的，整个应用一个。
• 整个verticle的内容都通过Context.runOnContext注册运行，所以它们才会始终都在一个线程上执行，并且执行顺序从上到下，不存在多线程竞争问题。
• 发布完成的Deployment会被加入DeploymentManager维护的deployments映射中，方便进行查找和之后的使用。

取消发布

public Future<Void> undeployVerticle(String deploymentID) {
    
    
    // 从deployments中获取Deployment对象
    Deployment deployment = deployments.get(deploymentID);
    // 获取当前上下文
    Context currentContext = vertx.getOrCreateContext();
    if (deployment == null) {
    
    
        return ((ContextInternal) currentContext).failedFuture(new IllegalStateException("Unknown deployment"));
    } else {
    
    
        // 调用deployment的undeploy()
        return deployment.undeploy();
    }
}

Deployment.undeploy()在上面介绍Deployment时已介绍。

VerticleManager

DeploymentManager专注于发布，VerticleManager则主要专注于Verticle的创建。其内部持有一个DeploymentManager对象，用于执行实际的发布操作。

该类中有两个主要逻辑

• VerticleFactory的注册、取消、查找等。可以实现自定义的VerticleFactory，这里不深入。
• Verticle的发布和创建的逻辑：调用VerticleFactory创建Verticle实例，在调用DeploymentManager.deploy()发布，代码过长，不给出。

所以Verticle是如何工作的？

这里回答最初提出的四个问题，就能解释Verticle是如何工作的。

• deployVerticle时发生了什么？

  创建Verticle对象 -> 创建Context并和Verticle对象绑定 -> 构建Deployment并存起来 -> 执行init() -> 执行start() -> 完成

• start()和stop()方法什么时候被调用？

  start(): 发布时，在新创建的Context上执行。

  stop(): 取消发布时，在与该Verticle绑定的Context上执行。

• 如何保证一个Verticle下的所有操作都在一个EventLoop线程上执行？

  通过将Context和Verticle绑定，调用start()和stop()时均在该Context下执行；而在start()和stop()中调用vertx的大多数操作，均是在调用代码块的当前Context下执行，而一个Context始终对应同一个EventLoop线程，如此即能保证一个Verticle下的所有操作都在同一个EventLoop线程上执行。

• 父子层级关系如何维持？有什么作用？

  通过Deployment对象记录并维持。作用在于关闭一个Verticle时，其子Verticle也会被依次关闭。

如此一来，Verticle几乎有了除容错机制外的所有的Actor模型的特性。

数据共享机制

Vertx提供了SharedData组件，用于为整个应用范围内提供共享组件，一个共享Map的使用大概如下

class Verticle1 : AbstractVerticle() {
    
    
    override fun start() {
    
    
        println("Verticle 1 started")
        vertx.sharedData().getLocalAsyncMap<String, String>("myMap").setHandler {
    
     ar ->
                                                                                 ar.result().put("你好", "我是Verticle1")
                                                                                }
    }
}

class Verticle2 : AbstractVerticle() {
    
    
    override fun start() {
    
    
        println("Verticle 2 started")
        vertx.sharedData().getLocalAsyncMap<String, String>("myMap").setHandler {
    
     ar ->
                                                                                 val value = ar.result().get("你好").result()
                                                                                 println(value)
                                                                                }
    }
}

fun main() {
    
    
    val vertx = Vertx.vertx();
    vertx.deployVerticle(Verticle1::class.java.canonicalName)
    Thread.sleep(1000)
    vertx.deployVerticle(Verticle2::class.java.canonicalName)
}

所有关于共享数据的内容都在io.vertx.core.shareddata包下，核心类是SharedDataImpl。

提供如下三种数据结构

• io.vertx.core.shareddata.impl.LocalAsyncLocks

  异步排他锁，在集群内部有效的锁。其实现的思路如下

  • 维护一个ConcurrentMap，存储锁名和等待该锁的Handler列表
  • 每次新来一个获取锁的请求，向等待列表中加入。并启动定时器开始计算超时，超时后直接回调锁等待超时。

  至此加入等待列表的逻辑完成。然后是锁流转逻辑。采用被动的逻辑，非常节省复杂度。

  • 当等待列表为空时，来一个请求就将锁给它；列表不为空时，仅加入等待列表，不做尝试获取锁的操作。
  • 当一个锁被释放时，再主动将锁给等待列表的下一个请求。这样几乎从来不会出现竞争的情况。

• io.vertx.core.shareddata.impl.AsynchronousCounter

  计数器，增减都是原子操作

• io.vertx.core.shareddata.impl.LocalMapImpl

  本地Map，用于单个实例中共享数据。仅是对ConcurrentMap的包装，没有其它特别之处。他的所有操作都是同步的。

• io.vertx.core.shareddata.impl.LocalAsyncMapImpl

  异步Map，同样是对ConcurrentMap的包装。不同之处在于其value是Holder类，它封装了TTL，实现原理是调用vertx.setTimer设置一个TTL长度的定时器，过期移除。

  @Override
  public void put(K k, V v, long timeout, Handler<AsyncResult<Void>> completionHandler) {
        
        
      long timestamp = System.nanoTime();
      long timerId = vertx.setTimer(timeout, l -> removeIfExpired(k));
      Holder<V> previous = map.put(k, new Holder<>(v, timerId, timeout, timestamp));
      if (previous != null && previous.expires()) {
        
        
          vertx.cancelTimer(previous.timerId);
      }
      completionHandler.handle(Future.succeededFuture());
  }
  

  可能有顾虑设置太多定时器不好，但vertx其实是将定时任务加入eventLoop线程去执行，因此并不会增加额外成本

  public long setTimer(long delay, Handler<Long> handler) {
        
        
      return scheduleTimeout(getOrCreateContext(), handler, delay, false);
  }
  private long scheduleTimeout(ContextImpl context, Handler<Long> handler, long delay, boolean periodic) {
        
        
      if (delay < 1) {
        
        
          throw new IllegalArgumentException("Cannot schedule a timer with delay < 1 ms");
      }
      long timerId = timeoutCounter.getAndIncrement();
      InternalTimerHandler task = new InternalTimerHandler(timerId, handler, periodic, delay, context);
      timeouts.put(timerId, task);
      context.addCloseHook(task);
      return timerId;
  }
  InternalTimerHandler(long timerID, Handler<Long> runnable, boolean periodic, long delay, ContextImpl context) {
        
        
      this.context = context;
      this.timerID = timerID;
      this.handler = runnable;
      this.periodic = periodic;
      EventLoop el = context.nettyEventLoop();
      if (periodic) {
        
        
          future = el.scheduleAtFixedRate(this, delay, delay, TimeUnit.MILLISECONDS);
      } else {
        
        
          future = el.schedule(this, delay, TimeUnit.MILLISECONDS);
      }
      if (metrics != null) {
        
        
          metrics.timerCreated(timerID);
      }
  }
  

框图

有待为每个工作原理都加上框图

总结

Vertx核心为EventBus、EventLoop，以及Verticle。这里通过先展示核心类的能力和实现原理，让读者有一个具象的认识，了解每个核心类大概有能干什么。然后通过EventBus的简单收发分析，展示了EventBus的工作原理及EventLoop参与代码执行的方式；通过Verticle的发布，展示了Verticle是如何运转的，以及Verticle的线程安全特性得到保障的原因；最后展示了SharedData进行应用范围内数据共享的实现原理。让读者对Vert.x核心部分有了较为深入的认识。

当然，Vert.x的能力远不止于此，这里仅介绍了单机版运行原理，它还支持集群和高可用特性，都是本文没有覆盖到的；此外，核心部分的文件系统、网络编程相关内容也均未介绍，这些留待之后再说。

最后，总结一波一些核心组件相互之间的关系。

• 一般来说，一个应用只有一个Vertx，在整个应用中传来传去的vertx实例，都是一个，除非我们想要拥有完全隔离的EventBus。
• 一个Vertx实例只持有一个EventBus和一个用于日常调度的EventLoopGroup(用于网络服务监听的不算)。
• 一个Vertx实例持有多个线程池，我们最常解除的只有EventLoopGroup和WorkerPool。
• 一个Context只持有一个EventLoop，即只对应一个线程。通过runOnContext()将任务调度到该EventLoop上执行。
• 一个VerticleManager持有多个VerticleFactory。
• 一个DeployManager持有多个Deployment，Deployment之间的父子关系由Deployment自己维护。
• 一个Deployment可以持有多个Verticle实例，但仅能持有一个Verticle类型