本文轉(zhuǎn)載自微信公眾號「無敵碼農(nóng)」，作者無敵碼農(nóng) 。轉(zhuǎn)載本文請聯(lián)系無敵碼農(nóng)公眾號。

2021年我將調(diào)整好心態(tài)持續(xù)給大家輸出有價值的技術(shù)干貨。在接下來的一段時間我所撰寫的技術(shù)內(nèi)容將偏向于“云原生”技術(shù)相關(guān)的內(nèi)容，主要會涉及Devops、Kubernetes、Service Mesh等內(nèi)容。而之所以偏向于寫這些內(nèi)容，一方面是自己的興趣，另一方面也是最近幾年以Kubernetes為基礎(chǔ)設(shè)施的“云原生”技術(shù)體系已經(jīng)成為主流，作為一名研發(fā)人員如果只專注于業(yè)務(wù)代碼的研發(fā)，而對程序運行的基礎(chǔ)環(huán)境、架構(gòu)體系缺乏足夠的認(rèn)識和了解，也是不利于成長和進(jìn)階的!

當(dāng)然，我也會持續(xù)分享編程技術(shù)相關(guān)的干貨內(nèi)容，例如有用的編程技巧、以及程序語言(如Java并發(fā)編程、I/O、網(wǎng)絡(luò)等)相關(guān)的技術(shù)，但有一點我將盡量減少去寫一些市面上已經(jīng)被寫爛、重復(fù)N次的技術(shù)內(nèi)容、以及各種雞湯文!以免浪費大家時間!

好了，廢話不多說!本篇文章我將給大家介紹“分布式鏈路追蹤”的內(nèi)容，對于目前大部分采用微服務(wù)架構(gòu)的公司來說，分布式鏈路追蹤都是必備的，無論它是傳統(tǒng)微服務(wù)體系亦或是新一代Service Mesh的微服務(wù)架構(gòu)!而具體介紹的內(nèi)容，本文不是完全講理論，而是希望從理論到實踐，引導(dǎo)大家去操作，因為只有這樣才能真正從技術(shù)層面有深刻的認(rèn)識和了解!

分布式鏈路追蹤概述

在具體介紹分布式鏈路追蹤系統(tǒng)之前，我們首先需要理解下什么是鏈路追蹤?在本專欄前面關(guān)于監(jiān)控系統(tǒng)的介紹中可以知道，監(jiān)控系統(tǒng)的觀測數(shù)據(jù)主要來源于統(tǒng)計指標(biāo)、日志以及鏈路追蹤這三個方面。而這些數(shù)據(jù)從類型上又可以劃分為兩種：請求級別、聚合級別。

請求級別的數(shù)據(jù)主要來源于真實的請求，例如一次HTTP調(diào)用、RPC調(diào)用等，本文要介紹的鏈路追蹤就是這種類型。而聚合級別則是接口請求的度量指標(biāo)或者一些參數(shù)數(shù)據(jù)的聚合，如QPS、CPU使用率等數(shù)值。日志和統(tǒng)計指標(biāo)數(shù)據(jù)既可以是請求級別，也可以是聚合級別，因為它們可能來自源于真實的請求，也可能是系統(tǒng)自身診斷時記錄下來的信息。

而對于鏈路追蹤來說，它主要的邏輯就是將請求鏈路的完整行為記錄下來，以便可以通過可視化的形式實現(xiàn)鏈路查詢、性能分析、依賴關(guān)系、拓?fù)鋱D等分布式鏈路追蹤相關(guān)的功能。如下圖所示：

在上圖中假設(shè)微服務(wù)系統(tǒng)中的一次接口調(diào)用總共有兩個微服務(wù)參與，其調(diào)用關(guān)系分別是A->B->C，其中B服務(wù)還與Redis這樣的第三方服務(wù)產(chǎn)生了調(diào)用關(guān)系、C服務(wù)則還需要調(diào)用MySQL數(shù)據(jù)庫服務(wù)。所以實際上鏈路追蹤所做的事情就是詳細(xì)記錄A->B(B->Redis)->C(C->MySQL)這條完整鏈路上的詳細(xì)調(diào)用信息，例如接口響應(yīng)結(jié)果、耗時等。

