概述

微服务调用存在的问题

• 串联调用链路，快速定位问题；
• 理清服务之间的依赖关系；
• 微服务接口性能分析；
• 业务流程调用处理顺序；

全链路追踪：对请求源头到底层服务的调用链路中间的所有环节进行监控。

链路追踪组件选型

OpenTracing语义规范：

https://github.com/opentracing/specification/blob/master/specification.md

组件对比：

	Zipkin	Pinpoint	SkyWalking	CAT
贡献者	Twitter开源	韩国人开源	华为吴晟开源	大众点评开源
实现方式	拦截请求，发送 http/mq 数据到 zipkin 服务	字节码注入	字节码注入	代理埋点（拦截器、注解、过滤器）
接入方式	基于 linkerd/sleuth，引入配置即可	javaagent 字节码	javaagent 字节码	代码侵入
agent 到 collector 传输协议	http、MQ	thrift	gRPC	http/tcp
OpenTracing	支持		支持
粒度	接口级	方法级	方法级	代码级
全局调用统计		支持	支持	支持
traceid 查询	支持		支持
告警		支持	支持	支持
JVM 监控		支持	支持	支持

探针性能对比：
模拟了三种并发用户：500，750，1000。使用 jmeter 测试，每个线程发送 30 个请求，设置思考时间为 10ms。使用的采样率为 1 ，即 100%，这边与生产可能有差别。pinpoint 默认的采样率为 20，即 50%，通过设置 agent 的配置文件改为 100%。zipkin 默认也是 1。组合起来，一共有 12 种。下面看下汇总表：

从上表可以看出，在三种链路监控组件中，skywalking 的探针对吞吐量的影响最小，zipkin 的吞吐量居中。pinpoint 的探针对吞吐量的影响较为明显，在 500 并发用户时，测试服务的吞吐量从 1385 降低到 774，影响很大。然后再看下 CPU 和 memory 的影响，在内部服务器进行的压测，对 CPU 和 memory 的影响都差不多在 10% 之内。

SkyWalking 是什么

skywalking 是一个国产开源框架，2015 年由吴晟开源 ，2017 年加入 Apache 孵化器。skywalking 是分布式系统的应用程序性能监视工具，专为微服务、云原生架构和基于容器（Docker、K8s、Mesos）架构而设计。SkyWalking 是观察性分析平台和应用性能管理系统，提供分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。

官网：http://skywalking.apache.org/
下载：http://skywalking.apache.org/downloads/
Github：https://github.com/apache/skywalking
文档：https://skywalking.apache.org/docs/main/v9.1.0/readme/
中文文档： https://skyapm.github.io/document-cn-translation-of-skywalking/
版本：v9.1.0

实现思路：采集数据》传输数据》存储数据》分析数据》监控报警。

SkyWalking 主要功能特性

• 多种监控手段，可以通过语言探针和 service mesh 获得监控的数据；
• 支持多种语言自动探针，包括 Java，.NET Core 和 Node.JS；
• 轻量高效，无需大数据平台和大量的服务器资源；
• 模块化，UI、存储、集群管理都有多种机制可选；
• 支持告警；
• 优秀的可视化解决方案；

SkyWalking 整体架构

整个架构分成四部分：

• 上部分 Agent

负责从应用中，收集链路信息，发送给 SkyWalking OAP 服务器；

• 下部分 SkyWalking OAP

负责接收 Agent 发送的 Tracing 数据信息，然后进行分析(Analysis Core)，存储到外部存储器(Storage)，最终提供查询(Query)功能；

• 右部分 Storage

Tracing 数据存储，目前支持 ES、MySQL、Sharding Sphere、TiDB、H2 多种存储器，目前采用较多的是 ES，主要考虑是 SkyWalking 开发团队自己的生产环境采用 ES 为主；

• 左部分 SkyWalking UI

负责提供控制台，查看链路等等；

SkyWalking 支持三种探针：

• Agent

基于 ByteBuddy 字节码增强技术实现，通过 jvm 的 agent 参数加载，并在程序启动时拦截指定的方法来收集数据。

• SDK

程序中显式调用 SkyWalking 提供的 SDK 来收集数据，对应用有侵入。

• Service Mesh

通过 Service mesh 的网络代理来收集数据。

后端（Backend）：
接受探针发送过来的数据，进行度量分析，调用链分析和存储。后端主要分为两部分：

• OAP（Observability Analysis Platform）

进行度量分析和调用链分析的后端平台，并支持将数据存储到各种数据库中，如：ElasticSearch，MySQL，InfluxDB等。

