分布式链路追踪之Skywalking简单了解

一、什么是APM

    APM (Application Performance Management) 即应用性能管理系统，是对企业系统即时监控以实现对应用程序性能管理和故障管理的系统化的解决方案。应用性能管理，主要指对企业的关键业务应用进行监测、优化，提高企业应用的可靠性和质量，保证用户得到良好的服务，降低IT总拥有成本。APM系统是可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题。

二、单体架构链路追踪

    单体架构中可以使用 AOP 在调用具体的业务逻辑前后分别打印一下时间即可计算出整体的调用时间，使用 AOP 来 catch 住异常也可知道是哪里的调用导致的异常。

 三、分布式链路追踪

     随着分布式系统和微服务架构的出现，一次用户的请求会经过多个系统，不同服务之间的调用关系十分复杂，任何一个系统出错都可能影响整个请求的处理结果。以往的监控系统往往只能知道单个系统的健康状况、一次请求的成功失败，无法快速定位失败的根本原因。

除此之外，复杂的分布式系统也面临这下面这些问题：
    性能分析：一个服务依赖很多服务，被依赖的服务也依赖了其他服务。如果某个接口耗时突然变长了，那未必是直接调用的下游服务慢了，也可能是下游的下游慢了造成的，如何快速定位耗时变长的根本原因呢？
     链路梳理：需求迭代很快，系统之间调用关系变化频繁，靠人工很难梳理清楚系统链路拓扑 (系统之间的调用关系)。为了解决这些问题，Google 推出了一个分布式链路跟踪系统 Dapper ，之后各个互联网公司都参照Dapper 的思想推出了自己的分布式链路跟踪系统，而这些系统就是分布式系统下的APM系统。

四、微服务系统监控三要素

    Logging ： 就是记录系统行为的离散事件，例如，服务在处理某个请求时打印的错误日志，我们可以将这些日志信息记录到 ElasticSearch 或是其他存储中，然后通过 Kibana 或是其他工具来分析这些日志了解服务的行为和状态。大多数情况下，日志记录的数据很分散，并且相互独立，比如错误日志、请求处理过程中关键步骤的日志等等
    Metrics ：是系统在一段时间内某一方面的某个度量，例如，电商系统在一分钟内的请求次数。我们常见的监控系统中记录的数据都属于这个范畴，例如 Promethus、Open-Falcon 等，这些监控系统最终给运维人员展示的是一张张二维的折线图。Metrics 是可以聚合的，例如，为电商系统中每个 HTTP 接口添加一个计数器，计算每个接口的 QPS，之后我们就可以通过简单的加和计算得到系统的总负载情况。
    Tracing ：即我们常说的分布式链路追踪。在微服务架构系统中一个请求会经过很多服务处理，调用链路会非常长，要确定中间哪个服务出现异常是非常麻烦的一件事。通过分布式链路追踪，运维人员就可以构建一个请求的视图，这个视图上展示了一个请求从进入系统开始到返回响应的整个流程。这样，就可以从中了解到所有服务的异常情况、网络调用，以及系统的性能瓶颈等。

五、OpenTracing

    分布式链路跟踪最先由Google在Dapper论文中提出，而OpenTracing通过提供平台无关、厂商无关的API，使得开发人员能够方便的添加（或更换）追踪系统的实现。

Trace

    一个 Trace 代表一个事务、请求或是流程在分布式系统中的执行过程。OpenTracing 中的一条 Trace 被认为是一个由多个 Span 组成的有向无环图（ DAG 图），一个 Span 代表系统中具有开始时间和执行时长的逻辑单元，Span 一般会有一个名称，一条 Trace 中 Span 是首尾连接的。

Span

    Span 代表系统中具有开始时间和执行时长的逻辑单元，Span 之间通过嵌套或者顺序排列建立逻辑因果关系。每个 Span 中可以包含以下的信息：

操作名称：例如访问的具体 RPC 服务，访问的 URL 地址等；
起始时间；2021-1-25 22:00:00
结束时间；2021-1-30 22:00:00
Span Tag

   一组键值对构 成的Span标签集合，其中键必须为字符串类型，值可以是字符串、bool 值或者数字；
Span Log：一组 Span 的日志集合；
SpanContext：Trace 的全局上下文信息；
References：Span 之间的引用关系，下面详细说明 Span 之间的引用关系；
在一个 Trace 中，一个 Span 可以和一个或者多个 Span 间存在因果关系。目前，OpenTracing 定义了 ChildOf 和 FollowsFrom 两种 Span 之间的引用关系。这两种引用类型代表了子节点和父节点间的直接因果关系。

