[系列] - go-gin-api 路由中间件 - Jaeger 链路追踪（五）

　　概述

　　首先同步下项目概况：

　　

　　上篇文章分享了，路由中间件 - 捕获异常，这篇文章咱们分享：路由中间件 - Jaeger 链路追踪。

　　啥是链路追踪？

　　我理解链路追踪虽然是为微服务构架提供服务的，当一个恳求中，请求了多个服务单元，如果恳求出现了错误或异常，很难去定位是那个服务出了问题，这时就须要链路追踪。

　　咱们先看一张图：

　　

　　这张图的调用链还比较清晰，咱们想像一下，随着服务的越来越多，服务与服务之间调用关系也越来越多，可能还会发展成右图的情况。

　　

　　这调用关系真的是... 看到这，我的内心是崩溃的。

　　

　　那么问题来了，这种情况下如何快速定位问题？

　　如何设计日志记录？

　　我们自己也可以设计一个链路追踪，比如当发生一个恳求，咱们记录它的：

　　怎么去实现恳求的惟一标示？

　　以 Go 为例 写一个中间件，在每次恳求的 Header 中收录：X-Request-Id，代码如下：

　　func SetUp() gin.HandlerFunc {

return func(c *gin.Context) {

requestId := c.Request.Header.Get("X-Request-Id")

if requestId == "" {

requestId = util.GenUUID()

}

c.Set("X-Request-Id", requestId)

c.Writer.Header().Set("X-Request-Id", requestId)

c.Next()

}

}

复制代码

　　每个 Request 和 Response 日志中都要收录 X-Request-Id。

　　问题又来了，每次调用都记录日志，当调用的服务过多时，频繁的记录日志，就会有性能问题呀，肿么办？

　　

　　哎，这么麻烦，看看市面上有没有一些开源工具呢？

　　开源工具

　　这个就不多做介绍了，基本上都能满足需求，至于优缺点，大家可以逐个去看看，喜欢那个就用那个？

　　我为何选择 Jaeger ？

　　因为我目前只会用这个，其他还不会 ...

　　咱们一起看下 Jaeger 是怎么回事吧。

　　Jaeger 架构图

　　

　　图片来源于官网。

　　简单介绍下上图三个关键组件：

　　Agent

　　Agent是一个网路守护进程，*敏*感*词*通过UDP发送过来的Span，它会将其批量发送给collector。按照设计，Agent要被布署到所有主机上，作为基础设施。Agent将collector和客户端之间的路由与发觉机制具象了下来。

　　Collector

　　Collector从Jaeger Agent接收Trace，并通过一个处理管线对其进行处理。目前的管线会校准Trace、建立索引、执行转换并最终进行储存。存储是一个可插入的组件，现在支持Cassandra和elasticsearch。

　　Query

　　Query服务会从储存中检索Trace并通过UI界面进行诠释，该UI界面通过React技术实现，其页面UI如下图所示，展现了一条Trace的详尽信息。

　　其他组件，大家可以了解下并选择性使用。

　　Jaeger Span

　　

　　图片来源于官网。

　　怎么操作 Span 呢？Span 有什么可以调用的 API ？

　　

　　Jaeger 部署

　　All in one

　　为了便捷你们快速使用，Jaeger 直接提供一个 All in one 包，我们可以直接执行，启动一套完整的 Jaeger tracing 系统。

　　启动成功后，访问 :16686 就可以看见 Jaeger UI。

　　独立布署

　　可以自由搭配，组合使用。

　　Jaeger 端口Jaeger 采样率

　　分布式追踪系统本身也会导致一定的性能低耗损，如果完整记录每次恳求，对于生产环境可能会有极大的性能耗损，一般须要进行取样设置。

　　固定取样

　　（sampler.type=const）

　　按比率取样

　　（sampler.type=probabilistic）

　　采样速率限制

　　（sampler.type=ratelimiting）

　　动态获取采样率

　　（sampler.type=remote）

　　Jaeger 缺点

　　看到这，说的都是理论，大家的心声可能是：

　　

　　实战

　　

　　关于实战的分享，我打算整理出 4 个服务，然后实现服务与服务之间进行互相调用，目前 Demo 还没写完...