天机阁——全链路跟踪系统设计与实现

首先，我们需要搞清楚天机阁是什么？

天机阁：天机阁是一个以分布式链路跟踪为核心的监控系统

在微服务架构下，由于进行了服务拆分，一次请求往往需要涉及多个服务，每个服务可能是由不同的团队开发，使用了不同的编程语言，还有可能部署在不同的机器上，分布在不同的数据中心。 下面这张图描述了用户访问微博首页，一次请求所涉及的服务（这张图仅作为示意，实际上可能远远比这张图还要复杂），你可以想象如果这次请求失败了，要想查清楚到底是哪个应用导致，会是多么复杂的一件事情。

如果有一个系统，可以跟踪记录一次用户请求都发起了哪些调用，经过哪些服务处理，并且记录每一次调用所涉及的服务的详细信息，这时候如果发生调用失败，你就可以通过这个系统快速定位是在哪个环节出了问题。

我们要对服务调用进行监控，首先要能收集到每一次调用的详细信息，包括调用的响应时间、调用是否成功、调用的发起者和接收者分别是谁，这个过程叫作数据采集。采集到数据之后，要把数据通过一定的方式传输给数据处理中心进行处理，这个过程叫作数据传输。数据传输过来后，数据处理中心再按照服务的维度进行聚合，计算出不同服务的请求量、响应时间以及错误率等信息并存储起来，这个过程叫作数据处理。最后再通过网页管理端的形式对外展示服务的调用情况，这个过程叫作数据展示。 可见，监控系统主要包括四个环节：数据采集、数据传输、数据处理和数据展示，下面依次大致介绍一下：

数据采集

通常情况下有两种数据采集的方式：

• 服务主动上报。这种处理方式通过在业务代码或者服务框架里加入数据收集代码逻辑，在每一次服务调用完成后，主动上报服务的调用信息。
• 代理收集。这种处理方式通过服务调用后把调用的详细信息记录到本地日志文件中，然后再通过代理去解析本地日志文件，然后再上报服务的调用信息。

这里，天机阁采用的是第一种方式。至于为什么呐？别急，先往下看。

  对于数据采集而言，最重要的就是对业务的低侵入，低开销(重点可以平衡一下采样率)(PS：难道真的让业务方去改代码接入吗？这显然是很不现实的)。

  所以天机阁采用的是往服务框架中加入数据收集代码逻辑，这样业务代码不用任何更改即可接入天机阁。所以只有使用了该框架才能够上报数据哦。那么又有一个问题来了，如何做到低侵入，低开销呐？答：采样率，最好是动态控制，在系统负载低的时候加大，在负载高的时候适当降低。天机阁就是这样做的！Google Dapper的实践证明，对于监控系统而言，采样率1/1024都是很正常的。（注意：这里的采样率要求一次请求的多次rpc要么都采样，要么都不采样，不然链路就串不起来， 天机阁在请求入口处进行采样， 采样标识通过带内数据往下游传递，保证一次请求用同一个采样标识。）

更加具体的说明：见文末的参考文章

数据传输

数据传输常用的方式有两种 ：

• UDP 传输。通过 UDP 将采集到的数据发送到数据处理中心，但是这种方式真的很暴力，也没有实现结构上的解耦合。
• Kafka 传输。数据采集后发送到指定的 Topic，然后数据处理单元再订阅对应的 Topic，就可以从 Kafka 消息队列中读取到对应的数据。

数据传输的格式主要还是有两种：二进制协议（PB等）+文本协议 (JSON等)

天机阁基本采用的是：二进制协议 + Kafka 。具体还做了一些优化：将需要上报的Span通过 jce 序列化成二进制，写入本地共享内存无锁队列中，然后由agent来消费共享内存批量上报到 kafka（共享内存无锁队列使用的是 即通 开源的高性能无锁共享内存队列，性能可达800w/s）

这里可能会有疑问的就是：为何不直接上报到 Kafka 呐？却还要经过一个共享内存的缓冲呐？因为这几个字“由agent来消费共享内存批量上报到 kafka”，主要是批量两字。OK，原因找到了。

数据处理

OK，现在数据已经到数据处理中心了，接下来就是如何处理并存储的问题了。

存储之前需要聚合一些东西,具体聚合大致有两个维度：

• 接口维度聚合，这个维度是把实时收到的数据按照接口名维度实时聚合在一起，这样就可以得到每个接口的实时请求量、平均耗时等信息。
• 机器维度聚合，这个维度是把实时收到的数据按照调用的节点维度聚合在一起，这样就可以从单机维度去查看每个接口的实时请求量、平均耗时等信息。

