SpringCloud集成SkyWalking链路追踪并收集日志2

博主介绍：✌全网粉丝5W+，全栈开发工程师，从事多年软件开发，在大厂呆过。持有软件中级、六级等证书。可提供微服务项目搭建与毕业项目实战，博主也曾写过优秀论文，查重率极低，在这方面有丰富的经验✌

博主作品：《Java项目案例》主要基于SpringBoot+MyBatis/MyBatis-plus+MySQL+Vue等前后端分离项目，可以在左边的分类专栏找到更多项目。《Uniapp项目案例》有几个有uniapp教程，企业实战开发。《微服务实战》专栏是本人的实战经验总结，《Spring家族及微服务系列》专注Spring、SpringMVC、SpringBoot、SpringCloud系列、Nacos等源码解读、热门面试题、架构设计等。除此之外还有不少文章等你来细细品味，更多惊喜等着你哦

🍅uniapp微信小程序🍅面试题软考题免费使用，还可以使用微信支付，扫码加群。由于维护成本问题得不到解决，可能将停止线上维护。

点击这里预览

抖音体验版

🍅文末获取联系🍅精彩专栏推荐订阅👇🏻👇🏻 不然下次找不到哟

Java项目案例《100套》
https://blog.csdn.net/qq_57756904/category_12173599.html
uniapp小程序《100套》

https://blog.csdn.net/qq_57756904/category_12173599.html

有需求代码永远写不完，而方法才是破解之道，抖音有实战视频课程，某马某千等培训都是2万左右，甚至广东有本科院校单单一年就得3万4年就12万学费，而且还没有包括吃饭的钱。所以很划算了。另外博客左侧有源码阅读专栏，对于求职有很大帮助，当然对于工作也是有指导意义等。在大城市求职，你面试来回一趟多多少少都在12块左右，而且一般不会一次性就通过，还得面试几家。而如果你对源码以及微服务等有深度认识，这无疑给你的面试添砖加瓦更上一层楼。

最后再送一句：最好是学会了，而不是学废了！！

2

前言

在上一篇文章skywalking安装教程中我们介绍了skywalking的作用以及如何将其集成到我们的微服务项目中。本篇文章我们介绍在微服务架构中，如何使用skywalking对一次客户端请求进行全链路追踪。

何为全链路追踪？

个人理解：在微服务架构中，一次客户端请求在对应的接口中可能需要通过多次跨服务调用完成，以skywalking安装教程中的项目演示为例，一次成功结束的请求可能需要经过商品微服务、订单微服务以及支付微服务三个服务共同处理，其中商品服务调用订单服务，订单服务调用支付服务。这就是微服务架构的调用链。skywalking通过一个请求上下文将一次客户端请求中涉及到的服务调用进行追踪，列出该调用链中涉及的微服务名、微服务中的接口名，这样我们就容易找到对应的接口，查看相应的代码去排查遇到的bug问题等。

通过skywalking支持全链路追踪，可以将微服务架构中的服务调用转变为实例调用。

全链路追踪

为了方便我们可用启动4个服务，eureka-server、cloud-pay、cloud-order、cloud-goods

微服务逻辑：

1、商品微服务

@Slf4j
@RestController
@RequestMapping("/goods")
public class GoodsController {

    @Value("${server.port}")
    private Integer port;

    private final IOrderClient orderClient;

    public GoodsController(IOrderClient orderClient) {
        this.orderClient = orderClient;
    }

    @GetMapping("/buy")
    public Integer buy(@RequestParam Integer id) {
        log.info("商品服务，服务端口号：{}", port);
        log.info("商品id：{}", id);

        Integer result = orderClient.create(id);
        log.info("下单结果：{}", result);
        if (result == 0) {
            log.info("购买成功");
        } else {
            log.error("购买失败");
        }

        return result;
    }
}

2、订单微服务

@Slf4j
@RestController
@RequestMapping("/order")
public class OrderClient implements IOrderClient {

    @Value("${server.port}")
    private Integer port;

    private final IPayClient payClient;

