Skywalking链路追踪
一、APM
1、什么是APM
随着微服务架构的流行，一次请求往往需要涉及到多个服务，因此服务性能监控和排查就变得更复杂
- 不同的服务可能由不同的团队开发、甚至可能使用不同的编程语言来实现
- 服务有可能布在了几千台服务器，横跨多个不同的数据中心
因此，就需要一些可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题，这就是APM系统，全称是（Application Performance Monitor，当然也有叫 Application Performance Management tools）
APM最早是谷歌公开的论文提到的 Google Dapper。Dapper是Google生产环境下的分布式跟踪系统，自从Dapper发展成为一流的监控系统之后，给google的开发者和运维团队帮了大忙，所以谷歌公开论文分享了Dapper。
2、原理
先来看一次请求调用示例：
- 包括：前端（A），两个中间层（B和C），以及两个后端（D和E）
- 当用户发起一个请求时，首先到达前端A服务，然后分别对B服务和C服务进行RPC调用；
- B服务处理完给A做出响应，但是C服务还需要和后端的D服务和E服务交互之后再返还给A服务，最后由A服务来响应用户的请求；
如何才能实现跟踪呢？需要明白下面几个概念：
- 探针：负责在客户端程序运行时收集服务调用链路信息，发送给收集器
- 收集器：负责将数据格式化，保存到存储器
- 存储器：保存数据
- UI界面：统计并展示
探针会在链路追踪时记录每次调用的信息，Span是基本单元，一次链路调用（可以是RPC，DB等没有特定的限制）创建一个span，通过一个64位ID标识它；同时附加（Annotation）作为payload负载信息，用于记录性能等数据。
一个Span的基本数据结构：
type Span struct {
TraceID int64 // 用于标示一次完整的请求id
Name string //名称
ID int64 // 当前这次调用span_id
ParentID int64 // 上层服务的调用span_id 最上层服务parent_id为null，代表根服务root
Annotation []Annotation // 记录性能等数据
Debug bool
}
一次请求的每个链路，通过spanId、parentId就能串联起来：
当然，从请求到服务器开始，服务器返回response结束，每个span存在相同的唯一标识trace_id。
3、技术选型
市面上的全链路监控理论模型大多都是借鉴Google Dapper论文，重点关注以下三种APM组件：
- Zipkin：由Twitter公司开源，开放源代码分布式的跟踪系统，用于收集服务的定时数据，以解决微服务架构中的延迟问题，包括：数据的收集、存储、查找和展现。
- Pinpoint：一款对Java编写的大规模分布式系统的APM工具，由韩国人开源的分布式跟踪组件。
- Skywalking：国产的优秀APM组件，是一个对JAVA分布式应用程序集群的业务运行情况进行追踪、告警和分析的系统。现在是Apache的顶级项目之一。
选项就是对比各个系统的使用差异，主要对比项：
- 探针的性能
主要是agent对服务的吞吐量、CPU和内存的影响。微服务的规模和动态性使得数据收集的成本大幅度提高。 - collector的可扩展性
能够水平扩展以便支持大规模服务器集群。 - 全面的调用链路数据分析
提供代码级别的可见性以便轻松定位失败点和瓶颈。 - 对于开发透明，容易开关
添加新功能而无需修改代码，容易启用或者禁用。 - 完整的调用链应用拓扑
自动检测应用拓扑，帮助你搞清楚应用的架构
三者对比如下：
| 对比项 | zipkin | pinpoint | skywalking |
|---|---|---|---|
| 探针性能 | 中 | 低 | 高 |
| collector扩展性 | 高 | 中 | 高 |
| 调用链路数据分析 | 低 | 高 | 中 |
| 对开发透明性 | 中 | 高 | 高 |
| 调用链应用拓扑 | 中 | 高 | 中 |
| 社区支持 | 高 | 中 | 高 |
综上所述，使用skywalking是最佳的选择。
二、Skywalking
1、简介
SkyWalking创建与2015年，提供分布式追踪功能，是一个功能完备的APM系统。
官网地址：http://skywalking.apache.org/
主要的特征：
- 多语言探针或类库
- Java自动探针，追踪和监控程序时，不需要修改源码。
- 社区提供的其他多语言探针
- .NET Core
- Node.js
- 多种后端存储： ElasticSearch， H2
- 支持OpenTracing
- Java自动探针支持和OpenTracing API协同工作
- 轻量级、完善功能的后端聚合和分析
- 现代化Web UI
- 日志集成
- 应用、实例和服务的告警
大致分四个部分：
- skywalking-oap-server： 就是Observability Analysis Platform的服务，用来收集和处理探针发来的数据
- skywalking-UI： 就是skywalking提供的Web UI 服务，图形化方式展示服务链路、拓扑图、trace、性能监控等
- agent： 探针，获取服务调用的链路信息、性能信息，发送到skywalking的OAP服务
- Storage： 存储，一般选择elasticsearch
因此我们安装部署也从这四个方面入手，目前elasticsearch已经安装完成，只需要部署其他3个即可。
2、部署安装
- 通过docker部署，需要部署两部分，分别是skywalking-oap-server和skywalking-UI。
#oap服务，需要指定Elasticsearch以及链接信息
docker run -d \
-e TZ=Asia/Shanghai \
--name oap \
-p 12800:12800 \
-p 11800:11800 \
-e SW_STORAGE=elasticsearch \
-e SW_STORAGE_ES_CLUSTER_NODES=192.168.150.101:9200 \
apache/skywalking-oap-server:9.1.0
#部署ui，需要指定oap服务
docker run -d \
--name oap-ui \
-p 48080:8080 \
-e TZ=Asia/Shanghai \
-e SW_OAP_ADDRESS=http://192.168.150.101:12800 \
apache/skywalking-ui:9.1.0
- 启动成功后，访问地址http://ip:48080/，即可查看skywalking的ui界面。
3、微服务探针
现在，Skywalking的服务端已经启动完成，我们还需要在微服务中加入服务探针，来收集数据。
将skywalking-agent解压到非中文目录。
在微服务中设置启动参数，以work微服务为例：
输入如下内容：
-javaagent:F:\code\sl-express\docs\resources\skywalking-agent\skywalking-agent.jar
-Dskywalking.agent.service_name=ms::sl-express-ms-work
-Dskywalking.collector.backend_service=192.168.150.101:11800
参数说明：
- javaagent： 将skywalking-agent以代理的方式整合到微服务中
- skywalking.agent.service_name：指定服务名称，格式：[{group name}::]{logic name}
- skywalking.collector.backend_service：指定oap服务，注意端口要走11800
设置完成后，重新启动work微服务，多请求几次接口，即可自oap-ui中看到数据。
查看链路：
服务关系拓扑图：
