Choerodon 的微服务之路（五）：微服务的“健康保障”

时间 2019-12-05

原文原文链接

本文是Choerodon 的微服务系列推文第五篇，上一篇《Choerodon 的微服务之路（四）：深刻理解微服务配置中心》介绍了配置中心在微服务架构中的做用，本篇将介绍微服务监控的重要性和必要性。java

▌文章的主要内容包括：git

为何要监控
开发者须要监控哪些
猪齿鱼的解决方案

在前面的几期的文章里，介绍了在 Choerodon 的微服务架构中，系统被拆分红多个有着独立部署能力的业务服务，每一个服务可使用不一样的编程语言，不一样的存储介质，来保持最低限度的集中式管理。github

这样的架构决定了功能模块的部署是分布式的，不一样的业务服务单独部署运行的，运行在独立的容器进程中，彼此之间经过网络进行服务调用交互。一次完整的业务流程会通过不少个微服务的处理和传递。编程

在这种状况下，如何监控服务的错误和异常，如何快速地定位和处理问题，以及如何在复杂的容器拓扑中筛选出用户所须要的指标，是 Choerodon 在监控中面临的首要问题。本文将会分享 Choerodon 在微服务下的监控思考，以及结合社区流行的 Spring Cloud、Kubernetes、Prometheus 等开源技术，打造的 Choerodon 的监控方案。缓存

为何要监控

在谈到 Choerodon 的监控以前，你们须要清楚为何须要微服务下的监控。安全

传统的单体应用中，因为应用部署在具体的服务器上，开发者通常会从不一样的层级对应用进行监控。好比猪齿鱼团队经常使用的方式是将监控分红基础设施、系统、应用、业务和用户端这几层，并对每一层分别进行监控。以下图所示。bash

而在微服务系统中，开发者对于监控的关心点是同样的，可是视角却发生了改变，从分层 + 机器的视角转化为以服务为中心的视角。在 Choerodon 中，传统的分层已经不太适用。服务是部署在 k8s 的 pod 中，而不是直接部署在服务器上。团队除了对服务器的监控以外，还须要考虑到 k8s 中容器的监控。一样，因为一个业务流程多是经过一系列的业务服务而实现的，如何追踪业务流的处理也一样相当重要。服务器

因此在微服务中，你们一样离不开监控，有效的监控可以帮开发者快速的定位故障，保护系统健康的运行。微信

平开发者须要监控哪些

在 Choerodon 中，将系统的使用人员分为应用的管理人员，开发人员，运维人员。而不一样的人员在平台中所关心的问题则分别不一样。网络

做为应用的管理人员，须要查看到系统中各个节点实例的运行状态以及实例中应用的状态。
做为开发人员，须要查看本身开发的服务在运行中的全部信息，也须要跟踪请求流的处理顺序和结果，并快速定位问题。
做为运维人员，须要查看系统集群中服务器的 CPU、内存、堆栈等信息。须要查看K8S集群的运行状态，同时也须要查看各个服务的运行日志。

除了这些之外，还须要监控到以下的一些信息：

服务的概览信息：服务的名称，相关的配置等基本信息。
服务的拓扑关系：服务之间的调用关系。
服务的调用链：服务之间的请求调用链。
服务的性能指标：服务的CPU，内存等。
接口的调用监控：接口的吞吐量，错误率，响应时间等。
服务的日志数据：服务运行中产生的日志异常。

简而概之，对于 Choerodon 而言，开发者将监控聚焦在指标监控，调用监控和日志监控。

猪齿鱼的解决方案

在开源社区中，有不少对监控的解决方案，好比指标监控有 Prometheus，链路监控有 zipkin、pinpoint，skywalking，日志则有 elk。

Choerodon 具备多集群多环境管理能力，Choerodon 为须要监控的集群配置监控组件，并与Choerodon 所在集群的监控组件互通以及过滤多余数据，能够最大限度地减小多集群非同一局域网的外网带宽需求。在多集群环境中仍然能够感知所管理应用的运行状态和配置预警信息。