• OAL（Observability Analysis Language）

用来进行度量分析的 DSL，类似于 SQL，用于查询度量分析结果和警报。

界面(UI)：

• RocketBot UI

SkyWalking 7.0.0 的默认 web UI

• CLI

命令行界面

这四个模块的交互流程：

SkyWalking 环境搭建部署

说明：

• skywalking agent 和业务系统绑定在一起，负责收集各种监控数据。
• Skywalking oapservice 是负责处理监控数据的，比如接受 skywalking agent 的监控数据，并存储在数据库中。接受 skywalking webapp 的前端请求，从数据库查询数据，并返回数据给前端。Skywalking oapservice 通常以集群的形式存在。
• skywalking webapp，前端界面，用于展示数据。
• 用于存储监控数据的数据库，比如 mysql、elasticsearch 等。

下载 SkyWalking：

下载：http://skywalking.apache.org/downloads/

下载上图箭头所示，SkyWalking APM 包括 oap 和 ui，Java Agent 表示应用需要接入的 agent。
下载链接：

# SkyWalking APM:  v9.1.0
wget https://archive.apache.org/dist/skywalking/9.1.0/apache-skywalking-apm-9.1.0.tar.gz

# Java Agent: v8.11.0 
wget https://archive.apache.org/dist/skywalking/java-agent/8.11.0/apache-skywalking-java-agent-8.11.0.tgz

目录说明：
apm：

• webapp

UI 前端（web 监控页面）的 jar 包和配置文件；

• oap-libs

后台应用的 jar 包，以及它的依赖 jar 包，里边有一个 server-starter-*jar 就是启动程序；

• config

启动后台应用程序的配置文件，是使用的各种配置；

• bin

各种启动脚本，一般使用脚本 startup.* 来启动 web 页面和对应的后台应用；
oapService.：默认使用的后台程序的启动脚本；（使用的是默认模式启动，还支持其他模式，各模式区别见启动模式）；
oapServicelnit.：使用 init 模式启动；在此模式下，OAP 服务器启动以执行初始化工作，然后退出；
oapServiceNolnit.：使用 no init 模式启动；在此模式下，OAP 服务器不进行初始化；
webappService.：UI 前端的启动脚本；
startup.：组合脚本，同时启动 oapService.、webappService.* 脚本；

agent：

• skywalking-agent.jar

代理服务 jar 包。

• config

代理服务启动时使用的配置文件。

• plugins

包含多个插件，代理服务启动时会加载改目录下的所有插件（实际是各种jar包）。

• optional-plugins

可选插件，当需要支持某种功能时，比如 SpringCloud Gateway，则需要把对应的 jar 包拷贝到 plugins 目录下。

搭建 SkyWalking OAP 服务：
1）先使用默认的 H2 数据库存储，不用修改配置

vim config/application.yml

2）启动脚本

bin/startup.sh

日志信息存储在 logs 目录：

启动成功后会启动两个服务，一个是 skywalking-oap-server，一个是 skywalking-web-ui，启动日志在 logs/skywalking-oap-server.log。
skywalking-oap-server 服务启动后会暴露 11800 和 12800 两个端口，分别为收集监控数据的端口 11800 和接受前端请求的端口 12800，修改端口可以修改config/applicaiton.yml。

skywalking-web-ui 服务会占用 8080 端口，修改端口可以修改 webapp/webapp.yml。

server.port：SkyWalking UI 服务端口，默认是8080；
spring.cloud.discovery.client.simple.instances.oap-service：SkyWalking OAP 服务地址数组，SkyWalking UI 界面的数据是通过请求 SkyWalking OAP 服务来获得；

http://xxx:8080

SkyWalking 中三个概念

服务(Service) ：表示对请求提供相同行为的一系列或一组工作负载，在使用 Agent 时，可以定义服务的名字；
服务实例(Service Instance) ：上述的一组工作负载中的每一个工作负载称为一个实例，一个服务实例实际就是操作系统上的一个真实进程；
端点(Endpoint) ：对于特定服务所接收的请求路径，如 HTTP 的 URI 路径和 gRPC 服务的类名 + 方法签名；

SkyWalking 快速开始

SkyWalking Agent 追踪微服务

通过 jar 包方式接入

准备一个 springboot 程序，打成可执行 jar 包，写一个 shell 脚本，在启动项目的 Shell 脚本上，通过 -javaagent 参数进行配置 SkyWalking Agent 来追踪微服务。
startup.sh 脚本：