那么這條調(diào)用鏈路上的數(shù)據(jù)到底是怎樣被記錄的呢?接下來我們繼續(xù)以上面的調(diào)用鏈為例分析下鏈路追蹤信息的具體組成和傳遞形式，以便進(jìn)一步理解分布式鏈路追蹤系統(tǒng)的原理和概念。具體邏輯示意圖如下：

如上圖所示，分布式鏈路追蹤所監(jiān)控的對象就是一次次調(diào)用所產(chǎn)生的鏈路，圖中1-8所示的就是一條完整的鏈路(Trace)，系統(tǒng)會通過唯一的標(biāo)識(TraceId)對此進(jìn)行記錄。而鏈路中的每一個依賴調(diào)用都會生成一個調(diào)用蹤跡信息(Span)，最開始生成的Span叫做根Span(Root Span)，后續(xù)生成的Span都會將前一個Span 的標(biāo)示(Sid)作為本Span信息的父ID(Pid)。

這樣以此類推，Span信息就會隨著鏈路的執(zhí)行被進(jìn)程內(nèi)或跨進(jìn)程進(jìn)行上下文傳遞，通過Span數(shù)據(jù)鏈就能將一次次鏈路調(diào)用所產(chǎn)生的蹤跡信息串聯(lián)起來，而每一個Span之上附著的日志信息(Annotation)就是我們進(jìn)行調(diào)用鏈監(jiān)控分析的數(shù)據(jù)來源。這就是分布式鏈路追蹤的基本原理。

而說到這里，你可能會有疑問：監(jiān)控這么大的數(shù)據(jù)量，是不是會很消耗系統(tǒng)資源?的確如此，所以大部分鏈路追蹤系統(tǒng)，都會存在一個叫做采樣率(Sampling)的設(shè)定，用來控制系統(tǒng)采集鏈路信息的比例，從而提升系統(tǒng)性能。因為很多時候，大量的鏈路信息都是相同的，我們需要關(guān)注的可能也只是相對耗時較高、出錯次數(shù)較多的鏈路，而并沒有必要100%的進(jìn)行采集。

SkyWalking簡介

前面我們從基本原理的角度說明了鏈路追蹤是什么，那么接下來我們將介紹下目前最流行的分布式鏈路追蹤系統(tǒng)——SkyWalking。

SkyWalking是一款優(yōu)秀的開源APM(Application Performance Management)系統(tǒng)，它不僅提供了鏈路追蹤，鏈路分析等分布式追蹤功能，還支持性能指標(biāo)分析、應(yīng)用和服務(wù)依賴性分析、服務(wù)拓?fù)鋱D分析、報警等一系列應(yīng)用性能監(jiān)控相關(guān)的功能，可以幫助我們有效地定位問題。

而從數(shù)據(jù)收集上看，SkyWalking支持多種不同的數(shù)據(jù)來源及格式，包括支持Java、.NET Core、NodeJS、PHP和Python等不同語言的無侵入式Agent探針，以及對Service Mesh(服務(wù)網(wǎng)格)架構(gòu)的支持等。其具體結(jié)構(gòu)如下圖所示：

如上圖所示，SkyWalking的核心由鏈路收集服務(wù)器(Receiver Cluster)、聚合服務(wù)器(AggregatorCluster)組成。其中Receiver Cluster是整個后端服務(wù)接入的入口，專門用于收集服務(wù)的各種指標(biāo)及鏈路信息。

