SkyWalking服务端的搭建、微服务接入SkyWalking

SkyWalking

微服务链路追踪SkyWalking

相关服务：韩国站群服务器

一般的系统中，微服务会有几十上百个，微服务的调用是错综复杂的，如果其中一个微服务挂了，在线上环境中排查问题是比较困难的，我们不能永远执行降级方法。如果人员离职，新接收项目的开发人员，理清服务的调用链路也耗时耗力，更不用说定位问题解决问题了。

对于一个大型的几十上百个微服务构成的微服务架构系统，通常会遇到下面一些问题，比如：

• 如何串联整个调用链路，快速定位问题？
• 如何缕清各个服务之间的依赖关系？
• 如何进行各个微服务接口的性能分析？
• 如何跟踪整个业务流程的调用处理顺序？

SkyWalking介绍

skyWalking是一个国产开源框架，2015年开源，2017年假如Apache孵化器。skyWalking是分布式系统的应用程序性能监视工具，专门为微服务、云原生架构和基于容器(Docker、k8s、mesos)架构而设计。包括了分布式追踪、性能指标分析、应用和服务依赖分析等。

官网

下载链接

Github

文档

中文文档

链路追踪框架对比

• Zipkin是Twitter开源的调用链路分析工具，目前基于Spingcloud sleuth得到了广泛的应用，特点是轻量，部署简单。
• Pinpoint一个韩国团队开源的产品，运用了字节码增强技术，只需要在启动时添加启动参数即可，对代码无侵入，目前支持Java和PHP语言，底层采用HBase来存储数据，探针收集的数据粒度非常细，但性能损耗大，因其出现的时间较长，完成度也很高，应用的公司较多
• Skywalking是本土开源的基于字节码注入的调用链路分析以及应用监控分析工具，特点是支持多种插件，UI功能较强，接入端无代码侵入。
• CAT是由大众点评开源的，基于Java语言开发，目前提供Java、C/C++、Node.js、Python、Go等语言的客户端，监控数据会全量统计，国内很多公司在用，例如美团点评、携程、拼多多等，CAT跟下边要介绍的Zipkin都需要在应用程序中埋点，对代码侵入性强。

Skywalking功能介绍

• 多种监控手段，可以通过语言探针和service mesh获得监控的数据
• 支持多重语言的自动探针，包括JAVA, .NET Core和NodeJS
• 轻量高效，无需大数据平台和大量的服务器资源
• 模块化，UI ,存储，集群管理都有多种机制可选
• 支持告警
• 优秀的可视化解决方案

SkyWalking的组成部分

• SkyWalking agent和业务系统绑定在一起，负责收集各种监控数据
• SkyWalking oapservice是服务处理监控数据的，比如接收是SkyWalking agent的监控数据，并存储在数据库中；接收SkyWalking webapp的前端请求，从数据库查询数据，并返回给前端。SkyWalking通常以集群的形式存在。
• SkyWalking webapp，前端界面，用于展示数据
• 数据库，用于存储监控数据，比如mysql，slasticsearch等

SkyWalking服务端部署

下载链接

这里使用的是8.5.0版本，下载完成后对压缩包进行解压，首先看bin目录下

当我们运行startup.bat，就相当于同时运行了oapService.bat和webappService.bat，也就是下图红框所示的

接下来介绍SkyWalking的目录结构

• agent
  • skywalking-agent.jar: 代理服务jar包
  • config：代理服务启动时使用的配置文件
  • plugins：包含多个插件，代理服务启动时会加载该目录下的所有插件，实际是各种jar包
  • optional-plugins：可选插件，当需要支持某种功能时，比如SpringCloud Gateway，则需要把对应的jar拷贝到plugins目录下
• bin：各种启动脚本，一般使用脚本startup.sh来启动web页面和对应的SkyWalking后台应用
  • oapService：默认使用的后台程序的启动脚本；使用的是默认模式启动，还支持其他模式，各模式区别见启动模式
  • oapServiceInit：使用init模式启动；在此模式下，OAP服务器启动以执行初始化工作，然后退出
  • oapServiceNoInit：使用 no init模式启动；在此模式下，OAP服务器不进行初始化。
  • startup：组合脚本，同时启动oapService和webappService脚本
  • webappService：UI前端的启动脚本
• config：启动后台应用程序配置文件
• oap-libs：后台应用的各种依赖包
• webapp：UI前端的jar包和配置文件，可以在yml文件中修改访问前端的端口

接下来就启动服务，双击bin目录下的startup.bat启动文件，它就会弹出两个命令行窗口，并且日志会记录在logs目录下。

我这里修改了webapp前端项目的端口，改为了8868，默认是8080.

而SkyWalking-oap-server服务启动后会暴露11800和12800两个端口，分别为收集监控数据的端口11800和接收前端请求的端口12800，修改端口可以修改config/application.yml文件。

在windows中，如果启动失败，这个命令行窗口会自动关闭，在linux系统中，启动成功后会有一个success的成功提示

现在就可以在浏览器中输入http://localhost:8868/查看到SkyWalking的ui界面

