为什么需要分布式链路追踪?
服务从单体应用升级到微服务的时候,整个请求的链路会变多,当发生异常、或遇到接口性能瓶颈时。很难将具体的异常日志和具体的请求关联起来,也很难直接定位是哪个调用环节存在性能瓶颈。这个时候就需要一个分布式链路追踪系统来串联调用链,快速定位问题。
更多详情及应用场景,参见 Google 分布式链路追踪论文 :《Dapper,大规模分布式系统的跟踪系统》
相关方案对比
方案 |
|
|
|
|
|
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 支持
- 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/
slack:https://the-asf.slack.com/join/shared_invite/zt-kcq6ba3p-Zjf1BvfpYzQu_kFQ99jefQ#/
QQ群:392443393