专为云原生、微服务架构而设计的链路追踪工具【SkyWalking介绍及搭建】_微服务链路追踪工具(1)

最新推荐文章于 2024-05-23 14:51:16 发布

2401_84167046

最新推荐文章于 2024-05-23 14:51:16 发布

阅读量955

点赞数 26

分类专栏：程序员文章标签：大数据面试学习

本文链接：https://blog.csdn.net/2401_84167046/article/details/138886277

版权

程序员专栏收录该内容

176 篇文章 0 订阅

订阅专栏

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

前言. 当前企业级分布式微服务集群架构图

服务链路追踪已成为不可或缺的一环
在这里插入图片描述

一. skywalking是什么

skywalking是一个优秀的国产开源框架，2015年由个人吴晟（华为开发者）开源， 2017年加入apache 孵化器。
skywalking是分布式系统的应用程序性能监视工具，专为微服务、云原生架构和基于容器化技术
（docker、K8s、Mesos）架构而设计，它是一款优秀的 APM（Application Performance Management）工具。skywalking是观察性分析平台和应用性能管理系统。提供分布
式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。

二. 为什么需要服务追踪

在微服务架构下，由于进行了服务拆分，一次请求往往需要涉及多个服务，每个服务可能是由不同的团队开发，使用了不同的编程语言，有可能部署在不同的机器上，分布在不同的数据中心。服务跟踪系统可以跟踪记录一次用户请求都发起了哪些调用，经过哪些服务处理，并且记录每一次调用所涉及的服务的详细信息，通过查看完整的调用链路，形成拓补图可以更加直观的了解业务，也可以针对当前的系统进行分析，是否需要扩容、优化接口、失败缓解，还有通过日志快速定位是调用失败的环节。
SkyWalking专门为微服务架构和云原生架构系统而设计并且支持分布式链路追踪的APM系统。
SkyWalking通过加载探针的方式收集应用调用链路信息，并对采集的调用链路信息进行分析，生成应用间关系和服务间关系以及服务指标。Apache SkyWalking (Incubating)目前支持多种语言，其中包括Java，.Net Core ，Node.js和Go语言。
目前skywalking已经支持从6个可视化维度剖析分布式系统的运行情况。
总览视图是应用和组件的全局视图，其中包括组件应用数量，应用的告警波动，慢服务列表以及应用吞吐量；拓扑图从应用依赖关系出发，展现整个应用的拓扑关系；应用视图则是从单个应用的角度，展现应用的上下游关系，TopN的服务和服务器，JVM的相关信息以及对应的主机信息。服务视图关注单个服务入口的运行情况以及此服务的上下游依赖关系，依赖度，帮助用户针对单个服务的优化和监控；调用链展现了调用的单次请求经过的所有埋点以及每个埋点的执行时长；告警视图根据配置阈值针对应用、服务器、服务进行实时告警。

SkyWalking中默认使用的端口有8080、11800、12800，请保证这些端口未被占用。

三链路追踪框架对比

Zipkin是Twitter开源的调用链分析工具，目前基于springcloud sleuth得到了广泛的使用，特点是轻量，使用部署简单。
Pinpoint是韩国人开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能强大，接入端无代码侵入。
SkyWalking是本土开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能较强，接入端无代码侵入。目前已加入Apache孵化器。
CAT是大众点评开源的基于编码和配置的调用链分析，应用监控分析，日志采集，监控报警等一系列的监控平台工具。

在这里插入图片描述

3.1 性能对比

模拟了三种并发用户：500，750，1000。使用jmeter测试，每个线程发送30个请求，设置思考时间为10ms。使用的采样率为1，即 100%，这边与生产可能有差别。pinpoint默认的采样率为20，即50%，通过设置agent的配置文件改为100%。zipkin默认也是1。组合起来，一共有12种。下面看下汇总表：