ChildOf 关系：

一个 Span 可能是一个父级 Span 的孩子，即为 ChildOf 关系。下面这些情况会构成 ChildOf 关系：

    一个 HTTP 请求之中，被调用的服务端产生的 Span，与发起调用的客户端产生的 Span，就构成了 ChildOf 关系；
    一个 SQL Insert 操作的 Span，和 ORM 的 save 方法的 Span 构成 ChildOf 关系。
很明显，上述 ChildOf 关系中的父级 Span 都要等待子 Span 的返回，子 Span 的执行时间影响了其所在父级 Span 的执行时间，父级 Span 依赖子 Span 的执行结果。除了串行的任务之外，我们的逻辑中还有很多并行的任务，它们对应的 Span 也是并行的，这种情况下一个父级 Span 可以合并所有子 Span 的执行结果并等待所有并行子 Span 结束。

FollowsFrom 关系：

在分布式系统中，一些上游系统（父节点）不以任何方式依赖下游系统（子节点）的执行结果，例如，上游系统通过消息队列向下游系统发送消息。这种情况下，下游系统对应的子 Span 和上游系统对应的父级 Span 之间是 FollowsFrom 关系。

Logs

每个 Span 可以进行多次 Logs 操作，每一次 Logs 操作，都需要带一个时间戳，以及一个可选的附加信息。

Tags

每个 Span 可以有多个键值对形式的 Tags，Tags 是没有时间戳的，只是为 Span 添加一些简单解释和补充信息。

SpanContext 和 Baggage

SpanContext 表示进程边界，在跨进调用时需要将一些全局信息，例如，TraceId、当前 SpanId 等信息封装到 Baggage 中传递到另一个进程（下游系统）中。

Baggage 是存储在 SpanContext 中的一个键值对集合。它会在一条 Trace 中全局传输，该 Trace 中的所有 Span 都可以获取到其中的信息。

六、分布式链路追踪基本原理

下诉原理都是些帮组简易理解的话语，

    一个完整请求链路的追踪ID（traceid）用于查出本次请求调用的所有服务，每一次服务调用的跨度ID（spanid）用来记录调用顺序

上游服务parenetid用来记录调用的层级关系

调用时间timestamp，把请求发出、接收、处理的时间都记录下来，计算业务处理耗时和网络耗时，然后用可视化界面展示出来每个调用链路，性能，故障

还可以记录一些其他信息，比如发起调用服务名称、被调服务名称、返回结果、IP、调用服务的名称等，最后，我们再把相同spanid的信息合成一个大的span块，就完成了一个完整的调用链。 

七、主流的开源APM产品

PinPoint
Pinpoint是由一个韩国团队实现并开源，针对Java编写的大规模分布式系统设计，通过JavaAgent的机制做字节代码植入，实现加入traceid和获取性能数据的目的，对应用代码零侵入。
官方网站：
https://github.com/naver/pinpoint

Zipkin
Zipkin是由Twitter开源，是分布式链路调用监控系统，聚合各业务系统调用延迟数据，达到链路调用监
控跟踪。Zipkin基于Google的Dapper论文实现，主要完成数据的收集、存储、搜索与界面展示。
官方网站：
https://zipkin.io/

SkyWalking
SkyWalking是apache基金会下面的一个开源APM项目，为微服务架构和云原生架构系统设计。它通过
探针自动收集所需的指标，并进行分布式追踪。通过这些调用链路以及指标，Skywalking APM会感知
应用间关系和服务间关系，并进行相应的指标统计。Skywalking支持链路追踪和监控应用组件基本涵盖
主流框架和容器，如国产RPC Dubbo和motan等，国际化的spring boot，spring cloud。
官方网站：
http://skywalking.apache.org/

CAT
CAT是由大众点评开源的项目，基于Java开发的实时应用监控平台，包括实时应用监控，业务监控，可
以提供十几张报表展示。
官方网站:
https://github.com/dianping/cat

八、SkyWalking 是什么

一个开源的可观测平台，用于从服务和云原生基础设施收集，分析， 聚合及可视化数据。