#!/bin/sh
# SkyWalking Agent配置
export SW_AGENT_NAME=springboot-skywalking-demo # Agent名字，一般使用`spring.application.name`
export SW_AGENT_COLLECTOR_BACKEND_SERVICES=127.0.0.1:11800 # 配置 Collector 地址
export SW_AGENT_SPAN_LIMIT=2000 # 配置链路的最大 Span 数量，默认为 300
export JAVA_AGENT=-javaagent:/root/skywalking-agent/skywalking-agent.jar
java $JAVA_AGENT -jar springboot-skywalking-demo-0.0.1-SNAPSHOT.jar # jar启动

等同于：

java -javaagent:/root/skywalking-agent/skywalking-agent.jar 
-DSW_AGENT_COLLECTOR_BACKEND_SERVICES=127.0.0.1:11800 
-DSW_AGENT_NAME=springboot-skywalking-demo -jar springboot-skywalking-demo-0.0.1-SNAPSHOT.jar

参数名对应 agent/config/agent.config 配置文件中的属性。
属性对应的源码：org.apache.skywalking.apm.agent.core.conf.Config.java。

# The service name in UI
agent.service_name=${SW_AGENT_NAME:Your_ApplicationName}
# Backend service addresses.
collector.backend_service=${SW_AGENT_COLLECTOR_BACKEND_SERVICES:127.0.0.1:11800}

我们也可以使用 skywalking.+配置文件中的配置名 作为系统配置项来进行覆盖。 javaagent 参数配置方式优先级更高

-javaagent:/root/skywalking-agent/skywalking-agent.jar
-Dskywalking.agent.service_name=springboot-skywalking-demo
-Dskywalking.collector.backend_service=127.0.0.1:11800

在 IDEA 中使用 SkyWalking

在运行的程序配置 jvm 参数：

-javaagent:D:\apache\apache-skywalking-java-agent-8.11.0\skywalking-agent\skywalking-agent.jar
-DSW_AGENT_NAME=springboot-skywalking-demo
-DSW_AGENT_COLLECTOR_BACKEND_SERVICES=192.168.65.206:11800 

SkyWalking 跨多个微服务追踪

Skywalking 跨多个微服务追踪，只需要每个微服务启动时添加 javaagent 参数即可。
启动微服务 gateway-service，order-service，user-service ，配置 skywalking 的 jvm 参数。

解决追踪链路不显示 gateway：
拷贝 agent/optional-plugins 目录下的 gateway 插件和 webflux 插件到agent/plugins目录：

SkyWalking 集成日志框架

https://skywalking.apache.org/docs/skywalking-java/latest/en/setup/service-agent/java-agent/application-toolkit-logback-1.x/

引入依赖：

<!-- apm-toolkit-logback-1.x -->
<dependency>
    <groupId>org.apache.skywalking</groupId>
    <artifactId>apm-toolkit-logback-1.x</artifactId>
    <version>8.11.0</version>
</dependency>

微服务添加 logback-spring.xml 文件，并配置 %tid 占位符：

<?xml version="1.0" encoding="UTF-8"?>
<configuration>

    <appender name="console" class="ch.qos.logback.core.ConsoleAppender">
        <!-- 日志的格式化 -->
        <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
            <layout class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.TraceIdPatternLogbackLayout">
                <Pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%tid] [%thread] %-5level %logger{36} -%msg%n</Pattern>
            </layout>
        </encoder>
    </appender>

    <!-- 设置 Appender -->
    <root level="INFO">
        <appender-ref ref="console"/>
    </root>

</configuration>

Skywalking 通过 grpc 上报日志（需要v8.4.0以上）：
gRPC 报告程序可以将收集到的日志转发到 SkyWalking OAP 服务器上。
logback-spring.xml 中添加：

<!-- https://skywalking.apache.org/docs/skywalking-java/latest/en/setup/service-agent/java-agent/application-toolkit-logback-1.x/  -->

<!-- 通过grpc上报日志到skywalking oap-->
<appender name="grpc-log" class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.log.GRPCLogClientAppender">
    <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
        <layout class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.TraceIdPatternLogbackLayout">
            <Pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%tid] [%thread] %-5level %logger{36} -%msg%n</Pattern>
        </layout>
    </encoder>
</appender>

Skywalking UI 效果：

SkyWalking 告警通知

skywalking 告警的核心由一组规则驱动，这些规则定义在config/alarm-settings.yml文件中，告警规则的定义分为三部分：

• 告警规则：它们定义了应该如何触发度量警报，应该考虑什么条件；
• 网络钩子（Webhook）：当警告触发时，哪些服务终端需要被通知；
• gRPC 钩子：远程 gRPC 方法的主机和端口，告警触发后调用；