而AggregatorCluster則用于匯總、聚合收集器收集到的數(shù)據(jù)，并最終將聚合數(shù)據(jù)存儲到數(shù)據(jù)庫中，而具體存儲方式可以有多種，例如常見的ElasticSearch、MySQL、TIDB等，我們可以根據(jù)實際需要進(jìn)行選擇。這些聚合數(shù)據(jù)后面可以用于告警設(shè)置，也可以被GUI/CLI等可視化系統(tǒng)以HTTP的形式訪問后進(jìn)行可視化展示。

此外，從數(shù)據(jù)采集邏輯上看，SkyWalking支持多種語言探針及項目協(xié)議，能夠覆蓋目前大部分主流的分布式技術(shù)棧，具體來說主要有以下3種：

• Metrics System：統(tǒng)計系統(tǒng)。支持直接從Prometheus中拉取度量指標(biāo)數(shù)據(jù)到SkyWalking，也支持程序自身通過micrometer推送數(shù)據(jù);
• Agents：業(yè)務(wù)探針。指在各個業(yè)務(wù)系統(tǒng)中集成探針服務(wù)來進(jìn)行鏈路追蹤，即鏈路數(shù)據(jù)采集。SkyWalking支持Java、Go、.NET、PHP、NodeJS、Python、Nginx LUA等多種語言的探針。此外，它還支持通過gRPC或者HTTP的方式來傳遞數(shù)據(jù);
• Service Mesh：SkyWalking還支持對新一代微服務(wù)架構(gòu)Service Mesh的監(jiān)控，可以通過特定的Service Mesh協(xié)議采集數(shù)據(jù)面、控制面的數(shù)據(jù)，實現(xiàn)對服務(wù)網(wǎng)格鏈路數(shù)據(jù)的觀測;

上面的內(nèi)容簡單介紹了SkyWalking的基本情況，并就其系統(tǒng)架構(gòu)進(jìn)行了簡單分析。實際上SkyWalking最近兩年發(fā)展得非常快，社區(qū)也非常活躍，在微服務(wù)鏈路追蹤、應(yīng)用性能監(jiān)控領(lǐng)域被使用得也越來越廣泛，由于篇幅原因，這里無法進(jìn)行更深入的分享，感興趣的讀者可以通過官方文檔或社區(qū)進(jìn)行深入了解!

SkyWalking安裝部署

前面的內(nèi)容分別介紹了分布式鏈路追蹤的基本原理，并著重介紹了SkyWalking!很顯然，寫到這里就結(jié)束的話，本文就沒有啥價值了，因為只是說了一堆正確的廢話，看了也就忘了!這顯然也不符合我分享的風(fēng)格，接下來我們就從實驗的角度來玩一下SkyWalking。

以下內(nèi)容需要進(jìn)行實際實驗操作，如果在地鐵上不方便可以先收藏，有時間再具體實驗玩下!

對于SkyWalking的部署主要涉及到后端OAP Server和前端UI，根據(jù)實際需要可以將它們部署在物理機、虛擬機或者Kubernetes集群之中。這里為了演示環(huán)境的一致性，我們選擇將SkyWalking的后端服務(wù)及UI分別部署到Kubernetes集群中。

而具體安裝SkyWalking的方式可以通過官方提供的Kubernetes部署文件采用Helm方式安裝，也可以手動編寫Kubernetes部署文件，這里為了便于學(xué)習(xí)，我們采用后一種方式。具體步驟如下：

1)、在Kubernetes集群中創(chuàng)建一個單獨運行SkyWalking容器的Namespace。命令如下：

#通過kubectl連接Kubernetes集群后執(zhí)行，創(chuàng)建namespace命令 
$ kubectl create ns skywalking 

命令執(zhí)行完成后，可以查看Namespace是否創(chuàng)建成功，命令如下：

#查看namespace創(chuàng)建情況 
$ 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空間已經(jīng)成功創(chuàng)建!

2)、編寫SkyWalking-UI及OAP Server服務(wù)Kubernetes部署文件