在这里插入图片描述
从上表可以看出，在三种链路监控组件中，skywalking的探针对吞吐量的影响最小，zipkin的吞吐量居中。pinpoint的探针对吞吐量的影响较为明显，在500并发用户时，测试服务的吞吐量从1385降低到774，影响很大。然后再看下CPU和memory的影响，在内部服务器进行的压测，对CPU和memory的影响都差不多在10%之内。

四. 链路追踪的实际应用预览

4.1 捋清业务

我们都知道，在一般场景下，我们很难直观的了解系统的运行、业务的流程，因为传统的都是文字需求说明和枯燥的代码。通过链路追踪，可以根据调用链路来捋清楚服务间的调用关系，如果 API 设计符合规范，甚至可以直观的了解调用的服务作用。这对于刚刚接触系统的开发人员十分重要。

4.2 分析耗时

链路的基本功能，服务间的调用耗时记录，如果服务耗时过长，会影响整体的用户体验，甚至会抛出超时异常等，这样的情况在微服务架构中也是时有发生。

在这里插入图片描述

4.3 可视化错误

微服务调用链路发生错误，可以直观的显示查看，定位到被调用服务的接口，及时排查微服务中错误原因。

在这里插入图片描述

4.4 优化链路

显示完整的调用链路，根据业务分析合理性、可读性、健壮性，是否重复调用某一个服务，是否链路过长，有没有可以优化的，链路是否清晰。有些场景比较复杂，比如数据中心比较分散，服务分布在不同的数据中心，但是服务中心之间因为地域原因，距离远，延迟高，这可能不符合设计要求，因此就要根据链路来找到最近的数据中心，然后配置调用最近的数据中心的服务。

在这里插入图片描述

4.5 生成网络拓扑

通过服务追踪系统中记录的链路信息，可以生成一张系统的网络调用拓扑图，它可以反映系统都依赖了哪些服务，以及服务之间的调用关系是什么样的，可以一目了然。除此之外，在网络拓扑图上还可以把服务调用的详细信息也标出来，也能起到服务监控的作用。

在这里插入图片描述

4.6 SkyWalking 主要功能特性

多种监控手段，可以通过语言探针和service mesh获得监控的数据；
支持多种语言自动探针，包括 Java，.NET Core 和 Node.JS；
轻量高效，无需大数据平台和大量的服务器资源；
模块化，UI、存储、集群管理都有多种机制可选；
支持告警；
优秀的可视化解决方案；

五. 使用Docker安装部署SkyWalking

5.1 查看官网版本

官网：http://skywalking.apache.org/
下载：http://skywalking.apache.org/downloads/
Github：https://github.com/apache/skywalking/
文档： https://skywalking.apache.org/docs/main/v8.4.0/readme/
中文文档： https://skyapm.github.io/document-cn-translation-of-skywalking/

在这里插入图片描述

从官网可以看出最新版本已经9.0版本了，但是我们使用es作为存储最好是使用明确存储了方式的版本 8.7.0

5.1 拉取镜像

5.1.1 尝鲜版

docker pull elasticsearch:7.12.0 

默认es存储数据镜像 
docker pull apache/skywalking-oap-server:8.7.0-es7 

webUI界面镜像 
docker pull apache/skywalking-ui:8.7.0 

制作微服项目镜像 
docker pull openjdk:8-alpine3.9

5.1.2 稳定版

docker pull elasticsearch:7.9.0 

默认es存储数据镜像 
docker pull apache/skywalking-oap-server:8.1.0-es7 

webUI界面镜像 
docker pull apache/skywalking-ui:8.1.0 

制作微服项目镜像 
docker pull openjdk:8-alpine3.9

5.1.3 备份镜像

最新版：
docker save apache/skywalking-oap-server:8.7.0-es7 apache/skywalking-ui:8.7.0 elasticsearch:7.12.0 -o skywalking8.7.0.tar 

稳定版：
docker save apache/skywalking-oap-server:8.1.0-es7 apache/skywalking-ui:8.1.0 elasticsearch:7.9.1 -o skywalking8.1.0.tar