分布式调用链监控

背景

                                                                                                                                 

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

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

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

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在系统的样子，每种颜色的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，对于一些没有监控到的组件，应用开发者也可以自行扩展；
• 数据的分析：数据的分析要快，分析的维度尽可能多。跟踪系统能提供足够快的信息反馈，就可以对生产环境下的异常状况作出快速反应。分析的全面，避免二次开发。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Skywalking优势

• 开源的APM（应用性能监控）项目，Apache顶级项目
• Java自动探针，开源生态支持.NetCore、NodeJS、PHP等多语言
• 对应用代码无侵入
• 超高的探针性能，在5000tps应用上，额外CPU消耗低于10%
• 支持在生产级别的100%分布式调用链采样
• 全方位支持拓扑图、服务性能指标、分布式调用链和告警

Skywalking项目历史

• 2016年构建开源内核
• Java探针内核，使用至今
• 综合多家商业APM公司经验以及Google Dapper论文后，设计内核协议
• 2017年加入Apache孵化器，成为中国首个个人项目加入Apache
• 2018年开始广泛使用于生产环境
• 2019年毕业成为Apache顶级项目

客户群

        超过100家公司公开宣布正在使用Skywalking。包括阿里云、华为、当当、东方航空、微众银行、招商银行等。

 

 

 

参考：

• Google Dapper中文翻译
• 全链路监控（一）：方案概述与比较
• 各大厂分布式链路跟踪系统架构对比