SpringCloud：微服务下的链路追踪讲解重要性及组件Sleuth实战以及常见问题（十五）

什么是分布式链路追踪系统，及使用好处？

微服务调用链路特别长，比如用户请求订单服务，订单服务可能会掉商品服务-用户服务-积分服务等等
等有一天发现这个订单服务返回的特别慢，但不知道具体是调用哪一个服务时间过长

一开始的解决方法可能会在代码里加begin起始时间和end结束时间，最后相减得到服务调用时间，但服务越来越多，不能在每个地方都加啊，不仅增加代码量也属于一个无用代码

此时链路追踪ZipKin就出现了，根据服务的流水号id，流水号id贯穿整个调用链路

Sleuth主要和ZipKin结合

**1.官方文档：**http://cloud.spring.io/spring-cloud-static/Finchley.SR1/single/spring-cloud.html#sleuth-adding-project

2.什么是Sleuth？

最主要功能，做日志埋点，帮我打印整一个服务调用链路

3.添加依赖（相关服务都需要加进去）

        <!--Sleuth链路追踪-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-sleuth</artifactId>
        </dependency>

4.加入依赖后重启服务重新访问服务

日志打印的黄色字体：第一个是应用的名称，第二个是整个请求的唯一id(去每一个服务调用都是这个id)，第三个是基本工作单元，获取元数据(可以包含多个元数据),第四个：false,是否要将信息输出到zipkin服务中来收集和展示

常见问题

日志不打印

orderserver打印了，productserver服务没打印

这就是日志级别设置的问题

在order和product服务分别加日志打印

    private final Logger logger = LoggerFactory.getLogger(getClass());
    在对应方法加
    logger.info("service save order");
    重启服务重新访问
    即可发现product也打印了