SkyWalking 分布式追踪系统

时间 2019-12-07 标签 skywalking 分布式追踪系统

随着微服务架构的流行，一些微服务架构下的问题也会愈来愈突出，好比一个请求会涉及多个服务，而服务自己可能也会依赖其余服务，整个请求路径就构成了一个网状的调用链，而在整个调用链中一旦某个节点发生异常，整个调用链的稳定性就会受到影响，因此会深深的感觉到 “银弹” 这个词是不存在的，每种架构都有其优缺点。

service map

面对以上状况，咱们就须要一些能够帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，可以快速定位和解决问题，这时候 APM（应用性能管理）工具就该闪亮登场了。

目前主要的一些 APM 工具备: Cat、Zipkin、Pinpoint、SkyWalking，这里主要介绍 SkyWalking ，它是一款优秀的国产 APM 工具，包括了分布式追踪、性能指标分析、应用和服务依赖分析等。

下面是 SkyWalking 6.x 的架构图：

6.x architecture

说明： SkyWalking 的核心是数据分析和度量结果的存储平台，经过 HTTP 或 gRPC 方式向 SkyWalking Collecter 提交分析和度量数据，SkyWalking Collecter 对数据进行分析和聚合，存储到 Elasticsearch、H二、MySQL、TiDB 等其一便可，最后咱们能够经过 SkyWalking UI 的可视化界面对最终的结果进行查看。Skywalking 支持从多个来源和多种格式收集数据：多种语言的 Skywalking Agent 、Zipkin v1/v2 、Istio 勘测、Envoy 度量等数据格式。

总体架构看似模块有点多，但在实际上仍是比较清晰的，主要就是经过收集各类格式的数据进行存储，而后展现。因此搭建 Skywalking 服务咱们须要关注的是 SkyWalking Collecter、SkyWalking UI 和存储设备，SkyWalking Collecter、SkyWalking UI 官方下载安装包内已包含，最终咱们只需考虑存储设备便可。

下面基于 Windows 环境使用 SkyAPM-dotnet 来介绍一下 SkyWalking， SkyAPM-dotnet 是 SkyWalking 的 .NET Agent。

环境要求

JDK8+
Elasticsearch 6.x
8080,10800,11800,12800 端口不被占用

Elasticsearch下载安装参考官方教程，安装完成后须要对 config/elasticsearch.yml 作以下修改：

# 修改
# 若是 cluster.name 不设置为 CollectorDBCluster ，则须要修改 SkyWalking 的配置文件
cluster.name: CollectorDBCluster   
network.host: 0.0.0.0
# 增长
thread_pool.bulk.queue_size: 1000

若是是 linux 环境，Elasticsearch 安装可能没有那么顺利，请参考 Linux 环境下安装 Elasticsearch 5.x、6.x 问题汇总。

下载 SkyWalking

SkyWalking 我的建议直接下载官方编译好的，下载地址

启动 SkyWalking

skywalking config

config/application.yml 的默认数据存储开启是的 h2，这里咱们须要修改数据存储为 Elasticsearch（在启动 SkyWalking 以前，确保 Elasticsearch 已启动）

SkyWalking 的启动包括两部分，一个是 SkyWalking Collector（oapService），一个是 SkyWalking UI（webappService），SkyWalking 解压后的 bin 目录：

skywalking bin

bat 为 windows 环境使用，sh 为 linux 环境使用，咱们能够分别启动 oapService 和 webappService，也能够经过 startup 一次性所有启动，从 startup 中的命令能够知道其实就是分别启动 oapService 和 webappService。

若是一切顺利(不顺利请多看几遍快速入门)，这时候就能够经过 http://localhost:8080 来查看 SkyWalking UI 了（默认全是0，截图是测试效果），默认帐号/密码：admin/admin。

skywalking ui

Java 项目接入

参考部署 skywalking javaagent，skywalking-agent.jar 位于下载包的 agent 目录下，具体效果这里就不测试了

skywalking java agent

.NET 项目接入

这里以 .NET Core 项目来测试，基于 .NET Framework 的项目目前也是支持的，只是相对不完善一些，参考 SkyAPM-dotnet

新建一个.NET Core API 项目，安装 Nuget 包：
```
Install-Package SkyAPM.Agent.AspNetCore
```
添加项目环境变量（实际状况应该是在 CI 流程中设置环境变量，参考：https://github.com/SkyAPM/SkyAPM-dotnet#examples）
```
set ASPNETCORE_HOSTINGSTARTUPASSEMBLIES=SkyAPM.Agent.AspNetCore
```
hostingStartupAssemblies
项目根目录下添加 skyapm.json 文件（来自官方例子），设置为 “若是较新则复制”，添加 SkyWalking 的配置信息，更多默认配置参考。（不过从源码能够看出其实也不须要建立单独的 skyapm.json，直接在 appsettings.json 增长 SkyWalking 节点配置也是没问题的）
```
{
  "SkyWalking": {
    "ServiceName": "WebAPIServiceA", // 服务名
    "Transport": {
      "gRPC": {
        "Servers": "localhost:11800"  // 服务地址
      }
    }
  }
}
```
启动程序，请求的追踪结果就会被记录下来，经过 SkyWalking UI 查看：

skywalking request log

单个服务的效果并不明显，看不出请求跨度、链路关系，下面是一个多服务的例子(下载源码)，依赖关系图以下：

service request map

目前 SkyWalking 的 .NET Agent 还不支持 gRPC 的调用跟踪，整个项目还在不断的完善中，期待后续更多的进展。根据以上的关系图搭建好项目后，访问接口后结果以下：

skywalking spans

一共有4各跨度，先访问 WenAPIServiceA，而后发送 HttpClient 请求，转到 WenAPIServiceB，WenAPIServiceB 执行操做 DB 的命令，每一个跨度的耗时一目了然。

服务关系的拓扑图，调用链路径也很是清晰：

skywalking topology map

参考连接

做者：BeckJin 连接：https://www.jianshu.com/p/2fd56627a3cf 来源：简书简书著做权归做者全部，任何形式的转载都请联系做者得到受权并注明出处。