如何配置微服务的健康检查？ | 微服务系列第九篇

魏新宇

发布于 2018-09-30 11:44:47

6.2K0

发布于 2018-09-30 11:44:47

文章被收录于专栏：大魏分享（微信公众号：david-share）大魏分享（微信公众号：david-share）

文章导读

本文仅代表作者的个人观点；
本文的内容仅限于技术探讨，不能作为指导生产环境的素材；
本文素材是红帽公司产品技术和手册；
本文分为系列文章，将会有多篇，初步预计将会有26篇。

一、MicroProfile健康检查规范

随着环境中运行的微服务数量的增加，主动监控微服务的所有实例的运行状况变得更加重要。使用像OpenShift这样的容器管理技术，可以利用运行状况检查，来自动决定是否使用新容器来丢弃和替换不健康的容器。通过快速更换不健康的容器，OpenShift极大地提高了服务的整体正常运行时间。

为了更好地集成部署在WildFly Swarm容器中并在OpenShift等平台上运行的微服务，MicroProfile Health规范为自动化流程提供了一种检查微服务健康状况的简单方法。规范中定义的运行状况检查体系结构由基于MicroProfile的微服务中的单个/运行状况REST端点组成，该端点使用HTTP状态代码报告整个微服务的运行状况。这种方法很有效，因为OpenShift很容易使用和解析运行状况检查，并且微服务开发人员只需要很少的额外工作。

要在WildFly Swarm上运行的微服务中利用此功能，在pom.xml中包含微文件依赖关系，以加载MicroProfile 1.3中的所有可用规范。请注意，如果使用WildFly Swarm物料清单，则无需指定版本，如以下示例所示：

<dependency>
	<groupId>org.wildfly.swarm</groupId>
	<artifactId>microprofile</artifactId>
</dependency>

要为微服务创建新的运行状况检查，在实现HealthCheck接口的任何类上使用@Health批注。 HealthCheck接口需要实现一个名为call（）的方法，该方法返回一个HealthCheckResponse对象，如以下示例所示：

1 使用@Health批注在微服务中创建新的运行状况检查。

2 运行状况检查类必须实现HealthCheck接口。

3 实现HealthCheck接口的类必须实现call（）方法并返回HealthCheckResponse对象。

4 使用HealthCheckResponseBuilder工厂类来构建运行状况检查响应。

当运行包含一个或多个运行状况检查的微服务时，WildFly Swarm会自动在URL /运行状况下公开HTTP端点，该端点与基本应用程序URL无关。当WildFly Swarm服务器在此运行状况端点上收到请求时，服务器会触发每个运行状况检查中的call（）方法。如果运行状况检查成功，并且HealthCheckResponse设置为UP值，则将HTTP状态代码200设置为响应。如果运行状况检查失败并且HealthCheckResponse设置为DOWN值，则返回503状态代码。除了响应代码之外，/ health端点还返回JSON数据以及有关运行的运行状况检查的详细信息，如以下示例所示：

$ curl http://localhost:8080/health{
"outcome": "UP",
"checks": [
    {
        "name": "alive",
        "state": "UP"
    }
  ]
}

如果在单个微服务中定义了多个运行状况检查，WildFly Swarm会聚合检查并报告单个总体状态，该状态表示所有检查的逻辑AND。也就是说，如果单个检查失败，整个微服务的健康结果将报告为DOWN：

$ curl http://localhost:8080/health{
"outcome": "DOWN",
"checks": [
    {
        "name": "alive",
        "state": "UP"
    },
    {
        "name": "database",
        "state": "DOWN"
    }
  ]
}

为方便起见，HealthCheckResponse类提供了命名（String name）方法，以生成已设置其名称的HealthCheckResponseBuilder实例。可以使用方法链来在一行中构建整个HealthCheckReponse对象。使用HealthCheckResponseBuilder上提供的方法来控制运行状况检查的名称或使用运行状况响应返回自定义数据。下表总结了可用的方法：

以下示例显示如何使用附加的自定义数据构建HealthCheckResponse：

HealthCheckResponse.named("sessions-check")
	.withData("sessionCount", sessionCount)
	.withData("lastCheckDate", new Date().toString())
	.state(sessionCount > 0)
	.build();

如果使用上一个示例中的代码命中/ health端点，则响应如下：

$ curl http://localhost:8080/health{
"outcome": "UP",
"checks": [
    {
        "name": "sessions-check",
        "sessionCount": 160,
        "lastCheckDate":  "Wed Apr 4 02:00:00 EST 2018"
        "state": "UP"
    }
  ]
}

二、使用探针使用OpenShift监视容器运行状况检查

在容器化微服务环境中，由于诸如临时连接丢失，配置错误或外部依赖性问题等问题，各个组件通常会变得不健康。 OpenShift Container Platform提供了许多检测和处理不健康容器的选项。 OpenShift用于监视容器运行状况的主要资源称为探测。

