SkyWalking之APM无侵入可观测原理分析

一、简介（为什么需要用到可观测能力）

随着微服务的开发模式的兴起，早期的单体架构系统已拆分为很多的子系统，各个子系统封装为微服务，各服务间通过HTTP协议RESET API或者RPC协议进行调用。

在单体服务或者微服务较少的情况下，当我们遇到问题时可以直接简单、快速地通过日志进行分析，并迅速判断是A服务还是B服务存在问题，以此快速恢复服务。

但是，在大型企业中，系统数量已经到达了几十个、甚至上百个，每个系统都有不同的架构和调用协议，那么此时这些系统之间的调用关系会变得错综复杂。当某个API接口的业务逻辑很复杂、且调用链路很长，涉及的系统或微服务较多，一旦其中一环出现问题，想要快速定位问题和解决问题那就太难了，如果还是按照早期一一查看日志的方式进行排查，无疑对运维和开发人员是一场噩梦.....

那么有什么方式能够做到快速定位和分析，并且在应用不改造的情况下实施呢？此时就需要一套APM(应用性能管理（Application Performance Management）)系统，将我们业务开发与运维制定的规范嵌入APM系统，在可视化UI面板+告警快速地，通过服务调用链的拓扑图进行问题定位。

APM系统开源的其实有很多产品，例如韩国主导的Pinpoint、大众点评的CAT、推特的ZipKin、CNCF的Jaeger以及本文重点介绍的Apache SkyWalking. 感兴趣的同学都可以一一了解和使用。

APM重点关注三个指标数据: 1、Metrics 2、Logging 3、Tracing

Peter Bourgon在参加完2017 Distributed Tracing Summit后发表的一篇博文，简洁扼要地介绍了指标（Metrics）、链路（Tracing）、日志（Logging）三者的定义和关系。这三种数据在可观察性中都有各自的发挥空间，但每种数据都没办法完全被其他数据代替。

我们从一个典型的服务问题排查过程来看：

通过各式各样的预设报警发现异常（通常是Metrics/Logging）
打开监控大盘查找异常的曲线，并通过查询找到异常的模块（Metrics）
对这个模块以及关联日志进行查询分析，找到核心的报错信息（Logging）
通过详细的调用链数据定位到引起问题的代码（Tracing）

二、SkyWalking

SkyWalking 由中国华为和 Apache 开源社区共同开发，目前已成为 Apache 基金会下的顶级项目之一，作者吴晟。

SkyWalking 是基于 Apache 开源生态的分布式应用性能监控系统。它提供了面向云原生架构的 APM（Application Performance Management）解决方案，支持多种语言的应用和多种方式的部署，具有以下特点：

分布式追踪：支持多种语言、多种协议的应用追踪，可获取全链路的请求数据。

应用拓扑图：根据追踪数据自动生成应用程序拓扑，便于系统管理员快速定位故障。

监控告警：具有丰富的监控指标和告警规则，支持第三方告警接口。

插件化体系：可通过插件模块实现对不同类型服务的监控和数据收集。

2.1 无侵入式说明

SkyWalking Agent采集调用链信息的客户端对业务是无感的、非侵入式的。那也就意味着，你的项目代码无须修改一行代码就能加入SkyWalking的采集、监控、调用链追踪。

原始项目接入SkyWalking很轻松、门槛很低。底层大概得原理是：JAVA本身就提供JAVAAGENT的机制以及采用动态修改字节码技术的方式，Agent在JVM底层帮我们把调用链采集上报的过程透明化了，开发人员作为业务层写代码是无感的。

注意：无侵入方式实现

应用服务器中需要安装SkyWalking-agent.jar
应用需要重启，并且在启动参数中添加相关配置，在后面案例中会提供详细的参

接下来我会使用入门案例做个简单初步分析和验证.

三、案例验证（使用JAVA+PHP）

3.1 安装SkyWalking的OAP系统安装包

下载: SkyWalking的OAP压缩包

下载页面: Downloads | Apache SkyWalking

3.2 上传下载好的OAP的tar包

3.3 运行OAP

1、解压 apache-skywalking-apm-9.7.0.tar.gz

