SpringCloud(19)之Skywalking应用上篇

一、Skywalking概述

随着互联网架构的扩张，分布式系统变得日趋复杂，越来越多的组件开始走向分布式化，如微服务、消息收发、分布式数据库、分布式缓存、分布式对象存储、跨域调用，这些组件共同构成了繁杂的分布式网络。

思考以下几个问题：

1.一个请求经过了这些服务之后出现了一个调用失败的问题，如何定位问题发生的地方？

2.如何计算每一个节点访问流量？

3.流量波动的时候，增加了哪些节点集群服务？

这些问题想要得到解决，一定是有数据支撑，绝不是靠开发人员或者运维人员的直觉。所以为了解决分布式应用、微服务系统面临的这些挑战，APM系统运营而生。

1.1微服务系统监控的三要素

Logging：就是记录系统行为的离散事件，例如，服务在处理某个请求时打印的错误日志，我们可以将这些日志信息记录到 ElasticSearch 或是其他存储中，然后通过 Kibana 或是其他工具来分析这些日志了解服务的行为和状态。大多数情况下，日志记录的数据很分散，并且相互独立，比如错误日志、请求处理过程中关键步骤的日志等等。
Metrics：是系统在一段时间内某一方面的某个度量，例如，电商系统在一分钟内的请求次数。我们常见的监控系统中记录的数据都属于这个范畴，例如 Promethus、Open-Falcon 等，这些监控系统最终给运维人员展示的是一张张二维的折线图。 Metrics 是可以聚合的，例如，为电商系统中每个 HTTP 接口添加一个计数器，计算每个接口的 QPS，之后我们就可以通过简单的加和计算得到系统的总负载情况。
Tracing：即我们常说的分布式链路追踪。在微服务架构系统中一个请求会经过很多服务处理，调用链路会非常长，要确定中间哪个服务出现异常是非常麻烦的一件事。通过分布式链路追踪，运维人员就可以构建一个请求的视图，这个视图上展示了一个请求从进入系统开始到返回响应的整个流程。这样，就可以从中了解到所有服务的异常情况、网络调用，以及系统的性能瓶颈等。

1.2 什么是链路追踪

谷歌在 2010 年 4 月发表了一篇论文《Dapper, a Large-Scale Distributed Systems Tracing

Infrastructure》介绍了分布式追踪的概念，之后很多互联网公司都开始根据这篇论文打造自己的分布式链路追踪系统。前面提到的 APM 系统的核心技术就是分布式链路追踪。

OpenTracing提供了一个标准的、与供应商无关的框架，这意味着如果开发者想要尝试一种不同的分布式追踪系统，开发者只需要简单地修改Tracer配置即可，而不需要替换整个分布式追踪系统。

现在OpenTracing API目前支持的语言众多：

1.2.1 链路追踪

下面通过官方的一个示例简单介绍说明什么是 Tracing,把Tracing学完后，更有助于大家运用Skywalking UI进行数据分析。

在一个分布式系统中，追踪一个事务或者调用流程，可以用下图方式描绘出来。这类流程图可以看清各组件的组合关系，但它并不能看出一次调用触发了哪个组件调用、什么时间调用、是串行调用还是并行调用。

一种更有效的展现方式就是下图这样，这是一个典型的 trace视图，这种展现方式增加显示了执行时间的上下文，相关服务间的层次关系，进程或者任务的串行或并行调用关系。这样的视图有助于发现系统调用的关键路径。通过关注关键路径的执行过程，开发团队就可以专注于优化路径中的关键服务，最大幅度的提升系统性能。例如下图中，我们可以看到请求串行的调用了授权服务、订单服务以及资源服务，在资源服务中又并行的执行了三个子任务。我们还可以看到，在这整个请求的生命周期中，资源服务耗时是最长的。

1.2.2 OpenTracing

学好OpenTracing，更有助于我们运用Skywalking UI进行数据分析。

Trace

一个Trace代表一个事物、请求或者是流程在分布式系中的执行过程。 OpenTracing 中的一条 Trace被认为是一个由多个 Span 组成的有向无环图（ DAG 图），一个 Span 代表系统中具有开始时间和执行时长的逻辑单元，Span一般会有一个名称，一条 Trace 中 Span 是首尾连接的。

Span

Span 代表系统中具有开始时间和执行时长的逻辑单元，Span 之间通过嵌套或者顺序排列建立逻辑因果关系。换句话就是到某个服务，这个服务的为一个span。

每个 Span 中可以包含以下的信息：

1.操作名称：例如访问的具体 RPC 服务，访问的 URL 地址等；

2.起始时间；