探测是一种诊断过程，它使用某些操作来查询各个容器的运行状况，通常是在可配置的时间表上。 OpenShift有两种主要类型的探针： liveness probes and readiness probes.

liveness probes

liveness probes检查配置它的容器是否仍在运行。如果活动探测器失败，OpenShift会杀死容器，然后容器会受到重启策略的影响。成功部署pod后，其活动探测将按照监视pod的运行状况的计划持续运行。

readiness probes.

readiness probes.情况探测器确定容器是否已准备好为请求提供服务。在部署pod期间运行准备探针，以确定pod是否已完成部署。如果容量的准备就绪探测失败，则内置于OpenShift中的端点控制器可确保容器的IP地址从所有连接的服务的端点中删除。 OpenShift还使用就绪探测器向端点控制器发出信号，即使容器正在运行，它也不应该从代理接收任何流量。

在设计运行状况检查时，重要的是要考虑它是用作活动探测还是准备探测。区别很重要，因为准备情况探测器运行状况检查必须指示容器是否已启动并正在运行并准备好为请求提供服务。准备就绪探测失败可以简单地指示容器需要更多时间来完成启动。但是，活动探测器运行状况检查可以更简单，并且只需要指示容器的当前状态（向上或向下）。失败的活动探测表明需要立即重启pod。

liveness和readyiness探针都支持一些常用选项，用于控制OpenShift何时执行它们以及它们如何对故障做出反应。这些常见选项包括：

initialDelaySeconds

在容器完成启动后，探针必须等待的时间（以秒为单位）。

设置的时间

在考虑探测失败因为没有收到响应之前，OpenShift必须等待探测完成的时间（以秒为单位）。

此外，通过利用三种可能的方法之一来定义探针来配置活性和就绪性探针。这些方法包括：

HTTP检查

OpenShift将HTTP GET请求发送到可配置的URL，以确定pod的健康状况。如果在超时之前收到HTTP响应并且响应代码在200和399之间，则认为检查成功。以下是使用httpGet方法探测pod的准备探测的示例：

...
readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 15
  timeoutSeconds: 1
...

Container执行检查

OpenShift在容器内执行命令。退出状态为0的支票被认为是成功的。以下是使用exec方法探测pod的活动探测示例：

...
livenessProbe:
  exec:
    command:
    - cat
    - /tmp/health
  initialDelaySeconds: 15
  timeoutSeconds: 1
...

TCP Socket Checks

OpenShift尝试打开容器的套接字。如果检查可以建立连接，则仅认为容器是健康的。

...
livenessProbe:
  tcpSocket:
    port: 8080
  initialDelaySeconds: 15
  timeoutSeconds: 1
...

使用HTTP检查可以很好地与MicroProfile健康规范运行状况检查端点配合使用，因为如果运行状况检查成功，它们将返回HTTP状态200，如果失败则返回HTTP状态503。容器执行检查和TCP套接字检查对于探测此类基于HTTP的运行状况检查端点不可用的容器非常有用。

三、在OpenShift Web控制台中创建运行状况检查探针

将微服务部署到OpenShift集群后，也可以配置探针。可以使用上面的YAML资源定义执行此操作，也可以使用OpenShift Web控制台。要使用Web控制台创建探针，确保选择了当前项目，然后选择Applications→Deployments并选择微服务的部署：

四、使用fabric8 Maven插件定义运行状况检查资源

fabric8 Maven插件提供了一种简单的方法，可以为部署在OpenShift Container Platform上的微服务自动创建应用程序运行状况检查。为此，在deployment.yml OpenShift资源片段中包含所需探测的YAML定义。将此YAML文件放在项目的src / main / fabric8目录中。以下是deployment.yml文件的示例，该文件为其微服务定义活动性和就绪性探测：

spec:
  template:
    spec:
      containers:
        - readinessProbe:
            httpGet:
              path: /health
              port: 8080
              scheme: HTTP
            initialDelaySeconds: 15
            timeoutSeconds: 5
          livenessProbe:
            httpGet:
              path: /health
              port: 8080
              scheme: HTTP
            initialDelaySeconds: 15
            timeoutSeconds: 5
          ports:
          - containerPort: 8080
            name: http
            protocol: TCP

五、实验展现：施健康检查

首先通过JBDS导入一下maven项目：

在HolaHealth类中实现MicroProfile健康规范要求。

通过展开JBoss Developer Studio左侧窗格中Project Explorer选项卡中的hola项打开HolaHealth类，然后单击hola→Java Resources→src / main / java→com.redhat.training.msa.hola.health并展开它。双击HolaHealth.java文件

添加@Health类级别注释以将该类配置为运行状况检查信息提供程序。

支持MicroProfile健康规范的要求。将org.eclipse.microprofile.health.HealthCheck接口声明为HotHealth类实现之一。

实现call（）方法以警告运行状况检查探针应用程序中的端点始终在运行。此方法需要返回HealthCheckResponse.named（“hola service”）。up（）。build（）值。