分布式链路追踪，要怎么玩下?

大家好！我是"无敌码农"，最近几个月因为各方面原因公众号没有及时更新，在这里给持续关注本公众号的朋友们表示歉意！2021年我将调整好心态持续给大家输出有价值的技术干货。在接下来的一段时间我所撰写的技术内容将偏向于“云原生”技术相关的内容，主要会涉及Devops、Kubernetes、Service Mesh等内容。而之所以偏向于写这些内容，一方面是自己的兴趣，另一方面也是最近几年以Kubernetes为基础设施的“云原生”技术体系已经成为主流，作为一名研发人员如果只专注于业务代码的研发，而对程序运行的基础环境、架构体系缺乏足够的认识和了解，也是不利于成长和进阶的！

当然，我也会持续分享编程技术相关的干货内容，例如有用的编程技巧、以及程序语言（如Java并发编程、I/O、网络等）相关的技术，但有一点我将尽量减少去写一些市面上已经被写烂、重复N次的技术内容、以及各种鸡汤文！以免浪费大家时间！

好了，废话不多说！本篇文章我将给大家介绍“分布式链路追踪”的内容，对于目前大部分采用微服务架构的公司来说，分布式链路追踪都是必备的，无论它是传统微服务体系亦或是新一代Service Mesh的微服务架构！而具体介绍的内容，本文不是完全讲理论，而是希望从理论到实践，引导大家去操作，因为只有这样才能真正从技术层面有深刻的认识和了解！

分布式链路追踪概述

在具体介绍分布式链路追踪系统之前，我们首先需要理解下什么是链路追踪？在本专栏前面关于监控系统的介绍中可以知道，监控系统的观测数据主要来源于统计指标、日志以及链路追踪这三个方面。而这些数据从类型上又可以划分为两种：请求级别、聚合级别。

请求级别的数据主要来源于真实的请求，例如一次HTTP调用、RPC调用等，本文要介绍的链路追踪就是这种类型。而聚合级别则是接口请求的度量指标或者一些参数数据的聚合，如QPS、CPU使用率等数值。日志和统计指标数据既可以是请求级别，也可以是聚合级别，因为它们可能来自源于真实的请求，也可能是系统自身诊断时记录下来的信息。

而对于链路追踪来说，它主要的逻辑就是将请求链路的完整行为记录下来，以便可以通过可视化的形式实现链路查询、性能分析、依赖关系、拓扑图等分布式链路追踪相关的功能。如下图所示：

在上图中假设微服务系统中的一次接口调用总共有两个微服务参与，其调用关系分别是A->B->C，其中B服务还与Redis这样的第三方服务产生了调用关系、C服务则还需要调用MySQL数据库服务。所以实际上链路追踪所做的事情就是详细记录A->B（B->Redis）->C（C->MySQL）这条完整链路上的详细调用信息，例如接口响应结果、耗时等。

那么这条调用链路上的数据到底是怎样被记录的呢？接下来我们继续以上面的调用链为例分析下链路追踪信息的具体组成和传递形式，以便进一步理解分布式链路追踪系统的原理和概念。具体逻辑示意图如下：

如上图所示，分布式链路追踪所监控的对象就是一次次调用所产生的链路，图中1-8所示的就是一条完整的链路（Trace），系统会通过唯一的标识（TraceId）对此进行记录。而链路中的每一个依赖调用都会生成一个调用踪迹信息（Span），最开始生成的Span叫做根Span（Root Span），后续生成的Span都会将前一个Span 的标示（Sid）作为本Span信息的父ID（Pid）。

这样以此类推，Span信息就会随着链路的执行被进程内或跨进程进行上下文传递，通过Span数据链就能将一次次链路调用所产生的踪迹信息串联起来，而每一个Span之上附着的日志信息（Annotation）就是我们进行调用链监控分析的数据来源。这就是分布式链路追踪的基本原理。

而说到这里，你可能会有疑问：监控这么大的数据量，是不是会很消耗系统资源？的确如此，所以大部分链路追踪系统，都会存在一个叫做采样率（Sampling）的设定，用来控制系统采集链路信息的比例，从而提升系统性能。因为很多时候，大量的链路信息都是相同的，我们需要关注的可能也只是相对耗时较高、出错次数较多的链路，而并没有必要100%的进行采集。

SkyWalking简介

前面我们从基本原理的角度说明了链路追踪是什么，那么接下来我们将介绍下目前最流行的分布式链路追踪系统——SkyWalking。

SkyWalking是一款优秀的开源APM（Application Performance Management）系统，它不仅提供了链路追踪，链路分析等分布式追踪功能，还支持性能指标分析、应用和服务依赖性分析、服务拓扑图分析、报警等一系列应用性能监控相关的功能，可以帮助我们有效地定位问题。