按照文档来看，天机阁应该是按照接口维度聚合的，但我猜测两者应该都有。（说实话，感觉这两个名词更像是有人捏造出来的）

聚合后就需要将数据持久化存储起来。具体天机阁的存储选型见下文。

数据展示

欢迎体验：http://tjgdev.xxx.com/#

以上就是所有监控系统实现必经的所有步骤。接下来，我们来看看实现链路追踪的最根本的原理。具体天机阁的实现见文末链接。

说了这么多，如何数据采集？如何追踪微服务的调用关系？

说到追踪，自然是先拿出鼻祖 Dapper 来看上一遍了：http://bigbully.github.io/Dapper-translation/

先来重复一下几个最基本概念：

• Traceid：用于标识某一次具体的请求 ID。当用户的请求进入系统后，会在 RPC 调用网络的第一层生成一个全局唯一的 traceId，并且会随着每一层的 RPC 调用，不断往后传递，这样的话通过 traceId 就可以把一次用户请求在系统中调用的路径串联起来。

为什么要有这个东西？来看阿里鹰眼的一个举例：

这里的 Traceid 就相当于表示车牌号"鲁123BC"，记录它是为了找出它的行驶路线。天机阁的traceID的唯一性是 Hash(ip+port+时间戳+计数器)形成的一个16字节的 ID。

• Spanid：在每一个Traceid 下，spanid 是唯一的。来看一下美团的这个简单的解释：
  

用于标识一次 RPC 调用在分布式请求中的位置。当用户的请求进入系统后，处在 RPC 调用网络的第一层 A 时 spanId 初始值是 0，进入下一层 RPC 调用 B 的时候 spanId 是 0.1，继续进入下一层 RPC 调用 C 时 spanId 是 0.1.1，而与 B 处在同一层的 RPC 调用 E 的 spanId 是 0.2，这样的话通过 spanId 就可以定位某一次 RPC 请求在系统调用中所处的位置，以及它的上下游依赖分别是谁。

可见，天机阁的 parentid 就相当于是图中的前缀 id（比如0.1.1），原理都是一样的。

• annotation：其他需要的信息（如：耗时，时间关系等等）。

Dapper不是设计用来做链路级的监控的，但是我们发现，它是非常适合去做集群之间网络活动性的应用级任务的分析。Google能够利用Dapper这个平台，建立一个不断更新的控制台，来显示集群之间最活跃的网络流量的应用级的热点。此外，使用Dapper我们能够为昂贵的网络请求提供指出的构成原因的跟踪，而不是面对不同服务器之间的信息孤岛而无所适从。

参考资料：

https://cn.aliyun.com/aliware/news/monitoringsolution
https://mp.weixin.qq.com/s/RBPJFrj2mcTUjbm4aH9TRg
https://www.infoq.cn/article/JF-144XPDqDxxdizdfwT

以上的链接真的得多读几遍啊啊啊啊啊啊啊啊！！！！很珍贵的东西，也不知道是谁发出来的。

ES,HBase，Mysql

ES

es是什么

elasticsearch 简写 es，es 是一个高扩展、开源的全文检索和分析引擎，它可以准实时地快速存储、搜索、分析海量的数据。

什么是全文检索 ( 别名： 倒排索引)

全文检索是指计算机索引程序通过扫描文章中的每一个词，对每一个词建立一个索引，指明该词在文章中出现的次数和位置，当用户查询时，检索程序就根据事先建立的索引进行查找，并将查找的结果反馈给用户的检索方式。这个过程类似于通过字典中的检索字表查字的过程。全文搜索搜索引擎数据库中的数据。

es的应用场景

• 一个线上商城系统，用户需要搜索商城上的商品。
  在这里你可以用es存储所有的商品信息和库存信息，用户只需要输入”空调”就可以搜索到他需要搜索到的商品。

• 一个运行的系统需要收集日志，用这些日志来分析、挖掘从而获取系统业务未来的趋势。
  你可以用logstash（elk中的一个产品，elasticsearch/logstash/kibana）收集、转换你的日志，并将他们存储到es中。一旦数据到达es中，就你可以在里面搜索、运行聚合函数等操作来挖掘任何你感兴趣的信息。

直白点讲，es是一个企业级海量数据的搜索引擎，可以理解为是一个企业级的百度搜索，除了搜索之外，es还可以快速的实现聚合运算。