3.结束时间；

4.Span Tag:一组键值对构成的Span标签集合，其中键必须为字符串类型，值可以是字符串、 bool 值或者数字；

5 Span Log ：一组 Span 的日志集合；

6.SpanContext：Trace 的全局上下文信息；

7.References：Span 之间的引用关系，下面详细说明 Span 之间的引用关系；

在一个 Trace 中，一个 Span 可以和一个或者多个 Span 间存在因果关系。目前，OpenTracing 定义了 ChildOf 和 FollowsFrom 两种 Span 之间的引用关系。这两种引用类型代表了子节点和父节点间的直接因果关系。

1.ChildOf 关系：一个 Span 可能是一个父级 Span 的孩子，即为 ChildOf 关系。下面这些情况会构成 ChildOf 关系;

1.1:一个 HTTP 请求之中，被调用的服务端产生的 Span，与发起调用的客户端产生的 Span，就构成了 ChildOf 关系；

1.2: 一个 SQL Insert 操作的 Span，和 ORM 的 save 方法的 Span 构成 ChildOf 关系。

很明显，上述 ChildOf 关系中的父级 Span 都要等待子 Span 的返回，子 Span 的执行时间影响了其所在父级 Span 的执行时间，父级 Span 依赖子 Span 的执行结果。除了串行的任务之外，我们的逻辑中还有很多并行的任务，它们对应的 Span 也是并行的，这种情况下一个父级 Span 可以合并所有子 Span 的执行结果并等待所有并行子 Span 结束。

FollowsFrom****关系 ：在分布式系统中，一些上游系统（父节点）不以任何方式依赖下游系统（子节点）的执行结果，例如，上游系统通过消息队列向下游系统发送消息。这种情况下，下游系统对应的子 Span 和上游系统对应的父级 Span 之间是 FollowsFrom关系。

1.3 常见的APM系统

我们前面提到了APM系统，APM 系统（Application Performance Management，即应用性能管理）是对企业的应用系统进行实时监控，实现对应用性能管理和故障定位的系统化解决方案，在运维中常用。

CAT（开源）：由国内美团点评开源的，基于Java开发，目前提供 Java、C/C++、 Node.js、 Python、Go 等语言的客户端，监控数据会全量统计。国内很多公司在用，例如美团点评、携程、拼多多等。 CAT 需要开发人员手动在应用程序中埋点，对代码侵入性比较强。
ZipKin(开源) ：由 Twitter 公司开发并开源，Java 语言实现。侵入性相对于 CAT 要低一点，需要对web.xml 等相关配置文件进行修改，但依然对系统有一定的侵入性。Zipkin 可以轻松与Spring Cloud 进行集成，也是 Spring Cloud 推荐的 APM 系统。
Pinpoint（开源）：**** 韩国团队开源的 APM 产品，运用了字节码增强技术，只需要在启动时添加启动参数即可实现 APM 功能，对代码无侵入。目前支持 Java 和 PHP 语言，底层采用 HBase 来存储数据，探针收集的数据粒度非常细，但性能损耗较大，因其出现的时间较长，完成度也很高，文档也较为丰富，应用的公司较多。
SkyWalking（开源）：**** 国人开源的产品，2019 年 4 月 17 日 SkyWalking 从 Apache 基金会的孵化器毕业成为顶级项目。目前 SkyWalking 支持 Java、.Net、 Node.js 等探针，数据存储支持 MySQL、 ElasticSearch等。
还有很多不开源的APM系统，例如：淘宝鹰眼、华为云APM等；

1.4 Skywalking 介绍

Skywalking是一个可观测性分析平台和应用性能管理系统，它也是基于OpenTracing规范、开源的AMP 系统。 Skywalking提供分布式跟踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。支持Java ，.Net Core, PHP, NodeJS, Golang, LUA, c++代理。支持Istio +特使服务网格

SkyWalking 核心功能：

服务、服务实例、端点指标分析；
服务拓扑图分析；
服务、服务实例喝端点SLA分析；
慢查询检测
告警

SkyWalking 特点：

多语言自动探针，支持Java、.NET等多种语言；
为多种开源项目提供了插件，为tomcat、HttpClient、Spring、RabbitMQ、Mysql等常见基础设施提供了自动探针；
微内核+插件的架构，存储、集群关丽丽、使用插件集合都可以进行自行选择；
支持告警；
优秀的可视化效果

Skywalking架构图：

SkyWalking 分为三个核心部分：

Agent（探针） ：Agent 运行在各个服务实例中，负责采集服务实例的 Trace 、 Metrics 等数据，然后通过 gRPC 方式上报给 SkyWalking 后端。