SkyWalking中三个概念

• 服务：表示对请求提供相同行为的一系列或一组工作负载，在使用Agent时，可以定义服务的名字；
• 端点：对于特定服务所接受的请求路径，如HTTP的URI路径和gRPC服务的类名+方法签名
• 实例：上述一组工作负载中的每一个工作负载称为一个实例，一个服务实例实际就是操作系统上的一个进程。

Skywalking接入微服务

linux

首先将apache-skywalking-apm-bin-es7/agent文件夹拷贝到发布容器中，位置可以根据情况调整。

cp -r ./agent/* /opt/skywalkingAgent

优先级：探针 > JVM配置 > 系统环境变量 > agent.config

一般都使用探针方式

一般都使用探针方式，其他方式就不介绍了，配置方式如下：

格式1(推荐)：-javaagent:/path/to/skywalking-agent.jar={config1}={value1},{config2}={value2}

-javaagent:/opt/skywalkingAgent/skywalking-agent.jar=agent.service_name=fw-gateway,collector.backend_service=127.0.0.1:11800

格式2：-Dskywalking.[option1]=[value2]

-javaagent:/opt/skywalkingAgent/skywalking-agent.jar -Dskywalking.agent.service_name=fw-gateway -Dskywalking.collector.backend_service=127.0.0.1:11800

一般配置下面两项即可：

agent.service_name：客户端服务名，在apm系统中显示的服务名称。

collector.backend_service：SW上传的服务地址。

JVM参数的详细配置

# 命名空间，用于隔离跨进程传播的header。如果进行了配置，header将为HeaderName:Namespace. 
# agent.namespace=${SW_AGENT_NAMESPACE:default-namespace} 
 
# 展示界面中现实服务名称 
agent.service_name=${SW_AGENT_NAME:lizz-gw}
 
# 每3秒采样道数默认情况下，负或零表示关闭 
agent.sample_n_per_3_secs=${SW_AGENT_SAMPLE:-1}
 
# 鉴权是否开启取决于后端的配置，可查看application.yml的详细描述。对于大多数的场景，需要后端对鉴权进行扩展。目前仅实现了基本的鉴权功能。 
# agent.authentication = ${SW_AGENT_AUTHENTICATION:xxxx} 
 
# 单个线段中的最大跨距量。 
# 通过这个配置项，SkyWalking可以估计应用程序内存开销。 
# agent.span_limit_per_segment=${SW_AGENT_SPAN_LIMIT:150} 
 
# 如果段的操作名称以这些后缀结尾，则忽略这些段。 
# agent.ignore_suffix=${SW_AGENT_IGNORE_SUFFIX:.jpg,.jpeg,.js,.css,.png,.bmp,.gif,.ico,.mp3,.mp4,.html,.svg} 
 
# 如果为true，则SkyWalking代理将在“/debugging”文件夹中保存所有检测到的类文件。 
# SkyWalking可能会要求这些文件，以解决兼容问题。 
# agent.is_open_debugging_class = ${SW_AGENT_OPEN_DEBUG:true} 
 
# 如果为true，SkyWalking代理将把所有检测到的类文件缓存到内存或磁盘文件中（由类缓存模式决定）， 
# 允许其他javaagent增强那些由SkyWalking agent增强的类。 
# agent.is_cache_enhanced_class = ${SW_AGENT_CACHE_CLASS:false} 
 
# 插入指令的类缓存模式：内存或文件 
# 内存：将类字节缓存到内存中，如果插入指令的类太多或太大，则可能会占用更多内存 
# 文件：在“/class cache”文件夹中缓存类字节，当应用程序退出时自动清理缓存的类文件 
# agent.class_cache_mode = ${SW_AGENT_CLASS_CACHE_MODE:MEMORY} 
 
# 操作名称最大长度 
# 注意，在目前的实践中，我们不建议长度超过190。 
# agent.operation_name_threshold=${SW_AGENT_OPERATION_NAME_THRESHOLD:150} 
 
# The agent use gRPC plain text in default. 
# If true, SkyWalking agent uses TLS even no CA file detected. 
# agent.force_tls=${SW_AGENT_FORCE_TLS:false} 
 
# 如果为true，则当用户创建新的配置文件任务时，skywalking代理将启用配置文件。否则禁用配置文件。 
# profile.active=${SW_AGENT_PROFILE_ACTIVE:true} 
 
# 并行监视器段计数 
# profile.max_parallel=${SW_AGENT_PROFILE_MAX_PARALLEL:5} 
 
# 最大监视段时间（分钟），如果当前段监视时间超出限制，则停止它。 
# profile.duration=${SW_AGENT_PROFILE_DURATION:10} 
 
# 最大转储线程堆栈深度 
# profile.dump_max_stack_depth=${SW_AGENT_PROFILE_DUMP_MAX_STACK_DEPTH:500} 
 
# 快照传输到后端缓冲区的大小 
# profile.snapshot_transport_buffer_size=${SW_AGENT_PROFILE_SNAPSHOT_TRANSPORT_BUFFER_SIZE:50} 
 
# skywalking后端服务地址。 
collector.backend_service=${SW_AGENT_COLLECTOR_BACKEND_SERVICES:127.0.0.1:11800}
 
# 日志文件名 
logging.file_name=${SW_LOGGING_FILE_NAME:skywalking-api.log}
 
# 日志记录级别 
logging.level=${SW_LOGGING_LEVEL:WARN}
 
# 日志文件存储目录 
# logging.dir=${SW_LOGGING_DIR:""} 
 
# 日志文件最大值, default: 300 * 1024 * 1024 = 314572800 
# logging.max_file_size=${SW_LOGGING_MAX_FILE_SIZE:314572800} 
 
# 最大历史记录日志文件。当发生滚动时，如果日志文件超过这个数字， 
# 然后删除最旧的文件。默认情况下，负数或零表示禁用。 
# 如果不限制个数可能到只日志文件过大，磁盘爆满。 
logging.max_history_files=${SW_LOGGING_MAX_HISTORY_FILES:5}
 
# 忽略异常，有些异常属于业务需要，不用在sw中标示出来 
# statuscheck.ignored_exceptions=${SW_STATUSCHECK_IGNORED_EXCEPTIONS:} 
 
# 异常链路的跟踪深度，最好不要高于10，对性能有影响 
# statuscheck.max_recursive_depth=${SW_STATUSCHECK_MAX_RECURSIVE_DEPTH:1} 
 
# 增加agent下特定文件夹下的支持插件 
plugin.mount=${SW_MOUNT_FOLDERS:plugins,activations,bootstrap-plugins}
 
# 不加载某些支持插件，名称参考Plugin-list.md 
plugin.exclude_plugins=${SW_EXCLUDE_PLUGINS:dubbo,motan}
 
# 是否获取mysql操作sql的参数 
# plugin.mysql.trace_sql_parameters=${SW_MYSQL_TRACE_SQL_PARAMETERS:false} 
 
# Kafka producer configuration 
# plugin.kafka.bootstrap_servers=${SW_KAFKA_BOOTSTRAP_SERVERS:localhost:9092}
 
# 跟踪Spring中的bean，需要耗费更多的资源 
plugin.springannotation.classname_match_regex=${SW_SPRINGANNOTATION_CLASSNAME_MATCH_REGEX:}

windows

直接配置JVM启动参数

-javaagent:D:\stu_soft\SkyWalking\apache-skywalking-apm-es7-8.5.0\apache-skywalking-apm-bin-es7\agent\skywalking-agent.jar
-DSW_AGENT_NAME=gateway-nacos-server
-DSW_AGENT_COLLECTOR_BACKEND_SERVICES=127.0.0.1:11800

接下来进行测试，启动Gateway服务和一个Order订单服务，在浏览器中通过gateway路由访问到下单接口

然后在看SkyWalking的前端界面，可以看到这里已经显示了我们的服务，但是界面中心区域却还是空白的。

这是因为SkyWalking链路追踪默认情况下是不显示Gateway的，我们需要agent\optional-plugins\apm-spring-cloud-gateway-2.1.x-plugin-8.5.0.jar这个jar包拷贝到agent\plugins目录下，然后重启我们的Gateway微服务

拓补图也有内容了，用户请求gateway的服务，然后路由到订单服务上，订单服务就是8083的端口，这里的192.168.20.12:8083之所以是没有显示对应的服务名，是因为我们现在还没有为order服务接入SkyWalking。

SkyWalking接入多个微服务

SkyWalking接入多个微服务，只需要在每个微服务启动的时候添加JVM启动参数就可以了

接下来进行测试，启动gateway、order、stock三个服务都接入到SkyWalking中去。

因为openfeign的bug，刚开始远程调用时order服务调用了两次stock服务，然后seata的全局事务id就冲突了，然后报错，导致order和gateway服务标红了。可以通过修改超时时间解决调用两次的问题。

我们再看追踪菜单

左边菜单的排序的根据响应时间降序排列的，也就是越长的响应时间在前面，我们也可以选择根据调用时间的先后来排序；右边从这里的调用链路中可以很直观的发现是什么地方报错了

基于Mysql持久化

SkyWalking默认采用h2的方式，也就是内存来存储监控数据，这样的缺点就是：运行一段时间后很占用内存资源；服务重启后数据丢失；

现在修改为mysql数据库的方式来存储

1. 修改config/application.yml文件，使用mysql作为持久化存储的仓库

   

2. 修改mysql连接信息

   

3. 根据上图中的连接信息创建swtest数据库，然后在SkyWalking服务启动的时候会自动创建数据表。

4. SkyWalking默认情况下它没有mysql连接的jar包，我们需要在我们的项目中找到mysql连接的jar包，放在oap-libs目录下

   

启动SkyWalking后就会发现，给我们刚刚创建的swtest数据库自动创建了很多数据表

我们可以进行测试一下，调用一个接口后，SkyWalking会存储调用链路的信息，然后我们重启SkyWalking服务，就会发现这些信息还存在