分布式追踪系统的设计与实践1

原创魏新宇大魏分享

微服务的现状：

在微服务体系中，一般不会同级调度，但交叉调用还是挺多的。

我们要解决上述的问题，比较好的方法是构建分布式请求追踪系统。

目前这类系统的实现有很多方案，开源的有：

在SpringCloud Netflix和Istio中，Zipkin被广泛使用。

分布式追踪系统应该能做到便于使用，即通过引入一个jar包，就可以做分布式请求追踪。跟踪三方面内容:

上面三个目标怎么实现？通过日志的方式来收集上面的信息，日志谁来写？jar包。日志会贯穿多个层面，日志的ID叫trace ID，traceID由网关层生成。

基于日志的分布式追踪系统的好处是：

业务侵入小

将每个系统分散的日志聚合起来，并进行海量日志分析，从而生成有价值的数据。

关于调用链：每次请求都生成一个全局唯一的ID（TraceID），通过它将不同的系统生成的日志串在一起，重组成调用链，时期价值达到1+1>2的效果。开发人员通过分布式追踪系统请求跟踪链拍橙V查问题。可以对多个请求进行统计和分析。

分布式追踪系统的几个场景：

1.调用链跟踪：一次请求调用过程的展示，以图形化方式输出各个微服务端集群之间的调用关系，并记录整个过程的消耗时间，协助发发人员分析整个系统的瓶颈点与热点、从而优化系统。

2.调用链路径分析：对多条调用链进行分析，整理成集群之间的调用关系，计算出整个链路的关键节点，直接依赖，间接依赖，依赖强度等。

3.调用来源分析：针对某一特定的集群，整理出其他集群对其的调用情况，防止错误调用的发生。

4.调用量统计：实时统计各个集群的调用次数、QPS、平均耗时、最大耗时等信息，开发人员可以根据相关的信息进行容量规划。

5.监控请求调用量：开发人员通过自动以正则表达式、对匹配该正则的URL的请求进行实时监控，包括调用次数、QPS、平均耗时、最大耗时、最小耗时。

根据以上的需求，分布式追踪系统的设计图如下：

上图中，java探针就是对应用做了一个切面的拦截。在请求开始和结束位置都注入代码。日志的上报，是个UDP的请求。有一个点需要考虑，业务逻辑层调用数据访问层，可能有多个数据访问层，怎么记录它的时序呢？怎么完成的把调用时序还原呢？

为了保证日志的时序，需要使用三个标识：

关于几种开源分布式追踪系统的对比，可以参照下文：

https://www.jianshu.com/p/0fbbf99a236e

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

Skywalking和PinPoint各有优劣势，不过从我看到国内的使用案例，SkyWalking更多一些。我们查看两者以及Zipkin在github的评星：

Skywalking是最高的：

继续滑动看下一个