1、微服务带来的问题

微服务框架带来的好处十分多，比如说它提高了开发的效率，它具备更好的扩展性。可是微服务其实是一把双刃剑，微服务同时也带来了一些问题，比如：

故障定位难
容量预估难
资源浪费多
链路梳理难

而这些问题也就是我们的鹰眼系统需要解决的问题。

2、鹰眼是什么

鹰眼是一个以链路追踪技术为核心的监控系统，它主要的手段是通过收集、存储、分析分布式系统中的调用事件数据，协助开发运营人员进行故障诊断、容量预估、性能瓶颈定位以及调用链路梳理。

EagleEye（鹰眼）：是分布式调用跟踪系统，就是对一次前端请求产生的分布式调用都汇总起来作分析。
TraceId: 是标明一次前端请求的全局唯一的调用链ID。在前端请求到达到服务器时，应用容器在执行实际业务处理之前，会先根据EagleEye的埋点逻辑，生成TraceId。

3、实现原理

3.1 TranceID

在一套中间件里做统一埋点，在分布式调用框架、分布式消息系统、缓存系统、统一接入层、Web 框架层的发送与接收请求的地方做统一埋点，埋点的数据能够被一套中间件在系统之间进行无缝透传。

当用户的请求进来的时候，鹰眼在第一个接收到这个请求的服务器的中间件会生成唯一的 TraceID，这个 TraceID 会随着每一次分布式调用透传到下游的系统当中，所有透传的事件会存储在 RPC log 文件当中。随后鹰眼会有一个中心化的处理集群把所有机器上的日志增量地收集到集群当中进行处理，处理的逻辑比较简单，就是做了简单清洗后再倒排索引。只要系统中报错，然后把 TraceID 作为异常日志当中的关键字打出来，就可以看到这次调用在系统里面经历了哪些事情，我们通过 TraceID 其实可以很容易地看到这次调用是卡在 B 到 C 的数据库调用，它超时了，通过这样的方式我们可以很容易追溯到这次分布式调用链路中问题到底出在哪里。其实通过 TraceId 我们只能够得到上面这张按时间排列的调用事件序列，我们希望得到的是有嵌套关系的调用堆栈。

3.2 TraceID + RPCID

要想还原调用堆栈，我们还需要另外一个东西叫做 RPCId(在 OpenTracing 中有类似的概念，叫做 SpanID)，RPCId 是一个多维序列。它经过第一次链路的时候初始值是 0，它每进行一次深入调用的时候就变成 0.1，然后再升就是 0.1.1，它每进行一次同深度的调用，就是说 A 调完 B 以后又调了 D 就会变成 0.2，RPCId 也随着本次调用被打印至同一份 RPC Log 中，连同调用事件本身和 TraceId 一起被采集到中心处理集群中一起处理。

收集完了以后，鹰眼对所有调用事件按照 RPCId 进行一个深度遍历，就可以获得这样的一个调用堆栈，上图中的调用堆栈实际上就是真实的淘宝交易系统里面进行下单的交易调用堆栈，可以看到这次调用经历了很多系统。但我们在鹰眼的视角上面来看，就好像是在本地发生的一样，可以很容易地去看到如果一次调用出现了问题，那问题的现象是出现在哪里，最后问题的根因又是发生在了哪里。除了调用异常的返回码之外，在右边其实还可以看到每次调用的耗时是多少，我们也可以看到每一次调用是慢在哪里。这张图中解释了鹰眼是如何解决微服务四大问题中的故障定位难的问题，它可以通过倒排索引，让用户反查出每一次调用的全貌是怎样的。

3.3 根据指定Tag统计调用次数

如果我们对万亿级别的调用链数据进行聚合，是否能够获得更有价值的信息？我们可以看一下，每一次调用除了它唯一标识 TraceID 和 RPCID 之外，还包含了一些标签信息 (Tag)，什么是标签呢？就是具备共性的, 大家都会有的这么一些信息。比如说这次调用它分别经历了哪些系统，这些系统它每次调用的 IP 是什么，经过哪个机房，服务名是什么？有一些标签是可以通过链路透传下去的，比如入口 url，它透传下去以后我就知道这次请求在下去之后发生的每一次事件都是由通过这个入口去发起的，那么如果把这些标签进行聚合计算，我们可以得到调用链统计的数据，例如按某机房标签统计调用链，我们就可以得到每个机房的调用次数的趋势图。

这样做有什么好处呢？实际上在容量预估当中这样做的好处是非常明显的。我们来看一个例子，假如我们有一个交易下单入口标签，我们对这样的标签做了聚合以后，不光能看到单次调用它的情况是如何，还能看到将这些调用链数据聚合以后，它的总调用次数是多少，平均耗时是多少，我可以发现系统当中热点瓶颈在哪里，同时我们可以发现一些非法流量，也就是说我之前不知道的事。