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、H2、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。

环境要求

1. JDK8+
2. Elasticsearch 6.x
3. 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

1. 新建一个.NET Core API 项目，安装 Nuget 包：

   Install-Package SkyAPM.Agent.AspNetCore
   

2. 添加项目环境变量（实际情况应该是在 CI 流程中设置环境变量，参考：https://github.com/SkyAPM/SkyAPM-dotnet#examples）

   set ASPNETCORE_HOSTINGSTARTUPASSEMBLIES=SkyAPM.Agent.AspNetCore
   

   

   hostingStartupAssemblies

3. 项目根目录下添加 skyapm.json 文件（来自官方例子），设置为 “如果较新则复制”，添加 SkyWalking 的配置信息，更多默认配置参考。（不过从源码可以看出其实也不需要创建单独的 skyapm.json，直接在 appsettings.json 增加 SkyWalking 节点配置也是没问题的）

   {
     "SkyWalking": {
       "ServiceName": "WebAPIServiceA", // 服务名
       "Transport": {
         "gRPC": {
           "Servers": "localhost:11800"  // 服务地址
         }
       }
     }
   }
   

4. 启动程序，请求的追踪结果就会被记录下来，通过 SkyWalking UI 查看：

   

   skywalking request log

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

service request map

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

skywalking spans

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

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

skywalking topology map

参考链接

• Apache SkyWalking
• SkyWalking-github
• SkyWalking-dotnet
• SkyWalking-sample

      </div>