提升篇：通过链路追踪优化慢请求

作者：老马

公众号：老马啸西风

博客：https://houbb.github.io/

人生理念：知行合一

分布式时代，原来的单体应用被拆分为若干的微服务，各个子系统负责聚类业务的垂直化深度建设，职责单一，既保证了系统的性能也方便未来扩展。

但是，任何事情有利就有弊

我们经常也会有苦恼的时候，比如下面这些问题：
1、客户端一次请求，内部要跨越十几个子系统，如果出现慢响应，如何快速定位卡在哪个环节？
2、老板安排任务，优化一下系统性能，如何展开工作？
3、线上部署太多系统，日志打印在不同机器磁盘，排查问题时需要根据关键信息（如：订单id）去不同的服务器上搜索，非常痛苦
4、某个核心服务（如：下单接口）在高峰期时出现少量的慢请求，有用户向客服投诉在APP下单时出现等待时间比较长，但是 APP 下单接口会调用多个 RPC 服务或者使用多个资源，有些接口是其他团队负责的，一时间不知道如何下手

当你遇到这些问题，你会如何处理？

一个简单的思路就是 打日志，将问题接口的每一步耗时情况以及异常日志全部打印出来，然后人肉收集这些日志数据并分析，找到需要优化的环节

代码类似这样：

确实挺方便，但我们可能会遇到这样问题，如果有多个请求并行处理，这样多个请求日志会穿插在一起，这时我们需要用关键字 搜索来筛选出一个请求的日志，这个关键字要求具有唯一性 ，比如采用 UUID 生成。

大致实现思路：

1、在流量的入口处，生成这么一个 requestID ，然后放到线程上下文中
2、这样执行到后面的方法，就可以从上下文取到这个 requestID
3、然后，在各个关键环节将 requestID 和 耗时 等信息打印到日志
4、最后，通过requestID 就可以了解一个链路上的耗时情况