全链路日志

上文介绍了服务的注册发现，这里就来谈谈所有微服务都会遇到的一个问题——全链路日志。

为了便于理解下面的内容，同样先从一个真实的业务场景入手。

 业务场景：这个请求到底经历了什么

当时公司的某一个业务线本来是基于自研的微服务架构，刚刚迁移到Spring Cloud。

因为公司原来的微服务架构是基于ZooKeeper做注册发现的，为了复用原来的中间件，迁移到Spring Cloud后，服务的注册发现基于SpringCloud ZooKeeper实现，不过组件方面只使用了Spring Cloud的服务间调用（Feign）。

迁移到微服务后，就得考虑日志跟踪的事情了。

之 前 只 是 简 单 地 把 日 志 打 印 到 本 地 文 件 上 ， 然 后 使 用ELK（ElasticSearch、Logstash和Kibana）进行日志收集和分析，因此日志记录比较随意，且没有形成一个统一的规范。

因为没有统一的规范，在做线上问卷调查的时候，难度非常大。

比如有一次碰到了某一个用户总是登录失败的问题。服务调用链路是这样的：

UserAPI→AuthService→UserService

在UserAPI中还能找到登录信息，因为日志里面打印出了用户名，而后根据相应的时间点可以找到线程ID，那么这个时间点的这个线程ID下所有的日志就都属于要跟踪的活动了。

但是要去AuthService查找这个请求的下一个服务的日志时就复杂了。因为同一时间点有多个服务器节点，每个节点有多个线程ID在活动，所以无法判断哪个服务器节点的哪个线程ID是用来处理UserAPI中在调查的那次请求的。

那怎么办？等没流量的时候运维人员又重试了几次，最终才定位到AuthSer vice中相应的日志。后来调查到的问题根源是，UserAPI调用AuthService的时候，有个参数因为含有特殊字符而被Tomcat自动摒弃了，导致AuthService收不到那个参数的值。项目组商量后，决定把日志进一步规范化，于是总结了以下3点需求。

1）记录什么时候调用了缓存、MQ、ES等中间件，在哪个类的哪个方法中耗时多久。

2）记录什么时候调用了数据库，执行了什么SQL语句，耗时多久。

3）记录什么时候调用了另一个服务，服务名是什么，方法名是什么，耗时多久。

一般来说，一个请求会跨多个服务节点，针对这种情况又梳理了两条重要需求。

1）把同一个请求在全部服务中的以上所有记录进行串联，最终实现一个树状的记录。

2）设计一个基于这些基础数据的查询统计功能。

通过以上需求梳理并规范日志后，就可以在一个页面上看到每个请求的树状结构日志了，结果可参考图9-1。

• 图9-1 请求全链路日志树状结构示意图

通过这样的设计，如果后期线上环境出现问题需要进一步调查，就有了更多的依据。

需求确定后，就需要选择一款合适的开源技术进行方案实现，这就涉及技术选型过程。

本文给大家讲解的内容是全链路日志：业务场景：这个请求到底经历了什么