OAP： SkyWalking 的后端服务，其主要责任有两个,一个是负责接收 Agent 上报上来的 Trace、 Metrics 等数据，交给 Analysis Core （涉及SkyWalking OAP 中的多个模块）进行流式分析，最终将分析得到的结果写入持久化存储中。SkyWalking 可以使用 ElasticSearch、 H2、 MySQL 等作为其持久化存储，一般线上使用 ElasticSearch 集群作为其后端存储。另一个是负责响应 SkyWalking UI 界面发送来的查询请求，将前面持久化的数据查询出来，组成正确的响应结果返回给 UI 界面进行展示。

UI 界面 ：SkyWalking 前后端进行分离，该 UI 界面负责将用户的查询操作封装为 GraphQL 请求提交给 OAP 后端触发后续的查询操作，待拿到查询结果之后会在前端负责展示。

1.4.1 Skywalking 安装

Skywalking数据存储方式有2种，分别为H2(内存)和elasticsearch，如果数据量比较大，建议使用后者，工作中也建议使用后者。

Skywalking自身提供了UI管理控制台，我们安装的组件：

1:elasticsearch,建议使用elasticsearch7.x

2:elasticsearch-hq,elasticsearch的管理工具，更方便管理elasticsearch

3:Skywalking

4:Skywalking-UI

1.4.2 elasticsearch安装

1)系统资源配置修改

elasticsearch占用系统资源比较大，我们需要修改下系统资源配置，这样才能很好的运行 elasticsearch，修改虚拟机配置， vi /etc/security/limits.conf ，追加内容:

Kotlin 复制代码

* soft nofile 65535
* hard nofile 65535

修改 vi /etc/sysctl.conf ，追加内容 :

Kotlin 复制代码

vm.max_map_count=655360

让配置立即生效：

Kotlin 复制代码

/sbin/sysctl -p

2)安装elasticsearch

建议安装elasticsearch7.x ，我们这里选择7.6.2,并且采用容器的安装方式，安装如下：

Kotlin 复制代码

docker run --name elasticsearch -p 9200:9200  -p 9300:9300 -e "discovery.type=single-node" -e ES_JAVA_OPTS="-Xms84m -Xmx512m" -d elasticsearch:7.6.2

此时就会从远程镜像仓库中拉取对应的镜像。

3)elasticsearch跨域配置

elasticsearch默认是没有开启跨域，我们需要配置跨域，并配置集群节点名字：

Kotlin 复制代码

#进入容器
docker exec -it elasticsearch /bin/bash

修改容器中 /usr/share/elasticsearch/config/elasticsearch.yml 文件，添加配置如下：

Kotlin 复制代码

cluster.name: "elasticsearch"
http.cors.enabled: true
http.cors.allow-origin: "*"
network.host: 0.0.0.0
discovery.zen.minimum_master_nodes: 1

参数说明：

cluster.name:集群服务名字

http.cors.enabled:开启跨域

http.cors.allow-origin: 允许跨域域名，*代表所有域名

network.host: 外部访问的IP

discovery.zen.minimum_master_nodes: 最小主节点个数

安装完成后，重启容器 docker restart elasticsearch ，再访问 http://ip:9200/ 效果如下：

安装 ElasticSearch管理界面elasticsearch-hq

Kotlin 复制代码

docker run -d --name elastic-hq -p 5000:5000 --restart always elastichq/elasticsearch-hq

安装完成后，访问控制台地址 http://IP:5000/#!/clusters/elasticsearch

1.4.3 Skywalking安装

Skywalking的安装我们也采用Docker安装方式，同时我们需要为Skywalking指定存储服务：

Kotlin 复制代码

##通过docker安装skywalking
docker run --name skywalking -d -p 1234:1234 -p 11800:11800 -p 12800:12800 --restart always --link elasticsearch:elasticsearch -e SW_STORAGE=elasticsearch7 - e SW_STORAGE_ES_CLUSTER_NODES=elasticsearch:9200 apache/skywalking-oap-server

参数说明：

--link elasticsearch:elasticsearch:存储服务使用elasticsearch

-e SW_STORAGE=elasticsearch7：存储服务elasticsearch的版本

-e SW_STORAGE_ES_CLUSTER_NODES=elasticsearch:9200:存储服务elasticsearch的链接地址

接下来安装Skywalking-UI，需要指定Skywalking服务名字：

Kotlin 复制代码

docker run --name skywalking-ui -d -p 8080:8080 --link skywalking:skywalking -e SW_OAP_ADDRESS=skywalking:12800 --restart always apache/skywalking-ui