在編寫具體的Kubernetes部署文件的過程中需要指定SkyWalking-UI及OAP Server的容器鏡像，一般來說可以通過源碼手動打包也可以直接使用官方已經(jīng)打包好的鏡像。這里為了方便演示，采用Docker官方鏡像倉庫中已經(jīng)打包好的鏡像。具體如圖所示：

如果上面兩張圖所示，我們分別在Docker Hub官方鏡像倉庫中找到了SkyWalking-UI及OAP Server的官方發(fā)布的容器鏡像版本，接下來編寫具體的部署文件。

編寫SkyWalking服務(wù)端Kubernetes部署文件(skywalking-aop.yml)，具體內(nèi)容如下：

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 

以上是一個標(biāo)準(zhǔn)的Kubernetes部署文件，關(guān)于文件中相關(guān)指令的具體含義可查閱Kubernetes相關(guān)的資料。

編寫SkyWalking-UI部署文件(skywalking-ui.yml)，具體內(nèi)容如下：

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)、根據(jù)編寫的部署文件，執(zhí)行Kubernetes部署命令

根據(jù)前面步驟中編寫的Kubernetes發(fā)布文件，這里我們根據(jù)編寫的發(fā)布文件直接執(zhí)行部署命令，具體如下：

#進(jìn)入發(fā)布文件的存儲目錄，直接一次性執(zhí)行全部文件部署命令 
$ kubectl apply -f . 
deployment.apps/oap created 
service/oap created 
deployment.apps/ui-deployment created 
service/ui created 

執(zhí)行完成后通過命令查看具體部署的情況，命令如下：

#查看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   <none>        12800/TCP,11800/TCP,1234/TCP   36h 
service/ui    NodePort    10.100.154.93    <none>        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服務(wù)都已經(jīng)正常運行!如果是第一次部署，拉取鏡像的過程可能會比較慢一點。如果在部署過程中存在問題，也可以查看Pod對象的運行日志，例如：

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

4)、查看SkyWalking-UI的Web訪問地址

經(jīng)過上述步驟，我們已經(jīng)成功將SkyWalking-UI、OAP Server兩個服務(wù)運行在Kubernetes集群之中。接下來通過SkyWalking-UI服務(wù)的映射端口(k8s部署文件中定義是31234端口)訪問Web UI，具體可通過http://NodeIP:31234進(jìn)行訪問，例如：

#這里的IP為Kubernetes集群向外暴露的節(jié)點入口IP 
http://10.211.55.12:31234/  

如果不知道Kubernetes集群節(jié)點入口IP地址，可以通過以下命令進(jìn)行查看：

#查詢SkyWalking-UI所部署的Kubernetes集群Node節(jié)點的IP地址 
$ kubectl describe node kubernetes 
Name:               kubernetes 
Roles:              master 
... 
Addresses: 
  InternalIP:  10.211.55.12 
  Hostname:    kubernetes 
... 

訪問后的界面顯示效果如下圖所示：

如上圖所示，此時可以看到SkyWalking已成功運行，由于尚無服務(wù)接入所以暫時還看不到有任何監(jiān)控數(shù)據(jù)!

后記

如前面所述內(nèi)容我們已經(jīng)在Kubernetes環(huán)境中將分布式鏈路追蹤系統(tǒng)部署成功了，如果在實驗過程中沒有K8s環(huán)境的話，可以參考本專欄相關(guān)文章，哪里我介紹了多種方式來安裝部署Kubernetes。

另外由于還沒有服務(wù)接入所以暫時還看不到任何鏈路追蹤數(shù)據(jù)，但是由于篇幅的原因這里就不繼續(xù)介紹如何將Java微服務(wù)接入SkyWalking了，但是這個這個接入過程卻是非常有意思的，因為它是我們作為研發(fā)人員，進(jìn)一步理解微服務(wù)程序與分布式鏈路追蹤系統(tǒng)集成、交互的關(guān)鍵!這部分我將作為續(xù)集在下一篇文章中給大家分享，時間不會太久，期待大家保持關(guān)注!