SkyWalking 提供了一种简便的方式来清晰地观测分布式系统，甚至横跨多个云平台。SkyWalking 更是一个现代化的应用程序性能监控(Application Performance Monitoring)系统，尤其专为云原生、基于容器的分布式系统设计。

官方提供的控制台演示演示地址：http://demo.skywalking.apache.org/ 账号：skywalking 密码：skywalking

1.SkyWalking 核心功能：

• 服务、服务实例、端点指标分析。
• 服务拓扑图分析
• 服务、服务实例和端点（Endpoint）SLA 分析
• 慢查询检测
• 告警

2.SkyWalking 特点：

多语言自动探针，支持 Java、.NET Code 等多种语言。
为多种开源项目提供了插件，为 Tomcat、 HttpClient、Spring、RabbitMQ、MySQL 等常见基础设施和组件提供了自动探针。
微内核 + 插件的架构，存储、集群管理、使用插件集合都可以进行自由选择。
支持告警。
优秀的可视化效果。

3.架构图

4.主要概念

服务(service)：表示对请求提供相同行为的一组工作负载。在使用打点代理或 SDK 的时候，你可以定义服务的名字。SkyWalking 还可以使用在 Istio 等平台中定义的名称。

服务实例(Service Instance)：上述的一组工作负载中的每一个工作负载称为一个实例。就像 Kubernetes 中的 pods 一样，服务实例未必就是操作系统上的一个进程。 但当你在使用打点代理的时候，一个服务实例实际就是操作系统上的一个真实进程。

端点(Endpoint)：对于特定服务所接收的请求路径，如 HTTP 的 URI 路径和 gRPC 服务的类名 + 方法签名。

五.三个核心部分

Agent（探针）

    Agent 运行在各个服务实例中，负责采集服务实例的 Trace 、Metrics 等数据，然后通过 gRPC 方式上报给 SkyWalking 后端。
可观测性分析平台OAP

    SkyWalking 的后端服务，其主要责任有两个。
    一个是负责接收 Agent 上报上来的 Trace、Metrics 等数据，交给 Analysis Core （涉及SkyWalking OAP 中的多个模块）进行流式分析，最终将分析得到的结果写入持久化存储中。SkyWalking 可以使用 ElasticSearch、H2、MySQL 等作为其持久化存储，一般线上使用ElasticSearch 集群作为其后端存储。
    另一个是负责响应 SkyWalking UI 界面发送来的查询请求，将前面持久化的数据查询出来，组成正确的响应结果返回给 UI 界面进行展示。
UI 界面

    SkyWalking 前后端进行分离，该 UI 界面负责将用户的查询操作封装为 GraphQL 请求提交给 OAP 后端触发后续的查询操作，待拿到查询结果之后会在前端负责展示。

六.探针

在 SkyWalking中，探针表示集成到目标系统中的代理或SDK库，它负责收集遥测数据，包括链路追踪和性能指标。根据目标系统的技术栈，探针可能有差异巨大的方式来达到以上功能。但从根本上来说都是一样的，即收集并格式化数据，并发送到后端。

从高层次上来讲，SkyWalking 探针可分为以下三组：

• 基于语言的原生代理 这种类型的代理运行在目标服务的用户空间中，就像用户代码的一部分一样。如SkyWalking Java 代理，使用 -javaagent 命令行参数在运行期间对代码进行操作，操作 一词表示修改并注入用户代码。另一种代理是使用目标库提供的钩子函数或拦截机制。如你所见，这些探针是基于特定的语言和库。
• 服务网格探针 服务网格探针从服务网格的 Sidecar 和控制面板收集数据。在以前，代理只用作整个集群的入口，但是有了服务网格和 Sidecar 之后，我们可以基于此进行观测了。
• 第三方打点类库 SkyWalking 也能够接收其他流行的打点库产生的数据格式。SkyWalking 通过分析数据，将数据格式化成自身的链路和度量数据格式。该功能最初只能接收 Zipkin 的 span 数据。

有如下几种推荐的方式来使用探针：

1. 只使用 基于语言的原生代理
2. 只使用 第三方打点库，如Zipkin 打点系统
3. 只使用 服务网格探针
4. 使用 服务网格探针，配合 语言原生代理 或 第三方打点库，来 追踪状态 。(高级用法)

九、参考文献

Skywalking概述_fFee-ops的博客-CSDN博客_skywalking

分布式链路追踪原理详解及SkyWalking、Zipkin介绍 - 云+社区 - 腾讯云

初识SkyWalking - 知乎