安装完成后，我们接下来访问Skywalking控制台： http://ip:8080

1.5 Skywalking的使用

1.5.1 agent下载

Skywalking-agent，它简称探针，用来收集和发送数据到归集器，我们先来学习下探针使用，探针对应的jar包在Skywalking源码中，我们需要先下载源码。

Skywalking源码下载地址： Index of /dist/skywalking ，我们当前使用的版本是 8.3.0 ，选择下载对应版本。

agent目录结构如下：

目录结构说明：

activations 当前skywalking正在使用的功能组件。

agent.config 文件是 SkyWalking Agent 的唯一配置文件。

plugins 目录存储了当前 Agent 生效的插件。

optional-plugins 目录存储了一些可选的插件（这些插件可能会影响整个系统的性能或是有版权问题），如果需要使用这些插件，需将相应 jar 包移动到 plugins 目录下。

skywalking-agent.jar 是 Agent 的核心 jar 包，由它负责读取 agent.config 配置文件，加载上述插件 jar 包，运行时收集到的 Trace 和 Metrics 数据也是由它发送到 OAP 集群的。

1.5.2 agent应用

项目使用agent，如果是开发环境，可以使用IDEA集成，如果是生产环境，需要将项目打包上传到服务器。为了使用agent，我们同时需要将下载的 apache-skywalking-apm-bin文件包上传到服务器上去。不过无论是开发环境还是生产环境使用agent ，对项目都是无侵入式的。

1.5.3 应用名配置

我们需要用到 agent ，此时需要将 agent/config/agent.config配置文件拷贝到每个需要集成

Skywalking工程的resource目录下，我们将 agent.config拷贝到工程\hailtaxi-parent 的每个子工程目录下，并修改其中的 agent.service_name ，修改如下：

|-------------------|------------------------------------------------------|
| hailtaxi-gateway: | agent.service_name= ${SW_AGENT_NAME:hailtaxi-gateway} | | hailtaxi-driver: | agent.service_name=$ {SW_AGENT_NAME:hailtaxi-driver} |
| hailtaxi-order: | agent.service_name=${SW_AGENT_NAME:hailtaxi-order} |

agent.config 是一个 KV 结构的配置文件，类似于 properties 文件，value 部分使用 "${}" 包裹，其中使用冒号（ ":"）分为两部分，前半部分是可以覆盖该配置项的系统环境变量名称，后半部分为默认值。例如这里的 agent.service_name 配置项，如果系统环境变量中指定了 SW_AGENT_NAME 值（注意，全是大写），则优先使用环境变量中指定的值，如果环境变量未指定，则使用 ++++hailtaxi++++ ++++-++++++++driver++++这个默认值。

1.5.4 生产环境中使用agent

生产环境使用，因此我们需要将agent和每个项目的jar包上传到服务器上，上传apache-skywalking-apm-bin至 /usr/local/server/skywalking ，再将工程hailtaxi-parent 中的项目打包，并分别上传到服务器上，如下三个工程：

hailtaxi-order-1.0-SNAPSHOT.jar

hailtaxi-gateway-1.0-SNAPSHOT.jar

hailtaxi-driver-1.0-SNAPSHOT.jar

1)启动hailtaxi-gateway

XML 复制代码

java -javaagent:/usr/local/server/skywalking/apache-skywalking-apm-
bin/agent/skywalking-agent.jar -Dskywalking.agent.service_name=hailtaxi-gateway -jar hailtaxi-gateway-1.0-SNAPSHOT.jar &

我只就是指定对应的agent包，以及覆盖skywalking的服务名称，大家在生产环境中可以在挂在目录中存放agent包，然后存放统一的config文件，然后再通过命令行覆盖对应的服务名就好了。

1.6Rocketbot

前面我们已经完成了SkyWalking环境搭建和项目应用agent使用，我们来看如何使用 SkyWalking 提供的 UI 界面------ Skywalking Rocketbot。

OAP服务和Rocket（其实就是个web项目）均已启动。

SpringCloud(19)之Skywalking应用上篇

一、Skywalking概述

1.1微服务系统监控的三要素

1.2 什么是链路追踪

1.2.1 链路追踪

1.2.2 OpenTracing

1.3 常见的APM系统

1.4 Skywalking 介绍

1.4.1 Skywalking 安装

1.4.2 elasticsearch安装

1.4.3 Skywalking安装

1.5 Skywalking的使用

1.5.1 agent下载

1.5.2 agent应用

1.5.3 应用名配置

1.5.4 生产环境中使用agent

1.6Rocketbot

1.6.1Rockerbot仪表盘