▌指标监控

Spring Boot 的执行器包含一系列的度量指标（Metrics）接口。当你请求 metrics 端点，你可能会看到相似如下的响应：

{
    "counter.status.200.root": 20,
    "counter.status.200.metrics": 3,
    "counter.status.200.star-star": 5,
    "counter.status.401.root": 4,
    "gauge.response.star-star": 6,
    "gauge.response.root": 2,
    "gauge.response.metrics": 3,
    "classes": 5808,
    "classes.loaded": 5808,
    "classes.unloaded": 0,
    "heap": 3728384,
    "heap.committed": 986624,
    "heap.init": 262144,
    "heap.used": 52765,
    "nonheap": 0,
    "nonheap.committed": 77568,
    "nonheap.init": 2496,
    "nonheap.used": 75826,
    "mem": 986624,
    "mem.free": 933858,
    "processors": 8,
    "threads": 15,
    "threads.daemon": 11,
    "threads.peak": 15,
    "threads.totalStarted": 42,
    "uptime": 494836,
    "instance.uptime": 489782,
    "datasource.primary.active": 5,
    "datasource.primary.usage": 0.25
}
复制代码

这些系统指标具体含义以下：

系统内存总量（mem），单位:KB
空闲内存数量（mem.free），单位:KB
处理器数量（processors）
系统正常运行时间（uptime），单位:毫秒
应用上下文（应用实例）正常运行时间（instance.uptime），单位:毫秒
系统平均负载（systemload.average）
堆信息（heap，heap.committed，heap.init，heap.used），单位:KB
线程信息（threads，thread.peak，thead.daemon）
类加载信息（classes，classes.loaded，classes.unloaded）
垃圾收集信息（gc.xxx.count, gc.xxx.time）

有了这些指标，咱们只须要作简单的修改，就可使这些指标被 Prometheus 所监测到。Prometheus 是一套开源的系统监控报警框架。默认状况下 Prometheus 暴露的metrics endpoint为/prometheus。

在项目的pom.xml文件中添加依赖，该依赖包含了 micrometer 和 prometheus 的依赖，并对监控的指标作了扩充。

<dependency>
    <groupId>io.choerodon</groupId>
    <artifactId>choerodon-starter-hitoa</artifactId>
    <version>${choerodon.starters.version}</version>
</dependency>
复制代码

Prometheus提供了4中不一样的Metrics类型：Counter，Gauge，Histogram，Summary。经过Gauge，Choerodon对程序的线程指标进行了扩充，添加了 NEW， RUNNABLE，BLOCKED，WAITING，TIMED_WAITING，TERMINATED 这几种类型，具体代码以下。

@Override
    public void bindTo(MeterRegistry registry) {

        Gauge.builder("jvm.thread.NEW.sum", threadStateBean, ThreadStateBean::getThreadStatusNEWCount)
                .tags(tags)
                .description("thread state NEW count")
                .register(registry);
        Gauge.builder("jvm.thread.RUNNABLE.sum", threadStateBean, ThreadStateBean::getThreadStatusRUNNABLECount)
                .tags(tags)
                .description("thread state RUNNABLE count")
                .register(registry);

        Gauge.builder("jvm.thread.BLOCKED.sum", threadStateBean, ThreadStateBean::getThreadStatusBLOCKEDCount)
                .tags(tags)
                .description("thread state BLOCKED count")
                .register(registry);

        Gauge.builder("jvm.thread.WAITING.sum", threadStateBean, ThreadStateBean::getThreadStatusWAITINGCount)
                .tags(tags)
                .description("thread state WAITING count")
                .register(registry);

        Gauge.builder("jvm.thread.TIMEDWAITING.sum", threadStateBean, ThreadStateBean::getThreadStatusTIMEDWAITINGCount)
                .tags(tags)
                .description("thread state TIMED_WAITING count")
                .register(registry);

        Gauge.builder("jvm.thread.TERMINATED.sum", threadStateBean, ThreadStateBean::getThreadStatusTERMINATEDCount)
                .tags(tags)
                .description("thread state TERMINATED count")
                .register(registry);
    }
