如何玩分布式链接跟踪？转载请联系无敌码农公众号。2021年我会调整好心态，继续为大家输出有价值的技术干货。在接下来的一段时间里，我写的技术内容会偏向“云原生”技术相关的内容，主要涉及DevOps、Kubernetes、ServiceMesh等内容。之所以比较喜欢写这些内容，一方面是出于自己的兴趣，另一方面基于Kubernetes的“云原生”技术体系已经成为近年来的主流。作为研究人员，如果只关注业务代码，对程序运行的基础环境和架构体系缺乏足够的认识和了解，不利于成长和进步！当然，我会继续分享编程技术相关的干货内容，比如实用的编程技巧，编程语言（如Java并发编程、I/O、网络等）相关技术，但有一件事我会尝试减少写一些市面上写的不好重复N遍的技术内容，还有各种鸡汤文！浪费大家的时间！好了，不废话了！在本文中，我将介绍“分布式链接跟踪”的内容。对于目前大部分采用微服务架构的公司来说，分布式链路追踪是很有必要的，无论是传统的微服务体系，还是新一代的ServiceMesh微服务架构！至于具体的内容，本文并没有完全讲理论，而是希望能指导大家从理论到实践的操作，因为只有这样才能真正从技术层面上有深刻的理解和理解！分布式链路跟踪概述在详细介绍分布式链路跟踪系统之前，我们首先需要了解什么是链路跟踪？本专栏前面的监控系统介绍由上可知，监控系统的观测数据主要来自三个方面：统计指标、日志和链路跟踪。这些数据可以分为两种类型：请求级别和聚合级别。请求级别的数据主要来自真实的请求，比如HTTP调用、RPC调用等，本文要介绍的链接跟踪就是此类。聚合等级是接口请求的衡量指标或者一些参数数据的聚合，比如QPS、CPU占用率等值。日志和统计指标数据既可以是请求级别的，也可以是聚合级别的，因为它们可能来自真实的请求，也可能是系统自身诊断时记录的信息。对于链路跟踪，其主要逻辑是记录所请求链路的完整行为，从而以可视化的形式实现链路查询、性能分析、依赖关系、拓扑图等分布式链路跟踪相关任务。功能。如下图所示：上图中，假设微服务系统中有两个微服务参与到一个接口调用中，调用关系为A->B->C，同时也连接了B服务使用第三方服务，例如Redis。调用关系生成，C服务还需要调用MySQL数据库服务。所以其实linktracking做的就是记录完整链路A->B(B->Redis)->C(C->MySQL)上的详细调用信息，比如接口响应结果，耗时等待等。那么这个调用链接上的数据是怎么记录的呢？下面继续以上述调用链路为例，分析链路跟踪信息的具体构成和传输形式，以进一步了解分布式链路跟踪系统。原则和概念。具体逻辑图如下：如上图所示，分布式链路跟踪监控的对象是一个接一个调用产生的链路。图中1-8是一个完整的链接（Trace），系统会通过一个唯一标识（TraceId）记录这个。链接中的每个依赖调用都会生成一个调用跟踪信息（Span）。最初生成的Span称为根Span（RootSpan），后续生成的Span会使用前一个Span的标签（Sid）作为Span信息。父ID(Pid)。以此类推，Span信息会随着链接的执行在进程内或跨进程进行上下文传递，而每个链接调用产生的trace信息可以通过Span数据链接串联起来，每个Span所附的日志信息（Annotation）是我们调用链监控分析的数据来源。这就是分布式链路跟踪的基本原理。说到这里，你可能会有疑问：监控这么大的数据量会不会消耗系统资源？事实上，大多数链接跟踪系统都会有一个设置，称为采样率（Sampling）。用于控制系统收集链路信息的比例，从而提高系统性能。因为在很多情况下，大量的链接信息是相同的，我们可能只需要关注那些相对耗时和错误较多的链接，并不需要100%的去收集。SkyWalking简介前面我们从基本原理的角度解释了什么是链接跟踪，接下来我们将介绍最流行的分布式链接跟踪系统——SkyWalking。SkyWalking是一个优秀的开源APM（ApplicationPerformanceManagement）系统。它不仅提供了链路跟踪、链路分析等分布式跟踪功能，还支持性能指标分析、应用与服务依赖分析、服务拓扑分析、告警等一系列与应用性能监控相关的功能，可以有效帮助我们定位问题。从数据采集的角度来看，SkyWalking支持多种不同的数据源和格式，包括支持Java、.NETCore、NodeJS、PHP、Python等不同语言的非侵入式Agent探针，以及服务网格（servicemesh))框架支持等。其具体结构如下图所示：如上图所示，SkyWalking的核心由链路采集服务器（ReceiverCluster）和聚合服务器（AggregatorCluster）组成。其中ReceiverCluster是整个后端服务接入的入口，专门用来收集服务的各种指标和链接信息。AggregatorCluster用于对采集器采集到的数据进行汇总聚合，最终将聚合后的数据存储到数据库中，具体的存储方式有很多，比如常见的ElasticSearch、MySQL、TIDB等，大家可以根据实际需要.选择。这些聚合后的数据可以用于后续的告警设置，也可以通过GUI/CLI等可视化系统以HTTP的形式进行访问，进行可视化展示。此外，从数据采集逻辑来看，SkyWalking支持多语言探针和项目协议，可以覆盖目前大部分主流的分布式技术栈。具体来说，主要有以下三种：MetricsSystem：统计系统。支持直接从Prometheus拉取metric数据到SkyWalking，也支持程序本身通过micrometer推送数据；代理人：业务调查。指在各个业务系统中集成探测服务，进行链路跟踪，即链路数据采集。SkyWalking支持Java、Go、.NET、PHP、NodeJS、Python、NginxLUA等多种语言的探针。此外，它还支持通过gRPC或HTTP传输数据；ServiceMesh：SkyWalking还支持新一代微服务架构ServiceMesh的监控，可以通过特定的ServiceMesh协议采集数据平面和控制平面的数据，实现对服务网格链路数据的观察；以上内容简要介绍了SkyWalking的基本情况，并对其系统架构进行了简单的分析。其实SkyWalking这两年发展非常快，社区也很活跃。在微服务链路跟踪、应用性能监控等领域应用越来越广泛。由于篇幅原因，这里无法更深入的分享。有兴趣的读者可以通过官方文档或社区深入了解！SkyWalking安装部署前的内容介绍了分布式链路跟踪的基本原理，重点介绍SkyWalking！显然，如果写到这里就结束了，这篇文章没有什么值得的，因为我只是说了一堆正确的废话，看完就忘了！这显然不符合我分享的风格，那我们就从实验的角度来玩一下SkyWalking吧。以下内容需要实际实验操作。如果在地铁上不方便，可以先存起来，有空再玩具体的实验！SkyWalking的部署主要涉及后端OAPServer和前端UI，可根据实际需要部署在物理平台上。机、虚拟机或Kubernetes集群。这里为了演示环境的一致性，我们选择将SkyWalking后端服务和UI分别部署到Kubernetes集群中。具体安装SkyWalking的方式可以使用Helm通过Kubernetes官方部署文件进行安装，也可以手动编写Kubernetes部署文件。这里，为了学习方便，我们采用后一种方法。具体步骤如下：1).在Kubernetes集群中创建一个单独运行SkyWalking容器的Namespace。命令如下：#通过kubectl连接到Kubernetes集群后执行，创建命名空间命令$kubectlcreatensskywalking命令执行完成后可以查看Namespace是否创建成功。看到天行空间此时已经创建成功！2)、编写SkyWalking-UI和OAPServer服务Kubernetes部署文件。在编写具体的Kubernetes部署文件的过程中，需要指定SkyWalking-UI和OAPServer的容器镜像。一般来说，可以通过源码手动打包，也可以直接使用官方打包好的镜像。为了演示方便，使用Docker官方镜像仓库已经打包好的镜像。具体如图：如上两图所示，我们在DockerHub官方镜像仓库中找到了SkyWalking-UI和OAPServer的官方容器镜像版本，然后编写了具体的部署文件。编写SkyWalking服务器Kubernetes部署文件（skywalking-aop.yml），具体内容如下：apiVersion:apps/v1kind:Deploymentmetadata:name:oapnamespace:skywalkingspec:replicas:1selector:matchLabels:app:oaprelease:skywalkingtemplate:metadata：labels:app:oaprelease:skywalkingspec:containers:-name:oap#指定OAPServer容器镜像和版本信息image:apache/skywalking-oap-server:8.3.0-es7imagePullPolicy:IfNotPresentports:-containerPort:11800name:grpc-containerPort:12800name:rest---apiVersion:v1kind:Servicemetadata:name:oapnamespace:skywalkinglabels:service:oapspec:ports:#restfulport-port:12800name:rest#rpcport-port:11800name:grpc-port:1234name:pageselector:app:oap以上是一个标准的Kubernetes部署文件。文件中相关说明的具体含义可以参考Kubernetes的相关资料。编写SkyWalking-UI部署文件（skywalking-ui.yml），具体内容如下：apiVersion:apps/v1kind:Deploymentmetadata:name:ui-deploymentnamespace:skywalkinglabels:app:uispec:replicas:1selector:matchLabels:app:uitemplate:metadata:labels:app:uispec:containers:-name:uiimage:apache/skywalking-ui:8.3.0ports:-containerPort:8080name:pageenv:-name:SW_OAP_ADDRESSvalue:oap:12800---apiVersion:v1kind:Servicemetadata:name:uinamespace:skywalkinglabels:service:uispec:ports:-port:8080name:pagenodePort:31234type:NodePortselector:app:ui3),根据编写的部署文件，根据编写的Kubernetesrelease文件执行Kubernetes部署命令前面的步骤，这里我们按照发布文件直接执行部署命令来写，如下：#进入发布文件的存放目录，直接一次性执行所有文件部署命令$kubectlapply-f.deployment。应用程序/oapcreatedservice/oapcreateddeployment.apps/ui-deploymentcreatedservice/uicreated执行完成后，通过命令查看具体部署情况，命令如下：#查看skywalking空间中Pod和Service对象的运行状态$kubectlgetall-nskywalkingNAMEREADYSTATUSRESTARTSAGEpod/oap-5f6d6bc4f6-k4mvv1/1Running036hpod/ui-deployment-868c66449d-ffffrt1/1Running036hNAMEIPYPECLUSTER(RNATYPECLUSTERS)AGEservice/oapClusterIP10.110.112.244
