闲鱼目前实际生产部署环境越来越复杂，横向依赖各种服务盘宗错节，纵向依赖的运行环境也越来越复杂。当服务出现问题的时候，能否及时在海量的数据中定位到问题根因，成为考验闲鱼服务能力的一个严峻挑战。

线上出现问题时常常需要十多分钟，甚至更长时间才能找到问题原因，因此一个能够快速进行自动诊断的系统需求就应用而生，而快速诊断的基础是一个高性能的实时数据处理系统。这个实时数据处理系统需要具备如下的能力：

本文不涉及问题自动诊断的具体分析模型，只讨论整体实时数据处理链路的设计。

为了便于理解系统的运转，我们定义该系统整体输入和输出。

一段时间内的某个服务出现错误的根因，每个服务的错误分析结果用一张有向无环图表达。（根节点即是被分析的错误节点，叶子节点即是错误根因节点。叶子节点可能是一个外部依赖的服务错误也可能是jvm异常等等）。

在实际的系统运行过程中，随着时间的推移，日志数据以及监控数据是源源不断的在产生的。每条产生的数据都有一个自己的时间戳。而实时传输这些带有时间戳的数据就像水在不同的管道中流动一样。

如果把源源不断的实时数据比作流水，那数据处理过程和自来水生产的过程也是类似的： 

自然地，我们也将实时数据的处理过程分解成采集、传输、预处理、计算、存储几个阶段。

整体的系统架构设计如下：

采用阿里自研的sls日志服务产品（包含logtail+loghub组件），logtail是采集客户端，之所以选择logtail是因为其优秀的性能、高可靠性以及其灵活插件扩展机制，闲鱼可以定制自己的采集插件实现各种各样数据的实时采集。

loghub可以理解为一个数据发布订阅组件，和kafka的功能类似，作为一个数据传输通道其更稳定、更安全。

详细对比文章参考：

https://yq.aliyun.com/articles/35979?spm=5176.10695662.1996646101.searchclickresult.6f2c7fbe6g3xgP

实时数据预处理部分采用blink流计算处理组件（开源版本叫做flink，blink是阿里在flink基础上的内部增强版本）。目前常用的实时流计算开源产品有Jstorm、SparkStream、Flink。

• Jstorm由于没有中间计算状态的，其计算过程中需要的中间结果必然依赖于外部存储，这样会导致频繁的io影响其性能；

• SparkStream本质上是用微小的批处理来模拟实时计算，实际上还是有一定延时；

• Flink由于其出色的状态管理机制保证其计算的性能以及实时性，同时提供了完备SQL表达，使得流计算更容易。

数据经过预处理后最终生成调用链路聚合日志和主机监控数据，其中主机监控数据会独立存储在tsdb时序数据库中，供后续统计分析。tsdb由于其针对时间指标数据的特别存储结构设计，非常适合做时序数据的存储与查询。

调用链路日志聚合数据，提供给cep/graph service做诊断模型分析。cep/graph service是闲鱼自研的一个应用，实现模型分析、复杂的数据处理以及外部服务进行交互，同时借助rdb实现图数据的实时聚合。

最后cep/graph service分析的结果作为一个图数据，实时转储在lindorm中提供在线查询。lindorm可以看作是增强版的hbase，在系统中充当持久化存储的角色。

日志和指标数据采集使用logtail，整个数据采集过程如图：

其提供了非常灵活的插件机制，共有四种类型的插件：

由于指标数据（比如cpu、内存、jvm指标）的获取需要调用本地机器上的服务接口获取，因此应尽量减少请求次数，在logtail中，一个input占用一个goroutine。

闲鱼通过定制input插件和processors插件，将多个指标数据（比如cpu、内存、jvm指标）在一个input插件中通过一次服务请求获取（指标获取接口由基础监控团队提供），并将其格式化成一个json数组对象，在processors插件中再拆分成多条数据，以减少系统的io次数同时提升性能。

数据传输使用LogHub，logtail写入数据后直接由blink消费其中的数据，只需设置合理的分区数量即可。分区数要大于等于blink读取任务的并发数，避免blink中的任务空转。

预处理主要采用blink实现，主要的设计和优化点：

1）编写高效的计算流程

blink是一个有状态的流计算框架，非常适合做实时聚合、join等操作。在我们的应用中只需要关注出现错误的的请求上相关服务链路的调用情况，因此整个日志处理流分成两个流：

如上图所示通过双流join后，输出的就是所有发生请求错误相关链路的完整数据。

blink在做join的时候本质上是通过state缓存中间数据状态，然后做数据的匹配。而如果state的生命周期太长会导致数据膨胀影响性能，如果state的生命周期太短就会无法正常关联出部分延迟到来的数据，所以需要合理的配置state生存周期，对于该应用允许最大数据延迟为1分钟。

MicroBatch和MiniBatch都是微批处理，只是微批的触发机制上略有不同。原理上都是缓存一定的数据后再触发处理，以减少对state的访问从而显著提升吞吐，以及减少输出数据量。

blink任务在运行是最忌讳的就是存在计算热点，为保证数据均匀使用Dynamic Rebalance，它可以根据当前各subpartition中堆积的buffer的数量，选择负载较轻的subpartition进行写入，从而实现动态的负载均衡。相比于静态的rebalance策略，在下游各任务计算能力不均衡时，可以使各任务相对负载更加均衡，从而提高整个作业的性能。

数据关联后需要将统一请求链路上的数据作为一个数据包通知下游图分析节点，传统的方式的是通过消息服务来投递数据。但是通过消息服务有两个缺点：

我们通过自定义插件的方式将数据通过异步的方式写入RDB，同时设定数据过期时间。在RDB中以<traceid,相关链路请求数据json style="box-sizing: border-box;">数据结构存储。写入的同时只将traceid做为消息内容通过metaQ通知下游计算服务，极大的减少了metaQ的数据传输压力。</traceid,相关链路请求数据json>

cep/graph计算服务节点在接收到metaQ的通知后，综合根据请求的链路数据以及依赖的环境监控数据，会实时生成诊断结果。诊断结果简化为如下形式：

说明本次请求是由于下游jvm的线程池满导致的，但是一次调用并不能说明该服务不可用的根本原因，需要分析整体的错误情况，那就需要对图数据做实时聚合。

聚合设计如下（为了说明基本思路，做了简化处理）：

聚合后的结果大致如下：

这样最终生成了服务不可用的整体原因，并且通过叶子节点的计数可以实现根因的排序。

系统上线后，整个实时处理数据链路的延迟不超过三秒。闲鱼服务端问题的定位时间从十多分钟甚至更长时间下降到五秒内。大大的提升了问题定位的效率。

目前的系统可以支持闲鱼每秒千万的数据处理能力。后续自动定位问题的服务可能会推广到阿里内部更多的业务场景，随之而来的是数据量的成倍增加，因此对于效率和成本提出了更好的要求。

未来我们可能做的改进：