微服务线上问题排查困难？不知道问题出在哪一环？那是你还不会分布式链路追踪

咱们以前单体应用里面有很多的应用和功能，依赖各个功能之间相互调用，使用公共的代码包等等，排查问题，使用类似于 gdb/dlv 工具或者直接查看代码日志，进行定位和分析

但是现在我们基本上都是微服务架构了，将以前的单体架构拆成了一个个独立的微服务，现在就变成了多个微服务之间的相互调用的关系

在一个业务链条中，中间可能涉及到几个，十几个甚至几十个微服务的交互和配合，如果中间某一环出现了问题，那么我们是很难排查的，排查问题耗时耗力，且效率极其低下

服务数量多，链路复杂，排查困难，大佬们就想出了一个办法，使用分布式链路追踪来处理这个问题

本文分别从以下几个方面来聊聊关于分布式链路追踪的技术知识：

• 什么是分布式链路追踪

• 分布式链路追踪的基础原理

• 目前常用的分布式链路追踪组件

• Jaeger 的基本架构和使用演示

✔什么是分布式链路追踪

分布式链路追踪，见名知意，这是用在分布式系统中，用于追踪服务调用链路的

文章开头有说到，微服务架构中，存在大量的微服务，且维护的团队不尽相同，使用的语言也不太一致

线上部署几百上千台服务器，若链路出现了问题，性能出现了瓶颈，我们如何排查， 如何有效的解决呢？

分布式链路追踪他就可以将一次分布式请求还原成调用链路，将一次分布式请求的调用状况集中展示，且他还提供友好的 UI 界面，咱们直接在页面上就能直观的看到每一个服务的耗时请求到具体哪台服务器上以及服务相应的状态等等👀👀。

在技术上通常使用

• Tracing 表示链路追踪

主要是用于单个请求的处理流程，包括服务调用和服务处理时长等信息

目前分布式上使用的比较多的是 Jaeger

• Logging 日志记录

主要是用来记录离散的日志事件。可以理解为你程序打印出来的一些日志

对于日志记录，我们一般会使用 ELK ，这是 elastic 公司提供的一套解决方案，其中每一个字母代表一个开源组件

E： Elasticsearch

L： Logstash

K：Kibana

• Metrics 数据聚合

用于聚合数据的，通常是有时间顺序的数据

对于数据聚合和统计系统，我们一般使用 Prometheus 普罗米修斯来进行处理

可以看到上述这三个概念是相辅相成的，仅仅只使用一种方式，是没有办法完全满足我们需求的，在实际生产过程中，会将上述进行两两组合来达到我们期望的效果。

👀Tracing 与 Logging 组合

既有链路追踪又有日志

那么我们就可以达到的效果是在我们每一个请求阶段，可以看到详细的标签数据对应的日志数据以及错误原因

<