复制代码

▌调用监控

在微服务架构中，一个请求可能会涉及到多个服务，请求的路径则可能构成一个网状的调用链。而若是其中的某一个节点发生异常，则整个链条均可能受到影响。

针对这种状况，团队须要有一款调用链监控的工具，来支撑系统监控分布式的请求追踪。目前开源社区中有一些工具：Zipkin、Pinpoint、SkyWalking。Choerodon 使用的是 SkyWalking，它是一款国产的 APM 工具，包括了分布式追踪、性能指标分析、应用和服务依赖分析等。

Skywalking 包含 Agent 和 Collecter，具体的部署和原理在这里不在作具体的介绍，Choerodon 的服务在每一个服务的 DockerFile中，添加了对 Skywalking Agent 的支持。具体以下：

FROM registry.cn-hangzhou.aliyuncs.com/choerodon-tools/javabase:0.7.1
COPY app.jar /iam-service.jar
ENTRYPOINT exec java -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap $JAVA_OPTS $SKYWALKING_OPTS  -jar /iam-service.jar
复制代码

部署时经过配置容器的环境变量 SKYWALKING_OPTS 来实现客户端的配置。

▌日志监控

日志是程序在运行中产生的遵循必定格式（一般包含时间戳）的文本数据，一般由Choerodon的服务生成，输出到不一样的文件中，通常会有系统日志、应用日志、安全日志等等。这些日志分散地存储在不一样的容器、机器中。当开发者在排查故障的时候，日志会帮助他们快速地定位到故障的缘由。

Choerodon 采用了业界通用的日志数据管理解决方案，主要包括elasticsearch、fluent-bit、fluentd 和 Kibana。对于日志的采集分为以下几个步骤。

日志收集：经过 fluent-bit 读取 k8s 集群中 cluster 的日志，并进行收集。
日志过滤：经过 fluentd 将读取到的日志进行过滤，并进行缓存。
日志存储：将过滤后的日志存储至 elasticsearch 集群中。
日志展现：经过 kibana 查询 elasticsearch 中的日志数据，并用于展现。

经过端对端可视化的日志集中管理，给开发团队带来以下的一些好处：

故障查找：经过检索日志信息，定位相应的 bug ，找出解决方案。
服务分析：经过对日志信息进行统计、分析，了解服务器的负荷和服务运行状态。
数据分析：分析数据，对用户进行行为分析。

写在最后

回顾一下这篇文章，介绍了微服务监控的重要性和必要性，以及 Choerodon 是如何应对指标监控，调用监控和日志监控这三种监控的。微服务架构下的服务规模大，系统相对复杂，也使得众多开发者成为了微服务的受害者。如何作好微服务下的监控，保障系统健康地运行，咱们仍有许多须要继续努力的。

更多关于微服务系列的文章，点击蓝字便可阅读 ▼

关于Choerodon猪齿鱼

Choerodon猪齿鱼做为开源多云应用平台，是基于Kubernetes的容器编排和管理能力，整合DevOps工具链、微服务和移动应用框架，来帮助企业实现敏捷化的应用交付和自动化的运营管理，同时提供IoT、支付、数据、智能洞察、企业应用市场等业务组件，致力帮助企业聚焦于业务，加速数字化转型。

你们也能够经过如下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

官网：choerodon.io
论坛：forum.choerodon.io
Github：github.com/choerodon
微信公众号：Choerodon猪齿鱼
微博：Choerodon猪齿鱼

欢迎加入Choerodon猪齿鱼社区，共同为企业数字化服务打造一个开放的生态平台。