原文链接：https://blog.csdn.net/Dante_003/article/details/76890218

这里我先加点餐：讲一下存储系统中数据压缩的一些知识

数据压缩

数据压缩分为有损和无损，自然如我们所想的有损的压缩比肯定是高于无损的压缩比的。有损压缩一般用于压缩图片， 音频，视频等。以下只讨论无损压缩。

他妈的，先复习一波Huffman编码：

经过这个编码设置之后我们可以发现，出现频率越高的字符越会在上层，这样它的编码越短；出现频率越低的字符越会在下层，编码越短。经过这样的设计，最终整个文本存储空间才会最大化的缩减。

1977年，以色列人Jacob Ziv和Abraham Lempel发表论文《顺序数据压缩的一-个通用算法》，从此，LZ系列压缩算法几乎垄断了通用无损压缩领域，常用的Gzip算法中使用的LZ77,GIF图片格式中使用的LZW,以及LZO等压缩算法都属于这个系列。设计压缩算法时不仅要考虑压缩比，还要考虑压缩算法的执行效率。Google Bigtable 系统中采用BMDiff和Zippy压缩算法，这两个算法也是LZ算法的变种，它们通过牺牲一定的压缩比，换来执行效率的大幅提升。

• 核心：压缩算法的核心是找重复数据，列式存储技术通过把相同列的数据组织在- -起， 不仅减少了大数据分析需要查询的数据量，还大大地提高了数据的压缩比。（这个还有点不太懂，不急，往下看。）

OLTP 与 OLAP 的介绍

数据处理大致可以分成两大类：

• 联机事务处理OLTP（on-line transaction processing），传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。
• 联机分析处理OLAP（On-Line Analytical Processing）。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。

• OLTP 系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作；
• OLAP 系统则强调数据分析，强调SQL执行时长，强调磁盘I/O，强调分区等。

什么是列式存储？到底有什么好处？如何结合场景使用？

传统的行式数据库将一个个完整的数据行存储在数据页中。如果处理查询时需要用到大部分的数据列，这种方式在磁盘I0上是比较高效的。-般来说，OLTP ( OnlineTransaction Processing, 联机事务处理)应用适合采用这种方式。

但是一个OLAP类型的查询可能需要访问几百万甚至几十亿个数据行，且该查询往往只关心少数几个数据列。例如，查询今年销量最高的前20个商品，这个查询只关心三个数据列:时间(datc)、商品( item)以及销售量( sales amount )。商品的其他数据列，例如商品URL、商品描述、商品所属店铺,等等，对这个查询都是没有意义的。

如图所示，列式数据库是将同一个数据列的各个值存放在-一起。插人某个数据行时，该行的各个数据列的值也会存放到不同的地方。

上例中列式数据库只需要读取存储着“时间、商品、销量”的数据列，而行式数据库需要读取所有的数据列。因此，列式数据库大大地提高了OLAP大数据量查询的效率。

当然，列式数据库不是万能的，每次读取某个数据行时，需要分别从不同的地方读取各个数据列的值，然后合并在一起形成数据行。因此，如果每次查询涉及的数据量较小或者大部分查询都需要整行的数据，列式数据库并不适用。

• 其实就是看你 select 的 列多不多的问题。

很多列式数据库还支持列组( column group, Bigtable 系统中称为locality group),即将多个经常一起访问的数据列的各个值存放在一起。如果读取的数据列属于相同的列组，列式数据库可以从相同的地方一次性读取多个数据列的值，避免了多个数据列的合并。列组是一种行列混合存储模式，这种模式能够同时满足OLTP和OLAP的查询需求。

由于同一个数据列的数据重复度很高，因此，列式数据库压缩时有很大的优势。例如，Google Bigtable列式数据库对网页库压缩可以达到15倍以上的压缩率。另外，可以针对列式存储做专门的索引优化。

比如，性别列只有两个值，“男”和“女"，可以对这一列建立位图索引:

“男”对应的位图为100101,表示第1、4、6行值为“男”;“女”对应的位图为011010,表示第2、3、5行值为“女”。如果需要查找男性或者女性的个数，只需要统计相应的位图中1出现的次数即可。另外，建立位图索引后0和1的重复度高，可以采用专门的编码方式对其进行压缩。

HBase

HBase是一个分布式的、面向列的开源关系型数据库，不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。

实时计算引擎

天机阁的计算任务主要是：（1）两个span的合并。（2）指标数据的统计，如果有异常，就需要实时告警。错误率啥的

这里边知识很多，以后好好学习哦！！