文章采集调用(追踪调用链路，监控链路性能，排查链路故障(组图))

　　文章采集调用(追踪调用链路，监控链路性能，排查链路故障(组图))

　　后台：跟踪调用链路，监控链路性能，排查链路故障

　　随着微服务架构的普及，一个请求往往需要涉及多个服务，需要一些可以帮助理解系统行为和分析性能问题的工具，以便在发生故障时能够快速定位并解决问题。

　　在单体架构下，可以使用AOP打印调用具体业务逻辑前后的时间，计算整体调用时间。使用 AOP 捕获异常并知道调用在哪里导致了异常。

　　基本实现原理

　　一个完整的请求链路的trace ID（traceid）用来找出这个请求调用的所有服务，每个服务调用的span ID（spanid）用来记录调用顺序

　　上游服务parenetid用于记录调用的层次关系

　　调用时间时间戳，记录请求发送、接收、处理的时间，计算业务处理时间和网络时间，然后用可视化的界面展示每个调用环节、性能、故障

　　还可以记录一些其他的信息，比如调用服务的名字，被调用服务的名字，返回结果，IP，调用服务的名字等等。最后我们把同一个spanid的信息组合成一个大跨度块来完成一个完整的调用链。

　　SkyWalking的原理和架构设计

　　定期采样节点数据，采样后定期上报数据，存储在ES、MySQL等持久层中。有了数据，自然要根据数据进行可视化分析。

　　空中漫步的工作原理

　　Skywalking的工作机制需要三个配合。工作原理图大致如下：

　　SkyWalking核心模块介绍：

　　SkyWalking 采用组件化开发，易于扩展。主要成分如下：

　　1. Skywalking Agent：链接数据采集tracing（调用链数据）和metric（度量）信息并上报，通过HTTP或gRPC将数据发送到Skywalking Collector。

　　2. Skywalking Collector ：链路数据采集器，对agent发送的tracing和metric数据进行整合分析，通过Analysis Core模块进行处理，落入相关数据存储。同时通过Query Core模块进行二次统计。和监控警报

　　3. 存储：Skywalking的存储支持ElasticSearch、Mysql、TiDB、H2等主流存储作为数据存储的存储介质。H2 仅用于单机临时演示。

　　4. SkyWalking UI：用于显示着陆数据的Web可视化平台。目前，RocketBot 被正式采用为 SkyWalking 的主要 UI

　　如何自动 采集 跨越数据

　　SkyWalking采用插件+javaagent的形式实现数据自动跨度采集，可以对代码无侵入，插件意味着可插拔，扩展性好

　　如何跨进程传递上下文

　　我们知道数据一般分为header和body，就像http有header和body一样，RocketMQ也有MessageHeader、Message Body，body一般都保存业务数据，所以不宜在body中传递context，而是在header中，如图

　　dubbo中的attachment相当于header，所以我们把context放在attachment里面，解决了context传输的问题。

　　提示：这里的上下文传递过程由dubbo插件处理，业务不知情

　　traceId 如何保证全局唯一

　　为了确保全局唯一性，我们可以使用分布式或本地生成的 ID。如果你使用分布式，你需要有一个发件人。每次发出请求时，都必须先请求发件人。会有网络调用开销，所以 SkyWalking 最终采用了本地生成 ID 的方法，并且采用了著名的雪流算法，具有很高的性能。

　　但是雪花算法有一个众所周知的问题：时间回溯，会导致产生重复的id。那么 SkyWalking 是如何解决时间回调问题的呢？

　　每次生成id时，都会记录生成id的时间（lastTimestamp）。如果发现当前时间小于上次生成id的时间（lastTimestamp），则表示发生了时间回调，会生成一个随机数作为traceId。

　　有这么多请求，所有 采集 都会影响性能吗？

　　如果每次请求都调用采集，毫无疑问数据量会很大，但是反过来想，真的有必要对每个请求都调用采集吗？实际上，没有必要。我们可以设置采样频率，只对部分数据进行采样。默认情况下，SkyWalking 设置为 3 秒采样 3 次，其余请求不采样，如图

　　这个采样频率其实已经足够我们分析元器件的性能了。以这种在 3 秒内采样 3 次的频率采样数据有什么问题？理想情况下，每次服务调用都是在同一个时间点进行的（如下图），所以每次都在同一个时间点采样真的没问题。

　　但是在生产中，每个服务调用基本不可能在同一时间点被调用，因为期间存在网络调用延迟，实际调用情况很可能如下图所示。

　　在这种情况下，会在服务 A 上采样一些调用，而不会在服务 B 和 C 上采样，因此无法分析调用链的性能，那么 SkyWalking 是如何解决的。

　　是这样解决的：如果上游携带Context（表示上游已经采样），下游强制采集数据。这确保了链接是完整的。

　　SkyWalking各模块组件视图介绍

　　Skywalking 已经支持从 6 个视觉维度分析分布式系统的运行。

　　1、Dashboard：查看全球服务的基本性能指标

　　Dashboard主要包括Service Dashboard和Database Dashboard

　　2、拓扑图：展示分布式服务之间的调用关系：

　　SkyWalking 可以根据获取的数据自动绘制服务之间的调用关系图，并且可以识别出常用的服务并显示在图标上，比如图上的tomcat、CAS服务

　　每个连接的颜色反映了服务之间的调用延迟，可以非常直观的看到服务之间的调用状态。点击连接中间的点可以显示两个服务之间的连接的平均值。响应时间、吞吐量和 SLA 等信息

　　显示服务的性能数据：

　　选择其中一项服务，查看调用关系及服务基本状态。

　　拓扑图也有平面显示效果

　　3、链接跟踪：可以根据需要查看链接调用过程

　　显示请求响应的内部执行，一个完整的请求经过了哪些服务，执行了哪些代码方法，每个方法的执行时间，执行状态等详细信息，快速定位代码问题。

　　失败的调用还有一个错误日志：

　　4、警报：5、Zipkin 原理与指标数据对比

　　Zipkin 分为两端，Zipkin 服务器和 Zipkin 客户端。客户端是微服务的应用。客户端配置服务器的 URL 地址。一旦服务之间发生调用，就会被微服务中配置的Sleuth*敏*感*词*器*敏*感*词*，并生成相应的Trace和Span信息发送给服务器。发送方式主要有两种，一种是HTTP消息的方式，一种是RabbitMQ等消息总线的方式。

　　无论哪种方式，我们都需要：一个 Eureka 服务注册中心，首先看一下 Zipkin 运行架构：

　　左边的应用服务也是Zipkin-clinet和Eureka-client。中间是依赖，包括 Zipkin-server 和 Eureka-server。最右边是WebUI展示和开发界面。

　　比较计划

　　Google的Dapper，阿里的鹰眼，大众点评的CAT，Twitter的Zipkin，LINE的pinpoint，国内的skywalking。

　　市面上的全链路监控理论模型多以Google Dapper论文为基础。本文重点介绍以下三个 APM 组件：

　　种类

　　拉链金

　　空中漫步

　　基本的