当超时和断路器允许消费者在调用端处理失败，那么遇到崩溃又如何做呢?当面对崩溃时，故障转移策略重新启动系统中失败的部分。但在实现这一目标之前，我们必须能够检测到微服务已经死亡。

健康检查是由指示其状态的微服务提供的API。它告诉调用者，服务是否健康。调用通常使用HTTP协议交互，但不是必需的。调用之后，将执行一组检查，并计算和返回一个全局状态。当检测到微服务不健康时，就不应该再调用它了，因为调用结果很可能是失败的。注意，调用一个健康的微服务也不能保证成功。健康检查仅仅表明微服务正在运行，并不是说它会准确地处理你的请求，或者说网络会给出它请求的答案。

根据你的环境，你可能有不同程度的健康检查。例如，您可能会在部署时使用准备就绪（ readiness）检查，以确定微服务何时准备好为请求服务(当所有内容都已正确初始化)。活跃度（Liveness）检查用于检测错误行为，表示微服务是否能够成功处理请求。如果由于目标微服务不能响应而无法执行活跃度（liveness）检查，那么微服务可能已经崩溃。

在一个 Vert.x应用程序中，有多种方法来实现健康检查。您可以简单地实现一个返回状态的路由（route），甚至可以使用一个真正的请求。你也可以使用Vert.x的健康检查模块在您的应用程序中各自的实现健康检查，并组合不同的结果。下面的代码实例给出了一个提供两级健康检查的应用程序:

Router router = Router.router(vertx);
HealthCheckHandler hch = HealthCheckHandler.create(vertx);
// A procedure to check if we can get a database connection
hch.register("db-connection", future -> {
    client.rxGetConnection()
        .subscribe(c -> {
            future.complete();
            c.close();
        },
        future::fail
    );
});
// A second (business) procedure
hch.register("business-check", future -> {
    // ...
});
// Map /health to the health check handler
router.get("/health").handler(hch);
// ...

在您完成了健康检查之后，您可以实现一个故障转移（failover）策略。一般来说，策略只是重新启动系统中宕掉的部分，希望得到最好的结果。虽然故障转移通常由您的运行时基础设施提供，但是Vert.x提供了一个内置的故障转移，当集群中的一个节点死亡时触发。通过Vert.x的故障转移，你不需要自定义的健康检查，因为Vert.x集群会周期性的ping各个节点。当Vert.x丢失了对某个节点的追踪时，Vert.x选择集群的一个健康节点并重新部署已宕机的服务。