spring-cloud（八）微服务链路追踪篇-SkyWalking
文章目录
-
- spring-cloud-Hoxton.SR6 （八）微服务链路追踪篇-SkyWalking
-
- 一、为什么需要链路追踪？
- 二、链路追踪组件之SkyWalking
-
- （1）是什么是SkyWalking
- （2）SkyWalkIng与ZipKin对比
-
- （1）ZipKin
-
- 1.安装ZipKIn服务端
- 2.客户端
- 3.ZIpKIn优缺点
- （2）skyWalking
-
- 1.SkyWalking 组成部分
- 2.SkyWalking 优缺点
- 三、SkyWalking 环境搭建
- 四、SkyWalkIng的使用
-
- （1）检查SkyWalking
- （2）项目中使用
-
- 1、IDEA 部署探针 （本地开发）
- 2、JAR包方式部署微服务探针处理（jar包部署）
- 3、Docker方式部署 探针处理（docker部署）
- （3）SKyWalkIng的使用
spring-cloud-Hoxton.SR6 （八）微服务链路追踪篇-SkyWalking
本文spring-cloud 版本为：hoxton.sr6
本文spring-boot版本为：2.2.x-2.3.x
一、为什么需要链路追踪？
由于微服务化项目拆分，会导致系统服务间调用链路愈发复杂，此时，一个前端请求可能最终需要调用多个后端服务才能完成实现。
微服务间调用链路可能是这样：
可能我画的不是很准确或者复杂，但是我的意图您需要清楚，就是微服务间啊，相互依赖，一个请求可能需要依赖多个微服务间调用，其整个调用链呢，可能非常复杂繁杂！服务越多，链路图一定会越乱，越复杂！
当整个请求不可用出现问题时，我们是没有办法判断请求是由哪个后端服务引发问题，这时我们需要快速定位故障点，找到调用异常的服务，跟进一个请求到底有哪些服务参与，参与顺序是怎样，从而达到每个请求的步骤清晰可见并且如果有新同事加入，不能快速的知道自己所负责的服务在哪一环等等…于是就有了分布式系统调用跟踪的需求。
为什么需要链路追踪总结如下：
-
1.故障定位难
-
2.链路梳理难
-
无法快速上手
即使服务再多，微服务间相互依赖的关系再乱，链路再乱，有了链路追踪，每一个请求的调用链路都清晰明了了，我们可快速定位调用链路上的某一环节的问题以及帮助新同事快速梳理调用流程等…
链路追踪已经不是什么新兴技术和概念了，其可使用组件有很多，比如：sleuth、Zipkin、阿里鹰眼、大众点评Cat、SkyWalkIng等…
这些组件呢有一个共同的名字： APM 工具 （Application Performance Management）即应用性能监控工具…
今天呢，咱们学习一下链路追踪组件之 SkyWalkIng
二、链路追踪组件之SkyWalking
（1）是什么是SkyWalking
SkyWalking是中国人吴晟（华为）开源的一款APM工具，现在已属于Apache旗下开源项目, 是一个观察性分析平台和应用性能管理系统。提供分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。
（2）SkyWalkIng与ZipKin对比
至于为什么要采用此二者对比，因为我目前就用过这两个，zipkin是最早接触cloud项目用过，目前呢，是在学习SkyWalkIng
- zipkin：Twitter公司开源的一个分布式追踪工具，被Spring Cloud Sleuth集成，使用广泛而稳定-
- SkyWalking：中国人吴晟（华为）开源的一款分布式追踪，分析，告警的工具，现已属于Apache旗下开源项目
（1）ZipKin
zipKin 被Spring Cloud Sleuth所集成了，其分为客户端和服务端（如同eureka ，一个或集群下的服务端，然后所有被监控的服务都是其客户端）
Zipkin是一个分布式跟踪系统。它有助于收集解决服务体系结构中的延迟问题所需的时序数据。功能包括该数据的收集和查找。
戳我：ZipKin github文档：
ZipKin包含了一些核心组件有：
- 追踪器：位于客户端，并记录有关发生的操作的时间和元数据，然后传输给服务端，这一点用户可见
- Reporter： 将数据发送到Zipkin的检测应用程序
- Collector：位于服务端中，收集传输来的数据
- Storage ：存储数据，默认存储在内存中
- search ：内置查询api,可删选链路追踪明细
- UI ：链路追踪控制台Web 管理界面，没有身份验证
架构图：
使用一景：
简单说下ZipKin的使用步骤：
1.安装ZipKIn服务端
可下载zip 可用docker,可像eureka版新建项目作为服务端
1.docker
docker run -d --restart always -p 9411:9411 --name zipkin openzipkin/zipkin
2.新建项目作为服务端 (gradle版)
compile 'io.zipkin.java:zipkin-server'
compile 'io.zipkin.java:zipkin-autoconfigure-ui'
配置
server:
port: 9411
spring:
application:
name: zipkin-server
启动类添加注解
@EnableZipkinServer
2.客户端
客户端添加依赖
compile group: 'org.springframework.cloud', name: 'spring-cloud-sleuth-zipkin'
客户端yml配置指明zipkin服务端地址
spring:
zipkin:
#zipkin服务器地址
base-url: http://localhost:9411
sleuth:
sampler:
#链路跟踪的数据上传的概率 0.1-1.0
percentage: 1.0
3.ZIpKIn优缺点
优
- 轻量级，springcloud集成，使用人数多，成熟
缺
- 侵入性
- 功能简单
- 欠缺APM报表能力（能力弱）
（2）skyWalking
SkyWalking：中国人吴晟（华为）开源的一款分布式追踪，分析，告警的工具，现已属于Apache旗下开源项目, 探针将数据通过gRPC或者HTTP传输给后端平台（server），后端平台将数据存储在Storage中，并且分析数据将结果展示在UI中.
戳我：SkyWalking中文文档：
1.SkyWalking 组成部分
- Probes：探针，探针因使用的语言不同而不通，收集数据并且格式化为skywalking所需的格式。
- Platform backend ：平台后端，对应于zipkin server，可以集群部署，聚合，分析，将数据展示在UI中
- Storage：存储，可扩展的存储，可以使es，H2，MySQL集群默认 h2
- UI ：丰富的可视化功能，提供身份验证
官网架构图一：
官网架构图二：
2.SkyWalking 优缺点
优
- 多种监控手段多语言自动探针，Java，.NET Core 和 Node.JS
- 轻量高效，不需要大数据
- 模块化，UI、存储、集群管理多种机制可选，
- 支持告警
- 社区活跃
缺：
- 较为新兴，成熟度不够高
三、SkyWalking 环境搭建
本文，采用docker-compose 安装 SkyWalking 环境
项目采用SkyWalkIng 版本为8.0.1 目前最新版为：8.1.0…
使用Elasticsearch7.x 版本存储数据（链路追踪相关数据）
实际上本次docker-compsoe.yml共构建了启动三个镜像：
es7.8.0、skywalking-oap-server 8.0.1、skywalking-ui:8.0.1
#docker-compose 文件所用版本号 这个需要注意 不同版本写法还是有点小区别的
version: '3'
services:
#依赖于es存储
elasticsearch7:
image: elasticsearch:7.8.0
container_name: elasticsearch7
restart: always
ports:
#es 外暴映射端口
- 9200:9200
environment:
- discovery.type=single-node
- bootstrap.memory_lock=true
- "ES_JAVA_OPTS=-Xms512m -Xmx512m"
- TZ=Asia/Shanghai
ulimits:
memlock:
soft: -1
hard: -1
networks:
- skywalking
volumes:
- elasticsearch7:/usr/share/elasticsearch/data
#构建SkyWalking 服务
oap:
image: apache/skywalking-oap-server:8.0.1-es7
container_name: oap
depends_on:
- elasticsearch7
links:
- elasticsearch7
restart: always
ports:
- 11800:11800
- 12800:12800
networks:
- skywalking
volumes:
- ./ext-config:/skywalking/ext-config
#SkyWalkIng 可视化web界面
ui:
image: apache/skywalking-ui:8.0.1
container_name: ui
depends_on:
- oap
links:
- oap
restart: always
ports:
- 8080:8080
environment:
SW_OAP_ADDRESS: oap:12800
security.user.admin.password: lei..
networks:
- skywalking
networks:
skywalking:
driver: bridge
volumes:
elasticsearch7:
driver: local
四、SkyWalkIng的使用
（1）检查SkyWalking
当docker-compose 构建好SkyWalkIng 环境后，我们可以访问web界面查看！
端口号看你docker-compose 构建时映射的web端口号了
检查Es IP:9200
（2）项目中使用
SkyWalkIng在我们的微服务项目中虽然不需要额外引入依赖包，但是为了给SkyWalkIng 发送我们的链路信息，实际上还需要一个探针
Probes：探针，探针因使用的语言不同而不通，收集数据并且格式化为skywalking所需的格式。
因为我开发语言为jaava，则需要java探针，即Java Agent 服务器探针
那么探针在哪里来呢？在SkyWalkIng项目中，我们需要下载
下载：es7-8.0.1 版本
下载：SkyWalking历史版本
Java Agent 服务器探针：
下载完解压如下：
java agent 所处的位置在 解压后文件夹 apache-skywalking-apm-es7-8.0.1\apache-skywalking-apm-bin-es7\agent 目录下
参考官网给出的帮助 Setup java agent，我们需要使用官方提供的探针为我们达到监控的目的
其实说白了就是我们要把 skywalkIng-agent.jar 放在我们启动参数之中
要想把当前服务让SkyWalkIng 管理监控起来，需要进行以下jvm参数设置（每一个想要使用SkyWalkIng的服务均要进行参数设置）
-javaagent: skywalkIng-agent.jar所在位置
-Dskywalking.agent.service_name=当前项目在skywalking想要叫啥名字
-Dskywalking.collector.backend_service=SkyWalkIng 服务端本地址
1、IDEA 部署探针 （本地开发）
我们需要给每个想要由SkyWalkIng管理的项目添加JVM 启动参数
-javaagent:D:\google\apache-skywalking-apm-es7-8.0.1\apache-skywalking-apm-bin-es7\agent\skywalking-agent.jar
-Dskywalking.agent.service_name=demo-order
-Dskywalking.collector.backend_service=xxxxx:11800
SkyWalking服务端IP 由开始docker-compose 映射指定 11800 为外部通信地址
就近采用前边的项目 ,均设置探针参数后启动
这时候，我们再来看一下SKyWalkIng管理端，有信息，则说明探针部署成功了
2、JAR包方式部署微服务探针处理（jar包部署）
注意:我这里执行语句不能直接copy 你需要自己更改skywalkIng.jar 包位置 以及 服务名字，jar包名字
java -javaagent:D:/google/apache-skywalking-apm-es7-8.0.1/apache-skywalking-apm-bin-es7/agent/skywalking-agent.jar -Dskywalking.agent.service_name=demo-order -Dskywalking.collector.backend_service=xxxx:11800 -jar springcloud-openfeign-hystrix-order-0.0.1-SNAPSHOT.jar
3、Docker方式部署 探针处理（docker部署）
方式一：
构建基础镜像，将我们的skywalking-agent 文件包含在内，提供给java服务使用
FROM centos:7
WORKDIR /app
RUN yum install -y wget && \
yum install -y java-1.8.0-openjdk
ADD https://mirror.bit.edu.cn/apache/skywalking/8.0.1/apache-skywalking-apm-es7-8.0.1.tar.gz /app
RUN tar -xf apache-skywalking-apm-es7-8.0.1.tar.gz && \
mv apache-skywalking-apm-bin-es7 skywalking
RUN ls /app
docker build -t base/skywalking:1.0 .
构建服务镜像 order
FROM base/skywalking:1.0
COPY springcloud-openfeign-hystrix-order-1.0.jar /app/app.jar
EXPOSE 9002
ENTRYPOINT java -javaagent:/app/skywalking/agent/skywalking-agent.jar -Dskywalking.agent.service_name=docker-order-demo -Dskywalking.collector.backend_service=xxxx:11800 -Dserver.port=9002 -jar app.jar
docker build -t order-demo:1.0 -f /docker/lei/Dockerfile .
这样，在构建好 order-demo后，其容器内部也会有一个skywalking-agent.jar 的文件了
方式二：
使用数据卷挂载（-v 将探针位置挂载到容器内部）
（3）SKyWalkIng的使用
清晰的看到了服务负载情况以及访问接口，缓慢的点在哪里
从上图可以看出，访问/product/demo/{id} 接口。负载到demo-product-one 服务时候，接口 /product/demo/{id}整个响应比较缓慢，demo-product-one 这个接口耗时达到了4032ms,而到了demo-product-two时候，接口/product/demo/{id} 只用了15ms
出现这个的原因！！！ 那当然是因为我前边设置的线程睡眠4000毫秒测试OpenFeign 和Hystrix的问题呀！
这个呢，是全局的接口响应统计记录，我们可以根据此报表看出，再某一个时间段的响应情况
我们再测试一下其他的接口
额…报错了！
注意：SkyWalkIng OPenFeign 报错org.apache.skywalking.apm.agent.core.plugin.interceptor.enhance.InstMethodsInter.intercept
解决：
服务调用方yml 配置添加
feign:
httpclient:
enabled: true
服务调用方依赖包添加
<dependency>
<groupId>io.github.openfeigngroupId>
<artifactId>feign-httpclientartifactId>
dependency>
OK！解决！
SkyWalkIng 提供的微服务间拓扑图
有了这个甚至无需我们自己手绘调用链路图…
Service ApdexScore :性能指标分数 0-1 越接近1 ，则说明服务性能越好…
点击微服务图标，会出现对应选择按钮，有服务器性能监控，整个服务调用链路、端点（请求过得url)监控等等
比如我们要查看order 的调用链路
左侧这一栏呢，则为请求链路了，目前这一大排呢，是我自己Consul对客户端的健康检查…
OK。好的，我们自己发送一些请求到demo-order服务
服务故障模拟
我们down掉两个product服务，然后请求order服务
可以看到，失败的请求在SkyWalking 调用链路中，标记为了红色，请调用链路图中了，/product/demo/{id}、Hystrix也变为了红色
点击报红链路—可以查看到改链路的错误信息
…
综上：用了SkyWalkIng 整个服务的调用链路信息是十分的明显了。。。。。每段链路的耗时，以及整个请求所涉及的服务，都非常的清晰明显！！！很方便问题的排查！！！
SkyWalking 其报表能力非常的出色，也支持报表图片直接导出功能！很方便出了问题，同事间互相探讨以及项目组ppt讲义问题排查等等，自带高清无码图片下载，，，杠杠的！！
SkyWalkIng呢，其整个页面涉及以及功能还是比较完善的，虽然较之老牌王者 ZipKIn等可能还欠缺点火候，但依然影响不了其实用性，生产环境，还是可以使用的！
那么，本次的SkyWalkIng 使用就到这里了！