为什么需要分布式链路追踪？
服务从单体应用升级到微服务的时候，整个请求的链路会变多，当发生异常、或遇到接口性能瓶颈时。很难将具体的异常日志和具体的请求关联起来，也很难直接定位是哪个调用环节存在性能瓶颈。这个时候就需要一个分布式链路追踪系统来串联调用链，快速定位问题。
更多详情及应用场景，参见 Google 分布式链路追踪论文 ：《Dapper，大规模分布式系统的跟踪系统》
相关方案对比
| 方案 |
Jaeger |
zipkin |
Apache skyWalking |
CAT |
Pinpoint |
Elastic APM |
| 开发语言 |
Go |
Java |
Java |
Java |
Java |
Go |
| Github Star |
12.7k+ |
13.9K+ |
15.9k+ |
14.9k+ |
11.1k+ |
800+ |
| Github contributors |
191 |
146 |
313 |
77 |
99 |
53 |
| Github open lssue/close Issue/PR |
340 / 948 / 1399 |
132 / 1600 / 2101 |
61 / 3069 / 3122 |
107 / 974 / 1008 |
147 / 2891 / 4523 |
111 / 874 / 3647 |
| 背后公司或组织 |
CNCF、Uber |
Apache、Twitter |
Apache |
美团 |
NAVER |
Elastic |
| 侵入性 |
中 |
高 |
低 |
高 |
低 |
很低 |
| OpenTracing兼容 |
是 |
是 |
是 |
否 |
否 |
不完善 |
| 客户端支持语言 |
Java、 Go、 Python. Node.js、 C+＋和C# |
Java, PHP, Go, Python, .NET， Ruby, |
Java, PHP, Go, C++, Node.js, Python, .NET, Lua, |
Java, Go, C/C++, Node.js, Python, |
Java, PHP, Python |
Java, PHP， Go, Node.js, Python, .Net, Ruby, |
| UI丰富度 |
中 |
中 |
较高 |
高 |
高 |
中 |
| 监控报警 |
无，需结合其它工具实现 |
无，需结合其它工具实现 |
支持 |
支持 |
支持 |
支持 |
| 二次开发难度 |
低 |
中 |
中 |
高 |
高 |
高 |
| 存储类型 |
Memory, Cassandra, Elasticsearch, Kafka |
Memory, Cassandra, ElasticSearch and MysQL |
Memory( H2 )、 ElasticSearch, MySQL、 TiDB、 infulxdb |
HDFS |
HBase |
Elasticsearch |
github 数据截止 2021-1-25 日
分布式链路追踪：skywalking
skywalking 是一个完整实现了 Google 分布式链路追踪论文所述功能的开源项目，最新的 skywalking 版本实现了作者发表的《STAM(流拓扑分析方法)》论文中的设计，该论文指出了Jaeger、zipkin 在分析服务拓扑方法的局限性，以及如何使用流拓扑分析的方法显著降低负载和内存成本。skywalking 的目标，是针对微服务、Cloud Native、容器化架构，提供应用性能监控和分布式调用链追踪能力。而且做到了在开启100%采样下，非常低的性能消耗 ，基于这些特点，以及下面这些特性，决定先采用 skywalking 作为链路追踪系统，如果有更好的替代方案欢迎在下方讨论
skywalking架构
如下图，skywalking 整个架构可分为五个模块：
- agent ：各种语言、和框架适配的无缝接入探针，以及部分语言本身没有探针特性，也会提供集成的SDK支持手动集成
- recelver：数据收集器，agent探针获取的调用链上下文数据会通过 grpc 或者 kafka 投递到数据收集器，支持各种协议的 trace 数据（包括 trace 规范协议、以及主流 trace 系统客户端sdk数据），metrics 数据收集，以及针对 service mesh 场景有单独实现收集器
- aggregator：多个跨进程系统来源数据聚合、分析、关联
- storage：最终落地持久化，落地数据库可选 es、tidb、influxdb、mysql、h2、shardingsphere
- web ui：采用 vue 实现的 前后端分离的 ui，界面美观
功能特性
1、trace 数据协议支持丰富
在 trace 数据收集方面，skywalking 支持了如下的 Trace 协议数据格式上报分析
- opentracing
- Jaeger
- zipkin
- skywalking 协议
文档地址：backend-receivers.md
2、开发语言支持丰富
虽然 skywalking 是 java 语言实现的链路追踪项目，但是在客户端 sdk 集成方面，几乎覆盖了主流开发语言。java 等部分支持动态织入的应用可以通过 agent 探针技术无感集成，其他语言也均有完善的 sdk 支持
3、探针性能优异
从测验结果看，增加链路追踪，几乎不影响业务服务的吞吐，只会增加一点资源消耗
![]()
测验项目地址：https://github.com/SkyAPMTest/Agent-Benchmarks
4、ui 完善美观
服务拓扑
![]()
服务链路
![]()
响应排名，热点图等
![]()
参考线上体验 demo：http://demo.skywalking.apache.org/ 用户名：skywalking 密码：skywalking
5、架构灵活、不侵入业务
skywalking 在架构设计上，oapServer 是无状态的支持横向扩展，超大规模流量下，只要后端存储模块(elasticsearch)能够 hold 住，支撑 100% 的 trace 采样率没啥问题。而且，大部分语言的集成实现，支持无缝集成，不侵入业务，探针的可定制化程度高，trace 追踪力度可配置追踪每个内部 service 方法级别。支持 opentracing 协议以及自定义埋点的数据收集。经初步测验，oapServer 在处理能力不足、或者直接宕机的情况下，均不影响业务服务
6、社区活跃，企业用户多，对这个项目足够了解
skywalking 自开源以来，博主一直在关注这个项目，曾写过源码级的原理分析博文。作者吴晟早期在华为从事 apm 相关的工作，skywalking 最早是他个人主导的开源项目，随后捐献给 Apache 开源组织，并从 Apache 成功孵化毕业，最后成为 Apache 基金会顶级项目，。对 skywalking 内部的代码架构设计比较了解。曾经也给 skywalking 社区贡献过代码，截至目前已有三百多个代码贡献者，迭代到了8.x的版本。国内有很多公司采用 skywalking 搭建性能分析 、链路追踪系统
![]()
更多企业用户：https://github.com/apache/skywalking-website/blob/master/data/homepage.yml
部分公司落地分享资料：
分享视频：https://skywalking.apache.org/zh/2020-11-23-devcon/
结语
Apache 的项目，虽然功能迭代和发版会经过严格的测试流程、发版表决流程，但是之前一直采用的 skywalking5.x 的版本，最新的版本到了8.x,功能增强了很多，ui 也更加美观了，整体变化比较大，所以先准备在小范围业务、部分流量尝试使用。
skywalking 相关资源
github：https://github.com/apache/skywalking
官网：https://skywalking.apache.org/
slack：https://the-asf.slack.com/join/shared_invite/zt-kcq6ba3p-Zjf1BvfpYzQu_kFQ99jefQ#/
QQ群：392443393