而从数据收集上看，SkyWalking支持多种不同的数据来源及格式，包括支持Java、.NET Core、NodeJS、PHP和Python等不同语言的无侵入式Agent探针，以及对Service Mesh（服务网格）架构的支持等。其具体结构如下图所示：

如上图所示，SkyWalking的核心由链路收集服务器（Receiver Cluster）、聚合服务器（AggregatorCluster）组成。其中Receiver Cluster是整个后端服务接入的入口，专门用于收集服务的各种指标及链路信息。

而AggregatorCluster则用于汇总、聚合收集器收集到的数据，并最终将聚合数据存储到数据库中，而具体存储方式可以有多种，例如常见的ElasticSearch、MySQL、TIDB等，我们可以根据实际需要进行选择。这些聚合数据后面可以用于告警设置，也可以被GUI/CLI等可视化系统以HTTP的形式访问后进行可视化展示。

此外，从数据采集逻辑上看，SkyWalking支持多种语言探针及项目协议，能够覆盖目前大部分主流的分布式技术栈，具体来说主要有以下3种：

• Metrics System：统计系统。支持直接从Prometheus中拉取度量指标数据到SkyWalking，也支持程序自身通过micrometer推送数据；

• Agents：业务探针。指在各个业务系统中集成探针服务来进行链路追踪，即链路数据采集。SkyWalking支持Java、Go、.NET、PHP、NodeJS、Python、Nginx LUA等多种语言的探针。此外，它还支持通过gRPC或者HTTP的方式来传递数据；

• Service Mesh：SkyWalking还支持对新一代微服务架构Service Mesh的监控，可以通过特定的Service Mesh协议采集数据面、控制面的数据，实现对服务网格链路数据的观测；

上面的内容简单介绍了SkyWalking的基本情况，并就其系统架构进行了简单分析。实际上SkyWalking最近两年发展得非常快，社区也非常活跃，在微服务链路追踪、应用性能监控领域被使用得也越来越广泛，由于篇幅原因，这里无法进行更深入的分享，感兴趣的读者可以通过官方文档或社区进行深入了解！

SkyWalking安装部署

前面的内容分别介绍了分布式链路追踪的基本原理，并着重介绍了SkyWalking！很显然，写到这里就结束的话，本文就没有啥价值了，因为只是说了一堆正确的废话，看了也就忘了！这显然也不符合我分享的风格，接下来我们就从实验的角度来玩一下SkyWalking。

以下内容需要进行实际实验操作，如果在地铁上不方便可以先收藏，有时间再具体实验玩下！

对于SkyWalking的部署主要涉及到后端OAP Server和前端UI，根据实际需要可以将它们部署在物理机、虚拟机或者Kubernetes集群之中。这里为了演示环境的一致性，我们选择将SkyWalking的后端服务及UI分别部署到Kubernetes集群中。

而具体安装SkyWalking的方式可以通过官方提供的Kubernetes部署文件采用Helm方式安装，也可以手动编写Kubernetes部署文件，这里为了便于学习，我们采用后一种方式。具体步骤如下：

1)、在Kubernetes集群中创建一个单独运行SkyWalking容器的Namespace。命令如下：

#通过kubectl连接Kubernetes集群后执行，创建namespace命令
$ kubectl create ns skywalking

命令执行完成后，可以查看Namespace是否创建成功，命令如下：

#查看namespace创建情况
$ kubectl get ns
NAME                   STATUS   AGE
default                Active   10d
kube-node-lease        Active   10d
kube-public            Active   10d
kube-system            Active   10d
kubernetes-dashboard   Active   10d
skywalking             Active   46s

可以看到此时skywalking空间已经成功创建！

2)、编写SkyWalking-UI及OAP Server服务Kubernetes部署文件

在编写具体的Kubernetes部署文件的过程中需要指定SkyWalking-UI及OAP Server的容器镜像，一般来说可以通过源码手动打包也可以直接使用官方已经打包好的镜像。这里为了方便演示，采用Docker官方镜像仓库中已经打包好的镜像。具体如图所示：

如果上面两张图所示，我们分别在Docker Hub官方镜像仓库中找到了SkyWalking-UI及OAP Server的官方发布的容器镜像版本，接下来编写具体的部署文件。

编写SkyWalking服务端Kubernetes部署文件（skywalking-aop.yml），具体内容如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: oap
  namespace: skywalking
spec:
  replicas: 1
  selector:
    matchLabels:
      app: oap
      release: skywalking
  template:
    metadata:
      labels:
        app: oap
        release: skywalking
    spec:
      containers:
        - name: oap
          #指定OAP Server容器镜像及版本信息
          image: apache/skywalking-oap-server:8.3.0-es7
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 11800
              name: grpc
            - containerPort: 12800
              name: rest