为了方便，skywalking 发行版中提供了默认的alarm-setting.yml文件，包括一些规则，每个规则有英文注释，可以根据注释得知每个规则的作用：

• 在最近10分钟的3分钟内服务平均响应时间超过1000ms
• 最近10分钟内，服务成功率在2分钟内低于80%
• 服务实例的响应时间在过去10分钟的2分钟内超过1000ms
• 数据库访问{name}的响应时间在过去10分钟的2分钟内超过1000ms

只要我们的服务请求符合alarm-setting.yml文件中的某一条规则就会触发告警。
比如 service_resp_time_rule 规则：
该规则表示服务{name}的响应时间在最近10分钟的3分钟内超过1000ms

• metrics-name：度量名称，也是 OAL 脚本中的度量名。默认配置中可以用于告警的度量有：服务，实例，端点，服务关系，实例关系，端点关系。它只支持long，double和int类型。
• op：操作符。
• threshold：阈值。
• period：多久告警规则需要被检查一下。这是一个时间窗口，与后端部署环境时间相匹配。
• count：在一个周期窗口中，如果按 op 计算超过阈值的次数达到 count，则发送告警。
• silence-period：在时间 N 中触发报警后，在 N -> N + silence-period 这段时间内不告警。
• message：该规则触发时，发送的通知消息。

测试：编写接口，模拟慢查询

@RequestMapping("/info/{id}")
public User info(@PathVariable("id") Integer id){

    try {
        Thread.sleep(2000);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }

    return userService.getById(id);
}

访问接口，过段时间会在 skywalking 控制界面出现了告警信息：

实现回调接口：

@RequestMapping("/notify")
public String notify(@RequestBody Object obj){
    // TODO 告警信息，给技术负责人发短信，钉钉消息，邮件，微信通知等
    System.err.println(obj.toString());
    return "notify successfully";
}

在config/alarm-settings.yml中配置回调接口，并重启 skywalking 服务：

测试访问：[http://localhost:8000/user/info/1](http://localhost:8000/user/info/1)，满足告警规则后，控制台输出告警信息：

参考： https://github.com/apache/skywalking/blob/master/docs/en/setup/backend/backend-alarm.md

对接钉钉：

Webhook 回调通知：
SkyWalking 告警 Webhook 回调要求接收方是一个 Web 容器（比如 tomcat 服务），告警的消息会通过 HTTP 请求进行发送，请求方法为 POST，Content-Type 为 application/json，JSON 格式基于List<org.apache.skywalking.oap.server.core.alarm.AlarmMessage>的集合对象数，集合中的每个AlarmMessage 包含以下信息：

• scopeId. 所有可用的 Scope，参考：org.apache.skywalking.oap.server.core.source.DefaultScopeDefine；
• name. 目标 Scope 的实体名称；
• id0. Scope 实体的 ID；
• id1. 未使用；
• ruleName. 在 alarm-settings.yml 中配置的规则名；
• alarmMessage. 报警消息内容；
• startTime. 告警时间, 位于当前时间与 UTC 1970/1/1 之间；

[{
	scopeId = 2,
	scope = SERVICE_INSTANCE,
	name = 98e1839 a6fdf48b0aedb0ecabb8ea5f7 @192 .168 .233 .1 of springboot - skywalking - demo,
	id0 = c3ByaW5nYm9vdC1za3l3YWxraW5nLWRlbW8 = .1 _OThlMTgzOWE2ZmRmNDhiMGFlZGIwZWNhYmI4ZWE1ZjdAMTkyLjE2OC4yMzMuMQ == ,
	id1 = ,
	ruleName = service_instance_resp_time_rule,
	alarmMessage = Response time of service instance 98e1839 a6fdf48b0aedb0ecabb8ea5f7 @192 .168 .233 .1 of springboot - skywalking - demo is more than 1000 ms in 2 minutes of last 10 minutes,
	startTime = 1613913565462
}, {
	scopeId = 6,
	scope = ENDPOINT_RELATION,
	name = User in User to / user / info / {
		id
	} in springboot - skywalking - demo,
	id0 = VXNlcg == .0 _VXNlcg == ,
	id1 = c3ByaW5nYm9vdC1za3l3YWxraW5nLWRlbW8 = .1 _L3VzZXIvaW5mby97aWR9,
	ruleName = endpoint_relation_resp_time_rule,
	alarmMessage = Response time of endpoint relation User in User to / user / info / {
		id
	} in springboot - skywalking - demo is more than 1000 ms in 2 minutes of last 10 minutes,
	startTime = 1613913565462
}]

SkyWalking 持久化追踪数据

基于 mysql 持久化

1）修改 config 目录下的application.yml，使用 mysql 作为持久化存储的仓库

2）修改 mysql 连接配置

storage:
  # 选择使用mysql，默认使用h2，不会持久化，重启skyWalking之前的数据会丢失
  selector: ${SW_STORAGE:mysql}
  # 使用mysql作为持久化存储的仓库
  mysql:
    properties:
      # 数据库连接地址，创建swtest数据库
      jdbcUrl: ${SW_JDBC_URL:"jdbc:mysql://1ocalhost:3306/swtest"}
      # 用户名
      dataSource.user: ${SW_DATA_SOURCE_USER:root}
      # 密码
      dataSource.password: ${SW_DATA_SOURCE_PASSWORD:root}

注意：需要添加 mysql 数据驱动包，因为在 lib 目录下是没有 mysql 数据驱动包的，所以修改完配置启动是会报错，启动失败的。

3）添加 mysql 数据驱动包到 oap-libs 目录下

4）启动Skywalking

查看 swtest 数据库，可以看到生成了很多表：

说明启动成功了，打开配置对应的地址[http://192.168.65.206:8080/](http://192.168.65.206:8080/)，可以看到 skywalking 的 web 界面。

测试：重启 skywalking，验证追踪数据会不会丢失。

基于 elasticsearch 持久化

1）准备好 elasticsearch 环境（参考 ES 专题）
启动 elasticsearch 服务

bin/elasticsearch -d

2）修改config/application.yml配置文件，指定存储使用 ES，修改 elasticsearch 的连接配置

3）启动 Skywalking 服务

启动时会向 elasticsearch 中创建大量的 index 索引用于持久化数据。
启动应用程序，查看追踪数据是否已经持久化到 elasticsearch 的索引中，然后重启 skywalking，验证追踪数据会不会丢失。

自定义 SkyWalking 链路追踪

如果我们希望对项目中的业务方法，实现链路追踪，方便我们排查问题，可以使用如下的代码。
引入依赖：

<!-- SkyWalking 工具类 -->
<dependency>
    <groupId>org.apache.skywalking</groupId>
    <artifactId>apm-toolkit-trace</artifactId>
    <version>8.11.0</version>
</dependency>

在业务方法中可以 TraceContext 获取到 traceId：

@RequestMapping("/list")
public List<User> list(){

    // TraceContext可以绑定key-value
    TraceContext.putCorrelation("name", "jay");
    Optional<String> op = TraceContext.getCorrelation("name");
    log.info("name = {} ", op.get());
    // 获取追踪的traceId
    String traceId = TraceContext.traceId();
    log.info("traceId = {} ", traceId);

    return userService.list();
}

在 Skywalking UI 中查询 tranceId：

@Trace 将方法加入追踪链路

如果一个业务方法想在 ui 界面的追踪链路上显示出来，只需要在业务方法上加上 @Trace 注解即可：

测试：

加入 @Tags 或 @Tag

我们还可以为追踪链路增加其他额外的信息，比如记录参数和返回信息。实现方式：在方法上增加 @Tag 或者@Tags。

@Trace
@Tag(key = "list", value = "returnedObj")
public List<User> list(){
    return userMapper.list();
}

@Trace
@Tags({@Tag(key = "param", value = "arg[0]"),
        @Tag(key = "user", value = "returnedObj")})
public User getById(Integer id){
    return userMapper.getById(id);
}

SkyWalking 集群部署( oap 服务高可用)

Skywalking 集群是将 skywalking oap 作为一个服务注册到 nacos 上，只要 skywalking oap 服务没有全部宕机，保证有一个 skywalking oap 在运行，就能进行追踪。
搭建一个 skywalking oap 集群需要：
（1）至少一个 Nacos（也可以是 nacos 集群）
（2）至少一个 ElasticSearch （也可以是 es 集群）
（3）至少 2 个 skywalking oap 服务
（4）至少 1 个 UI （ UI 也可以集群多个，用 Nginx 代理统一入口）

1） 修改config/application.yml文件
使用nacos作为注册中心：

修改nacos配置：

可以选择性修改监听端口：

修改存储策略，使用 elasticsearch 作为 storage：

2）配置 ui 服务 webapp.yml 文件的 oap-service，写多个 oap 服务地址

3） 启动微服务测试
指定微服务的 jvm 参数：

-Dskywalking.collector.backend_service=ip1:11800,ip2:11800