    public OrderClient(IPayClient payClient) {
        this.payClient = payClient;
    }

    @Override
    @GetMapping("/create")
    public Integer create(@RequestParam("goodsId") Integer goodsId) {
        log.info("订单服务feign接口，服务端口号：{}", port);
        log.info("商品id：{}", goodsId);
        if (goodsId % 2 == 0) {
            log.error("下单失败：商品id为2的倍数");
            return 1;
        }

        Integer result = payClient.pay(goodsId);
        if (result == 0) {
            log.info("支付成功");
        } else {
            log.error("支付失败");
        }
        return result;
    }
}

3、支付微服务

@Slf4j
@RestController
@RequestMapping("/pay")
public class PayClient implements IPayClient {

    @Value("${server.port}")
    private Integer port;

    @GetMapping("/pay")
    @Override
    public Integer pay(@RequestParam("goodsId") Integer goodsId) {
        log.info("支付服务feign接口，服务端口号：{}", port);
        log.info("商品id：{}", goodsId);
        if (goodsId % 3 == 0) {
            log.error("支付失败：商品id为3的倍数");
            return 1;
        }

        if (goodsId % 5 == 0) {
            log.error("支付失败：商品id为5的倍数");
            throw new RuntimeException("支付异常：商品id为5的倍数");
        }
        // 支付成功
        return 0;
    }
}

分别在后面三个微服务中加上logback.xml日志配置

<?xml version="1.0" encoding="UTF-8"?>
<configuration>　　
    <!-- 控制台输出 -->
    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
            <layout class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.TraceIdPatternLogbackLayout">
                <Pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%tid] [%thread] %-5level %logger{36} -%msg%n</Pattern>
            </layout>
        </encoder>
    </appender>
    <!-- 配置异步记录 AsyncAppender -->
    <appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender">
        <discardingThreshold>0</discardingThreshold>
        <queueSize>1024</queueSize>
        <neverBlock>true</neverBlock>
        <appender-ref ref="STDOUT"/>
    </appender>
    <!-- skywalking grpc 日志收集 8.4.0版本开始支持 -->
    <appender name="grpc-log" class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.log.GRPCLogClientAppender">
        <encoder class="ch.qos.logback.core.encoder.LayoutWrappingEncoder">
            <layout class="org.apache.skywalking.apm.toolkit.log.logback.v1.x.mdc.TraceIdMDCPatternLogbackLayout">
                <Pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%tid] [%thread] %-5level %logger{36} -%msg%n</Pattern>
            </layout>
        </encoder>
    </appender>

    <!--系统操作日志-->
    <root level="DEBUG">　　
        <appender-ref ref="STDOUT"/>　
        <appender-ref ref="ASYNC"/>　
        <appender-ref ref="grpc-log"/>
    </root>
</configuration>

启动4个服务

刷新Skywalking

在服务集成到skywalking初期，skywalking是无法显示服务中的业务接口的，当我们调用服务中的接口时，对应的接口才会出现在skywalking中。

正常调用

正常调用跟异常调用区别在于异常是红色告警，所以我们看下面的异常调用

异常调用

当我们调用商品服务的接口并传入商品id为5时，发现响应状态为500，说明接口中出现异常

我们进入skywalking页面查看该调用链路

首先我们知道此次请求调用的是商品微服务暴露的接口，所以我们进入商品服务查看调用链路

进来后找到对应时间的请求

由图我们可用清晰地看到调用链路中的微服务名(spring.application.name)、接口(请求类型GET、POST、PUT等)。

与前面正常请求的界面不同的是，当接口中出现异常导致响应500时，该链路采用红色重点标记，其调用链中也通过使用红色的点进行标记，方便我们知道异常发生在哪些服务中。

我们点击调用链路的其中一环，如下所示，可以发现，商品服务处理请求的实例为端口号为9527的实例，从中也可以看到异常信息

我们点击接口查看接口日志，下面是GET:/goods/buy

商品服务调用订单服务，我们再点击订单服务中接口请求的一行

订单服务调用支付服务，我们再点击支付服务中接口请求的一行

好了，去消化消化吧