---
apiVersion: v1
kind: Service
metadata:
  name: oap
  namespace: skywalking
  labels:
    service: oap
spec:
  ports:
    #restful端口
    - port: 12800
name: rest
     #rpc端口
    - port: 11800
      name: grpc
    - port: 1234
      name: page
  selector:
    app: oap

以上是一个标准的Kubernetes部署文件，关于文件中相关指令的具体含义可查阅Kubernetes相关的资料。

编写SkyWalking-UI部署文件(skywalking-ui.yml)，具体内容如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ui-deployment
  namespace: skywalking
  labels:
    app: ui
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ui
  template:
    metadata:
      labels:
        app: ui
    spec:
      containers:
        - name: ui
          image: apache/skywalking-ui:8.3.0
          ports:
            - containerPort: 8080
              name: page
          env:
            - name: SW_OAP_ADDRESS
              value: oap:12800
---
apiVersion: v1
kind: Service
metadata:
  name: ui
  namespace: skywalking
  labels:
    service: ui
spec:
  ports:
    - port: 8080
      name: page
      nodePort: 31234
  type: NodePort
  selector:
    app: ui

3)、根据编写的部署文件，执行Kubernetes部署命令

根据前面步骤中编写的Kubernetes发布文件，这里我们根据编写的发布文件直接执行部署命令，具体如下：

#进入发布文件的存储目录，直接一次性执行全部文件部署命令
$ kubectl apply -f .
deployment.apps/oap created
service/oap created
deployment.apps/ui-deployment created
service/ui created

执行完成后通过命令查看具体部署的情况，命令如下：

#查看skywalking空间中的Pod、Service对象的运行情况
$ kubectl get all -n skywalking
NAME                                 READY   STATUS    RESTARTS   AGE
pod/oap-5f6d6bc4f6-k4mvv             1/1     Running   0          36h
pod/ui-deployment-868c66449d-fffrt   1/1     Running   0          36h

NAME          TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                        AGE
service/oap   ClusterIP   10.110.112.244           12800/TCP,11800/TCP,1234/TCP   36h
service/ui    NodePort    10.100.154.93            8080:31234/TCP                 36h

NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/oap             1/1     1            1           36h
deployment.apps/ui-deployment   1/1     1            1           36h

NAME                                       DESIRED   CURRENT   READY   AGE
replicaset.apps/oap-5f6d6bc4f6             1         1         1       36h
replicaset.apps/ui-deployment-868c66449d   1         1         1       36h

可以看到部署的SkyWalking服务都已经正常运行!如果是第一次部署，拉取镜像的过程可能会比较慢一点。如果在部署过程中存在问题，也可以查看Pod对象的运行日志，例如：

#可以查看aop的启动日志
$ kubectl logs pod/oap-5f6d6bc4f6-k4mvv -n skywalking

4)、查看SkyWalking-UI的Web访问地址

经过上述步骤，我们已经成功将SkyWalking-UI、OAP Server两个服务运行在Kubernetes集群之中。接下来通过SkyWalking-UI服务的映射端口（k8s部署文件中定义是31234端口）访问Web UI，具体可通过http://NodeIP:31234进行访问，例如：

#这里的IP为Kubernetes集群向外暴露的节点入口IP
http://10.211.55.12:31234/ 

如果不知道Kubernetes集群节点入口IP地址，可以通过以下命令进行查看：

#查询SkyWalking-UI所部署的Kubernetes集群Node节点的IP地址
$ kubectl describe node kubernetes
Name:               kubernetes
Roles:              master
...
Addresses:
  InternalIP:  10.211.55.12
  Hostname:    kubernetes
...

访问后的界面显示效果如下图所示：

如上图所示，此时可以看到SkyWalking已成功运行，由于尚无服务接入所以暂时还看不到有任何监控数据！

后记

如前面所述内容我们已经在Kubernetes环境中将分布式链路追踪系统部署成功了，如果在实验过程中没有K8s环境的话，可以参考本专栏相关文章，哪里我介绍了多种方式来安装部署Kubernetes。

另外由于还没有服务接入所以暂时还看不到任何链路追踪数据，但是由于篇幅的原因这里就不继续介绍如何将Java微服务接入SkyWalking了，但是这个这个接入过程却是非常有意思的，因为它是我们作为研发人员，进一步理解微服务程序与分布式链路追踪系统集成、交互的关键！这部分我将作为续集在下一篇文章中给大家分享，时间不会太久，期待大家保持关注！

—————END—————

参考文档：

https://skywalking.apache.org/zh/2019-08-30-how-to-use-skywalking-agent/