分布式追踪系统之我见
source link: https://blog.yuantops.com/tech/thoughts_on_distributed_tracing_system/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
分布式追踪系统之我见
一切的开始
古早的时候，没人需要分布式追踪系统。大家系统架构简单，功能直来直去，有问题就看日志、查问题。
后来，微服务流行起来。之前的模式，被称作“单体架构”。微服务粒度更小了，以前一个接口做的事，现在要拆散成很多部分，再通过相互调用组合到一起。系统更瘦了，但是管理起来更难了。
当我有 10 个微服务时，出了故障还可以排查。如果有成千上万个微服务呢？随着时间发展，微服务之间的依赖会越来越复杂，一个接口背后可能是几十上百个微服务调用，没人能搞懂了。
大家意识到，需要一个能展示整条调用链路情况的辅助系统。
Google Dapper
这时候，Google 公开了一篇论文 Dapper - a Large-Scale Distributed Systems Tracing Infrastructure，介绍他们的分布式追踪技术。这篇文章提出了科学的分布式追踪模型，仿佛一盏指路明灯，此后几乎所有实现，都遵循这个模型。
基于这篇论文，有了 Zipkin(Twitter 开源), 有了 OpenTracing。国内阿里鹰眼，也在概念上有借鉴。
分布式追踪系统
一般而言，分布式追踪系统分为三部分，采集、上报、落盘与分析。
采集: 对于已经存在大量系统，在代码中进行改造，工作量将相当可观，不现实。明智做法，是从中间件着手，力求侵入更小、开发者无感知。如果是 dubbo 调用，最合适是统一升级 dubbo jar 包。
上报：先把日志打印到本地，然后公共 agent 采集上报。
落盘与存储：数据采集上来后，可以做很多事情。最简单的，放到 HBase + ElasticSearch，支持按 traceId 搜索。复杂点，接入流计算引擎，实时计算相关指标。
我真的需要它吗
直说我的看法：
如果你的系统调用链深度顶多三层，依赖外部系统才一两个，常规日志监控手段足矣，分布式追踪系统并不是必须品。
如果当前你的系统已经按微服务组织起来，但没有使用统一维护的中间件，那应该先改造现有系统，把中间件收敛起来，再统一升级。
不错的参考资料
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK