白话链路追踪基础技术

2020-12-13 本文已影响0人大强斌

1 要解决的目标及理论模型

1.1 背景

互联网电商行业，一次用户的购买，涉及背后的系统很多，如果出现问题，我应该怎样快速定位是那个系统环节出现问题？A系统，B系统，C系统，巨量的体系下面，每秒成千上万的流量，那都是钱A! 老板允许你交易失败一分钟？这就是链路追踪要解决得问题。如何解决？如何统计每个环节消耗的时间？最简单的就是从入口仍一个标识进去，每经过一个环节，建立子环节和整条链路的关系，并打印代码执行的时间，输出到日志中，最后通过数据汇总，分析，完成关系运算，输出到界面中，可以吗？ok？yes，对就那简单。这就是一个思路。elk实现方案，就是这样搞的？elk不懂得自己百度。还有没有其他方案？除了能监控关键方法层面，代码层面有没有？代码层面的监控，能提供直接可靠的问题定位机制，能快速发现问题。有 metrics 技术，可以参考 https://www.jianshu.com/p/effe8e259d25，就不依依解释了。

1.2 我们要监测什么东西?

技术体系的变更引起了监测对象的变化，不同的技术监测对象要求有不同的方案，apm技术也在发展，以前中间件的监控，就能满足体系要求，随着微服务技术发展，apm框架技术也在升级迭代。下面就从最原的基础理论谈起。

1.2.1

业务跟踪监测原理

我们如何知道一条链路经过的各个节点？这就是业务监控。那我门采用什么数据结构? 比如一次访问要经过 A,B,C 三个节点，他们之间可能是并行的，也可能是串行的。访问一个节点的时候，他的上级是什么?所以会引入parent的概念。跨线程，怎办?大家都应该有一个统一的上级，这就引入了tracementId的概念.我如何记录当前处理的节点数据，为了解决这个问题就引入了栈的概念。举例如下：访问经过的路径如下

user -> jetty -> A(spring bean) -> B(spring bean)

-> C(spring bean)

那应该怎处理呢？

即线程按顺序调用到jetty,A,B,C，pinpoint会将其依次放入到CallStack中(执行trace.traceBlockBegin())，当方法执行完毕(调用trace.traceBlockEnd())，会从栈中弹出。

此时会产生几个SpanEvent，关于组织其调用关系属性有如下三个：

spanId：标志这个SpanEvent归属于哪个span

deepth：标志调用深度，即入栈时的当前数组下标

sequence：标志调用顺序

而对于例子中的几个SpanEvent其值时什么呢？

根据深度和顺序号，就很容易能够梳理出调用树了。

需要注意一点，上述SpanEvent B和C为什么深度一样？因为B和C是串行的两个方法，B调用完毕，会出栈，C入栈，所以C和B的深度是一样的。这就涉及到了本地线程的技术，存储上下下文变量。

跨系统怎办？简单啊，通过数据传输，那就把上个相关所属于的 segmentId，最后一次访问节点的相关信息传递到下一个进行，做为上级来处理呢。

1.2.2 除了业务监控，我们还需要监控什么？jvm监控，内存监控，垃圾回收监控，cpu监控，线程数量，这些都是对资源的监控。这些可以通过java提供的ManagementFactory 技术实现。

1.2.3 除了这些要监控的对象，我们还要考虑什么问题？

监控数据再业务系统中呈现爆炸性的增长，我们应该怎存储？增加监控系统我们对我门的业务系统性能带来什么冲击？我们的是否每条数据都需要？

这就涉及到采样频率的考虑，能不能根据性能自动调节采样率？elk就提供了自适应采用方案。

1.2.4 怎样实现的问题？

说了那多上面的东西，用java技术我门应该怎实现？监控的对象，包过业务，redis ，数据源，各种中间件，我们应该用怎样的架构组织去实现，最大程度上的抽象，最小的代码的开发？这就是插件技术的引用。链路中间的通信，我们应该用什么协议实现？一方面是应用代码，一方面是监控代码，我们手写代码？侵入到业务逻辑中？NONO,我们一定要做成公共组件，这就是aop思想，那我门在什么时机对代码进行更改？那多需要更改的方法，总不能一个个配置切入点把。这就需要利用 java angent 技术，从虚拟机层面对类进行改写，可以通过https://www.jianshu.com/p/63c328ca208d了解。本质上来说就是对java 字节码就行修改，这些都是字节码技术。因为涉及到底层，难啊！字节码技术各自不同的特点，能有我们程序员直接看懂，面向对象开发的吗?有！技术的进步就是为了提高生产力，让我门当傻瓜把。

那多插件。我们应该怎样组织起来，方面集中管理，如果需要扩展插件，我们应该怎办？这就需要考虑扩展性的问题。这方面skywalking 做的就比pinpont 比较好，我只需要简单配置下我拦截的类，和方法，和要插入的公共业务，通过配置就可以实现，其他的你别跟我谈什么agent 技术，什么字节码修改，你的体系api ，我通通不需要知道？怎实现的？

2 目前市面的技术体系

我们一切从头开始制造轮子?你扯蛋呢？巨人也是站在巨人的肩膀上，才能看的更远。市面上有 Zipkin Pinpoint SkyWalking CAT Jaeger appdash 我们应该怎样选型? 下面就进行回答这个问题

3技术选型

每个技术的演变都是有其背景和应用的领域.

1 Zipkin 是 Spring Cloud 指定的默认性能监控工具，

2 Jaeger 纳入云原生计算基金会（CNCF）的孵化项目主要为k8s 服务的基于go语言的.

3 Pinpoint 是韩国搞的.

4skywalking 是国人搞的，已经进入了Apache 基金会，目前国内比较火。国内强烈建议这个，由于应用了byptebuddy字节码技术，面向对象思维编程模型，性能也不错，最终导致傻瓜式开发。配置配置完事了。和pinpoint 相比不需要了解底层api 开发效率和易用性都非常高。

5探针性能影响

比较关注探针的性能，毕竟APM定位还是工具，如果启用了链路监控组建后，直接导致吞吐量降低过半，那也是不能接受的。对skywalking、zipkin、pinpoint进行了压测，并与基线（未使用探针）的情况进行了对比。

选用了一个常见的基于Spring的应用程序，他包含Spring Boot, Spring MVC，redis客户端，mysql。监控这个应用程序，每个trace，探针会抓取5个span(1 Tomcat, 1 SpringMVC, 2 Jedis, 1 Mysql)。这边基本和skywalkingtest的测试应用差不多。

模拟了三种并发用户：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%之内。

6 collector的可扩展性

skywalking 有集群模式，collector 向zookper 注册，进行扩展服务能力。

zipkin 通过mq 方式进行消息订阅，进行服务扩展

pinpoint 也有集群模式，通过zookper 提供在agent 和collector 和collector 和hbase 之间的高可用

7 监控的细粒度 pinpoint>skywalking>zipkin

以上都支持微服务和云生态。下面基于实现原理，支持的语言，支持的组件支持的数据存储，扩展性，多维角度去解析,架构基本一样，实现细节侧重点不同，选型是兼顾目前公司的技术和长远发展，取舍后的结果。