zipkin

Love The Way You Lie 2024-04-17 05:59 49阅读 0赞

## 一 、概述 ##

zipkin为分布式链路调用监控系统，聚合各业务系统调用延迟数据，达到链路调用监控跟踪。

在复杂的调用链路中假设存在一条调用链路响应缓慢，如何定位其中延迟高的服务呢？

*  日志： 通过分析调用链路上的每个服务日志得到结果；
 *  zipkin：使用zipkin的web UI可以一眼看出延迟高的服务；

**zipkin主要涉及四个组件 collector storage search web UI**

1.  Collector接收各service传输的数据；
2.  Cassandra作为Storage的一种，也可以是mysql等，默认存储在内存中，配置cassandra可以参考这里；
3.  Query负责查询Storage中存储的数据,提供简单的JSON API获取数据，主要提供给web UI使用；
4.  Web 提供简单的web界面；

**使用zipkin涉及几个概念**

1.  Span:基本工作单元，一次链路调用(可以是RPC，DB等没有特定的限制)创建一个span，通过一个64位ID标识它， span通过还有其他的数据，例如描述信息，时间戳，key-value对的(Annotation)tag信息，parent-id等,其中parent-id 可以表示span调用链路来源，通俗的理解span就是一次请求信息；
2.  Trace:类似于树结构的Span集合，表示一条调用链路，存在唯一标识；
3.  Annotation: 注解,用来记录请求特定事件相关信息(例如时间)，通常包含四个注解信息；

cs - Client Start,表示客户端发起请求
     
    sr - Server Receive,表示服务端收到请求
     
    ss - Server Send,表示服务端完成处理，并将结果发送给客户端
     
    cr - Client Received,表示客户端获取到服务端返回信息

1.  BinaryAnnotation:提供一些额外信息，一般已key-value对出现

## 二、完整的调用链路 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2OTE4MTQ5_size_16_color_FFFFFF_t_70]  
上图表示一请求链路，一条链路通过Trace Id唯一标识，Span标识发起的请求信息，各span通过parent id 关联起来，如图

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2OTE4MTQ5_size_16_color_FFFFFF_t_70 1]  
整个链路的依赖关系如下:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2OTE4MTQ5_size_16_color_FFFFFF_t_70 2]  
完成链路调用的记录后，如何来计算调用的延迟呢，这就需要利用Annotation信息

![在这里插入图片描述][20190825163036283.png]

1. sr-cs 得到请求发出延迟
     2. ss-sr 得到服务端处理延迟
     3. cr-cs 得到真个链路完成延迟

Span细节图

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2OTE4MTQ5_size_16_color_FFFFFF_t_70 3]  
注意，上图并没有显示Span的所有细节（比如name和binaryAnnotation等），但这并不影响我们分析问题。

上图的①和⑥是一次完整的RPC调用，它发生在服务器0和服务器1之间，显而易见的是，用于描述该RPC调用的Span的spanId是1000，所以，这是同一个Span的，只是它的数据来源于两台不同的服务器（应用）：服务器0和服务器1。

往低层说，该Span由两条跟踪日志表示，一条在服务器0上被采集，另一条在服务器1上被采集，他们的Span的traceId、spanId和parentSpanId都是一样的！而且该Span将成为跟踪树中的顶节点，因为他们的parentSpanId为null。  
对于步骤①来说，服务器1上的sr减去服务器0上的cs的时间就是约等于网络耗时（这里忽略不同服务器时钟的差异），同理，对于其他步骤，sr-cs和cr-ss得到的都是网络耗时。

我们接着看请求步骤②和④，从跟踪树的层次来说他们属于①下的子调用，所以它们的parentSpanId就是①的1000。步骤②和④都会分别产生一个spanId（上面的1001和1002），所以如上图，看似一次简单的RPC过程，其实共产生了6条Span日志，它们将在Zipkin服务端组装成3个Span。

它的设计参考了，google dapper论文 中文: https://blog.csdn.net/yangzishiw/article/details/79402084

## 三、实际应用 ##

在SpringCloud中zipkin 与sleuth 配合使用，实现分布式系统链路治理。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2OTE4MTQ5_size_16_color_FFFFFF_t_70]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/15/897c9bcd56a3425c95982521ea79bd3e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2OTE4MTQ5_size_16_color_FFFFFF_t_70 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/15/206f02ef56a943ce8f0c0c8a0e0383c2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2OTE4MTQ5_size_16_color_FFFFFF_t_70 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/15/a3a1d7a9cf05421fa72c177e43cc2a81.png
[20190825163036283.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/15/3038a7fd66fe450ba1115edc8bfe462f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2OTE4MTQ5_size_16_color_FFFFFF_t_70 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/15/3ae196c26f8446d8a993f14fcdeb0763.png