微服务架构下的链路追踪与APM组件解析-优快云博客

本文链接：https://blog.youkuaiyun.com/Cavan_C/article/details/114531744

背景

mcd

从单体应用转化为微服务应用，服务按照不同的维度进行拆分，一次请求往往需要涉及多个服务。服务应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发，各团队使用的编程语言也可能不一样，应用可能部署在成百上千台服务器，横跨多个不同的数据中心。

这就造成了微服务架构模式下存在以下几个问题：

如何快速发现问题？
如何判断故障影响范围？
如何梳理服务依赖以及依赖的合理性？
如何分析链路性能问题以及实时容量规划？

Google Dapper几个基础概念

Span：基本工作单元，一次链路调用（可以是RPC、DB等没有特定的限制）创建一个span，通过一个64位id标识它，uuid较为方便，span中还有其他的数据，例如描述信息、时间戳、key-value对的（Annotation）tag信息、parent-id等，其中parent-id可以表示span调用链路来源。

上图说明了span在一次大的追踪过程中是什么样的。Dapper记录了span名称，以及每个span的id和父id，以重建在一次追踪过程中不同span之间的关系。如果一个span没有父id被称为root span。所有span都挂在一个特定的追踪上，也共用一个跟踪id。

Span数据结构：

type Span struct {
    TraceID    int64 // 用于标示一次完整的请求id
    Name       string
    ID         int64 // 当前这次调用span_id
    ParentID   int64 // 上层服务的调用span_id  最上层服务parent_id为null
    Annotation []Annotation // 用于标记的时间戳
    Debug      bool
}

Trace：类似于树结构的Span集合，表示一条完整调用链路，从请求到服务器开始，服务器返回response结束，跟踪每次rpc调用的耗时，存在唯一标识trace_id。比如：你运行的分布式大数据存储一次Trace就由你的一次请求组成。

trace

上图描绘了Trace在系统的样子，每种颜色的note标注了一个span，一条链路通过TraceId唯一标识，Span标识发起的请求信息。树节点是整个架构的基本单元，而每一个节点又是对span的引用。节点之间的连线表示Span和它父Span直接的关系。虽然Span在日志文件中只是简单的代表Span的开始和结束时间，他们在整个树形结构中却是相对独立的。

Annotation：注解，用来记录请求特定事件相关信息（例如时间），通常包含四个注解信息：

1）CS：Client Start，表示客户端发起请求；

2）SR：Server Receive，表示服务端收到请求

3）SS：Server Send，表示服务端完成处理，并将结果发送给客户端

4）CR：Client Received，表示客户端获取到服务端返回的信息

Annotation数据结构：

type Annotation struct {
    Timestamp int64
    Value     string
    Host      Endpoint
    Duration  int32
}

链路跟踪组件比较

市场上的APM（Application Performance Management）理论模型大多都是借鉴Google Dapper论文，本文重点关注一下几种APM组件：

Zip：由Twitter公司开发，开放源代码分布式的跟踪系统，用于收集服务的定时数据，以解决微服务架构中的延迟问题，包括数据的收集、存储、查找和展现；
Pinpoint：是一款对Java编写的大规模分布式系统的APM工具，由韩国人开源的分布式跟踪组件；
Skywalking：国产的优秀APM组件，是一个对Java分布式应用程序集群的业务运行情况进行追踪、告警和分析的系统；
其他的类似组件还有美团的CAT，淘宝的鹰眼EgleEye。

综上所述，我们选择链路监控组件有哪些要求呢？Dapper中也提到了，总结如下：

性能损耗：APM组件服务的影响应该做到足够小。在一些高度优化过的服务，即使一点点损耗也会很容易察觉到，而且有可能迫使在线服务的部署团队不得不将跟踪系统关停；
代码的侵入性：对于应用的程序员来说，是不需要知道有跟踪系统这回事的，如果一个跟踪系统想生效，就必须需要依赖应用的开发者主动配合，那么这个跟踪系统就太脆弱了，往往由于跟踪系统在应用中植入代码的BUG或者疏忽导致应用出问题，这样才是无法满足对跟踪系统"无所不在的部署"这个需求；
可扩展性：能够支持的组件越多越好，或者提供便捷的插件开发API，对于一些没有监控到的组件，应用开发者也可以自行扩展；
数据的分析：数据的分析要快，分析的维度尽可能多。跟踪系统能提供足够快的信息反馈，就可以对生产环境下的异常状况作出快速反应。分析的全面，避免二次开发。