tar -zxvf apache-skywalking-apm-9.7.0.tar.gz

2、进入 apache-skywalking-apm-bin

3、在启动OAP之前需要确定机器上是否安装JDK

注意SkyWalking新版安装包需要JDK11以上，否则无法启动

Linux 上安装及卸载JDK（包含yum方式）-CSDN博客

Exception in thread "main" java.lang.UnsupportedClassVersionError: org/apache/skywalking/oap/server/starter/OAPServerStartUp has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0

该错误告诉我们，我们的类是在比尝试运行它的版本更高的Java版本下编译的。更具体地说，在这种情况下，我们使用Java 11编译了我们的类，并尝试使用Java 8运行它。

作为参考，让我们快速看一下Java版本号。 如果我们需要下载适当的Java版本，这将很方便。

主版本号和次版本号存储在类字节码中的字节六和七中。

让我们看看主要版本号如何映射到Java版本：

45 = Java 1.1

46 = Java 1.2

47 = Java 1.3

48 = Java 1.4

49 = Java 5

50 = Java 6

51 = Java 7

52 = Java 8

53 = Java 9

54 = Java 10

55 = Java 11

56 = Java 12

57 = Java 13

4、进入bin目录有启动脚本，我们先启动oapService.sh(服务端)、再启动webappService.sh(UI客户端)

sh oapService.sh 
sh webappService.sh

5、启动完毕，执行jps程序查看进程有没有正常拉起来

如果JPS无法使用，则参考linux环境下JPS命令未找到-CSDN博客

6、正常会出现上面两个进程，如果没有拉起来在logs目录可以查看错误信息进行排查，如无问题则继续往下

7、访问SkyWalking 8080 UI界面，默认端口8080

http://$ip:8080

目前刚开始服务列表这些是空的， SkyWalking支持多种数据存储介质例如默认内存、MySQL、ES等等，一般生产环境使用ES集群进行存储，我们测试直接不用改什么配置，默认采用内存的形式。那就意味着如果服务重启，则之前的测试数据会丢失。

3.4 Trace调用链追踪的基本原理介绍

Trace调用链追踪，例如A->B->C->D 存在4个微服务的调用链关系。假设我们通过HTTP协议进行交互，该怎么把调用链信息拿到呢?

Google的Dapper论文中提到了一种分布式调用链追踪的实现方式, 市面上的APM系统调用链追踪大部分是参考这篇论文实现的。每个调用链可以使用TraceId进行标识，每个服务被调用称为一个Span会伴随一个SpanId, 每当父服务调用子服务的时候会将TraceId以及父层的SpanId往子服务传递，子服务收到后，记录父层传递的SpanId作为自己Span的父id, 最后2个服务都会把调用信息上报到APM的服务端，例如SkyWalking的某个端口。

最后SkyWalking因为采集到了这些Span的信息，Span信息记录着父子关系、调用时间信息、TraceId等等，经过UI绘制，就能把这一次调用的TraceId的所有Span进行串联，最终形成调用链拓扑图。

接下来我们部署一个SpringBoot项目和一个PHP项目，很简单的链路，SpringBoot调用PHP项目的HTTP接口，我们来看下SkyWalking的UI界面以及分析原理验证。

3.5 运行项目
我本地搭建了一套SpringBoot项目，但是如果只是简单运行，那肯定和我们的SkyWalking还没进行结合。那怎么结合起来呢? 那就是通过运行的时候，设置参数，和SkyWalking Agent进行结合。

我们上面提到过，使用SkyWalking Agent最大的好处就是【无代码侵入】，那也就是意味着我们的源代码无须做任何变更，只需要在运行java -jar JAR包的时候额外加入一下参数即可:

下载Agent：

下载后进行解压，我将使用两种方式验证；

本地IDEA运行和Linux环境下运行，但注意运行需要同时配置JVM启动参数

# skywalking‐agent.jar的本地磁盘的路径
-javaagent:F:\Apache\skywalking-agent\skywalking-agent.jar
# 在skywalking上显示的服务名
-Dskywalking.agent.service_name=SkyWalking-Test
# skywalking的collector服务的IP及端口
-Dskywalking.collector.backend_service=192.168.20.128:11800