为什么需要分布式链路追踪？
服务从单体应用升级到微服务的时候，整个请求的链路会变多，当发生异常、或遇到接口性能瓶颈时。很难将具体的异常日志和具体的请求关联起来，也很难直接定位是哪个调用环节存在性能瓶颈。这个时候就需要一个分布式链路追踪系统来串联调用链，快速定位问题。
更多详情及应用场景，参见 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,ElasticSearchand 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 支持
- java：Java agent
- php ：SkyAPM PHP SDK
- C : cpp2sky
- go：SkyAPM GO2Sky
- lua：LUA agent
- node.js：Node.js agent
- .net：SkyAPM .NET Core agent
- python：Python Agent
- service mesh(服务网格实现)：SkyWalking on Istio 、Envoy Proxy
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
部分公司落地分享资料：
- 【刘嘉鹏】devcon2020-爱番番skywalking实践经验.pdf
- 【宋振东】Apache SkyWalking在小米中的应用.pdf
- 【王院生】SkyWalking 与 Nginx 的优化实践 20201113.pdf
- 【赵禹光】SkyWalking Dev Con 分享贝壳全链路跟踪.pdf
- 【高洪涛】Observability Solutions in Cloud Native-高洪涛.pdf
- 【张鑫】2020-11-14-Connection-Pool.pdf
- 【吴晟】2020-SkyWalking DevCon Open Talk.pdf
分享视频：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/
