## SpringCloud Sleuth + Zipkin 概览 ### 认识 SpringCloud sleuth - SpringCloud Sleuth 实现的功能是:它会自动为当前应用构建起各通信通道的跟踪机制 - 通过诸如 RabbitMQ、Kafka(或者其他任何 SpringCloud Stream 绑定器实现的消息中间件)传递的请求 - 通过 Zuul、Gateway 代理传递的请求 - 通过 RestTemplate 发起的请求 > Service A -Rest[FLAG]-> ServiceB -Kafka[FLAG]-> Service D (服务与服务之间的时间消耗)
> -Rest[FLAG]-> Service C --- - SpringCloud Sleuth 跟踪实现原理 - 为了实现请求跟踪:当请求发送到分布式系统的入口端点时,只需要服务跟踪框架为该请求创建一个唯一的跟踪标识,Trace ID - 为了统计各处理单元的时间延迟,当请求到达各个服务组件时,或是处理逻辑到达某个状态时,也通过一个唯一标识来标记它的开始、具体过程以及结束,Span ID > Service A[traceld, spanldA] -> Service B[traceld, spanldA1] -> Service D[traceld, spanldA11]
> -> Service C[traceld,spanldA2] --- - Zipkin 的基础概念 - Zipkin 解决微服务架构中的延迟问题,包括数据的收集、存储、查找和展现 - Zipkin 有四大核心组件构成: - Collector:收集器组件 - Storage:存储组件 - API: RESTFUAPI,提供外部访问接口 - U:Web Ul,提供可视化査询页面 - ![Zipkin流程图.png](pic/Zipkin流程图.png) --- - Zipkin Web UI 预览 - 链路追踪与服务依赖 Zipkin 展示预览 - ![ZipkinWebUI.png](pic/ZipkinWebUI.png) ## 集成 SpringCloud Sleuth 实现微服务通信跟踪 - 集成 SpringCloud Sleuth 的步骤 - 第一原则:保证你的微服务存在跨进程通信,否则,意义不大(完全可以通过更简单的方式实现) - 在 pom.xml中添加依赖配置 - 注意日志中的输出变化 - 代码中调用方法的打印是 10 进制的, Sleuth 打印是 16进制的打印 - PS: 命令行退出 mysql \q - echo 'ibase=10,obase=16;xxxxxxxxxxx' | bc --- ## 搭建 Zipkin Server 实现对跟踪信息的收集 - 搭建 Zipkin Server 的步骤 - Tips:SpringCloud Finchley 版本(包含)之后,官方不建议自己搭建 Zipkin-Server, 提供了已经打包好的jar 文件(SpringBoot工程),直接下载启动即可 - 下载地址:curl -sSL https://zipkin.io/quickstart.sh | bash -s - 选择自己需要的版本,我的是 zipkin-server-2.21.7-exec.jar - 选择 exec.jar 结尾的 jar --- - 启动命令: nohup java -jar zipkin-server-2.21.7-exec.jar --server.port=8888 & --- - 配置 Zipkin Server 实现对跟踪信息的收集 - 为什么需要对 Zipkin Server 做自定义配置 ? - 默认情况下,Zipkin Server 将跟踪信息存储在内存中(JVM ),重启会丢失 - Zipkin Server 默认使用 HTTP 方式上报跟踪数据,性能较差 - Zipkin Server 配置 MySQL 跟踪数据持久化 - MySQL 中添加数据表: - https://github.com/openzipkin/zipkin/blob/master/zipkin-storage/mysal-v1/src/main/resources/mysql.sql - Zipkin Server 启动指定 MySQL 路径 --- - 启动命令 - java -jar zipkin-server-2.21.7-exec.jar --STORAGE_TYPE=mysql --MYSQL_HOST=127.0.0.1 --MYSQL_TCP_PORT=3306 --MYSOL_USER=root --MYSQL_PASS=root --MYSQL_DB=by_zipkin ## SpringCloud Sleuth 整合 Zipkin 实现分布式链路跟踪、收集 - SpringCloud Sleuth 整合 Zipkin 的步骤 - 简单的两个步骤(Zipkin Server 使用 MySQL 实现跟踪数据持久化) - pom 文件中添加依赖 ```xml org.springframework.cloud spring-cloud-starter-zipkin ``` - bootstrap 中增加 Zipkin 的配置 ```yaml kafka: bootstrap-servers: 127.0.0.1:9092 producer: retries: 3 consumer: auto-offset-reset: latest sleuth: sampler: # ProbabilityBasedSampler 抽样策略 probability: 1.0 # 采样比例, 1.0 表示 100%, 默认是 0.1 # RateLimitingSampler 抽样策略, 设置了限速采集, spring.sleuth.sampler.probability 属性值无效 rate: 100 # 每秒间隔接受的 trace 量 zipkin: sender: type: kafka # 默认是 web base-url: http://localhost:9411/ ``` --- - 下载、安装 Kafka 配置跟踪数据传输 - 下载Kafka :https://kafka.apache.org/quickstart - 一般采用 - 解压、启动 ZK和 Kafka Server 即可(使用默认配置) - 启动内置 zk ```shell Kafka_2.13-2.7.0 bin/zookeeper-server-start.sh config/zookeeper.properties ``` - 启动 kafka ```shell kafka_2.13-2.7.0 bin/kafka-server-start.sh config/server.properties ``` - 启动 zipkin ```shell zipkin java -DKAFKA_BOOTSTRAP_SERVERS=127.0.0.1:9092 -jar zipkin-server-2.21.7-exec.jar --STORAGE_TYPE=mysql --MYSQL_HOST=127.0.0.1 --MYSQL_TCP_PORT=3306 --MYSQL_USER=root --MYSQL_PASS=root --MYSQL_DB=imooc_zipkin ``` --- ## SpringCloud Sleuth 设置采样率、抽样收集策略 - SpringCloud Sleuth 采样收集 - 收集跟踪信息是一把双刃剑,需要做好权衡 - 收集的跟踪信息越多,越能反映出系统的实际运行情况 - 高并发场景下,大量的请求调用会产生海量的跟踪日志信息,性能开销太大 - Sleuth --(Kafka[策略:True])--> Zipkin - 可以自由选择 Zipkin brave 自带的两个抽样策略 - ProbabilityBasedSampler 采样率策略 - 默认使用的策略, 以请求百分比的方式配置和收集跟踪信息: 它的默认值为 0.1,代表收集 10% 的请求跟踪信息 - spring.sleuth.samplerprobability=0.5 - RateLimitingSampler 抽样策略 - 限速采集,也就是说它可以用来限制每秒追踪请求的最大数量,优先级更高 - spring.sleuth.sampler.rate=10 - 开发环境下,配置尽可能高的采样率, 方便解决问题和性能瓶颈等的尽早发现 - 线上环境采样率不宜过高 --- ```yaml sleuth: sampler: # ProbabilityBasedSampler 抽样策略 probability: 1.0 # 采样比例, 1.0 表示 100%, 默认是 0.1 # RateLimitingSampler 抽样策略, 设置了限速采集, spring.sleuth.sampler.probability 属性值无效 rate: 100 # 每秒间隔接受的 trace 量 ``` - 使用代码的方式 [SamplerConfig.java] - PS: 代码和配置文件: 只使用一种方式即可 - PS: 采样策略也使用一个即可, 通常只使用限速采集 --- ## SpringCloud Sleuth + Zipkin 分布式日志追踪总结 - SpringCloud sleuth + Zipkin 逻辑架构 - 跟踪、收集所涉及到的三个组件(模块) Sleuth、Zipkin、Brave - 三个组件之间的关系 - Brave 是一个 tracer 库,提供的是 tracer 接囗 - Sleuth 采用了 Brave 作为 tracer库 - Sleuth可以不使用 Zipkin - ![SpringCloudsleuthZipkin逻辑架构.png](pic/SpringCloudsleuthZipkin逻辑架构.png) --- - Brave 解读 - Brave 的两个最基本、也是最核心的概念 - trace: 以看作是一个逻辑执行过程中的整个链条 - span:是 trace 跟踪的基本单位 ```java void order(){ GoodsService(); AccountService(); } void Accountservice(){ DeductBalance(); } ``` ```text Span: Order _ / \ | Child Child | / \ | Span: Goods Span: Account Trace | | Child | | | Span: Deduct - ``` --- - Brave 中常用的数据结构及其说明 - Tracing:工具类,用于生成 Tracer 类实例 - Tracer :也是工具类,用于生成 Span - Span:实际记录每个功能块执行信息的类 - TraceContext :记录 trace 的执行过程中的元数据信息类 - Propagation :用于在分布式环境或者跨进程条件下的trace 跟踪时实现 TraceContext 传递的工具类 - ![Brave中常用的数据结构及其说明.png](pic/Brave中常用的数据结构及其说明.png) --- - SpringCloud Sleuth 实现跨服务 Trace 追踪 - SpringCloud Sleuth 和 Brave 提供了很多不同的分布式框架的支持,例如 qRPC、Kafka、HTTP 等 - Brave 实现跨服务(或者跨线程)Trace追踪的核心是通过 TraceContext 中核心信息的传递来实现的 - 样例:Brave 针对 HTTP 服务进行Context 传递的标准流程 - ![实现跨服务Trace追踪.png](pic/实现跨服务Trace追踪.png)