实时文章采集(0服务出现错误的根因服务的设计方法与设计 )

　　实时文章采集(0服务出现错误的根因服务的设计方法与设计

)

　　0 1 背景

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

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

　　1、数据实时采集，实时分析，计算复杂，分析结果持久化。

　　2、 可以处理各种各样的数据。收录应用日志、主机性能监控指标和调用链接图。

　　3、高可靠性。系统没有问题，数据不会丢失。

　　4、高性能，底部延迟。数据处理时延不超过3秒，支持每秒千万级数据处理。

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

　　02 I/O 定义

　　为了便于理解系统的运行，我们将系统的整体输入输出定义如下：

　　输入：

　　服务请求日志（包括traceid、时间戳、客户端ip、服务器ip、耗时、返回码、服务名、方法名）

　　环境监测数据（指标名称、ip、时间戳、指标值）。比如cpu、jvm gc次数、jvm gc耗时、数据库指标。

　　输出：

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

　　03 建筑设计

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

　　

　　如果将源源不断的实时数据比作自来水，数据处理过程类似于自来水生产的过程：

　　

　　当然，我们也将实时数据处理分解为采集、传输、预处理、计算和存储阶段。

　　整体系统架构设计如下：

　　

　　采集

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

　　传输

　　loghub可以理解为数据发布订阅组件，功能类似于kafka，作为数据传输通道，更稳定安全，详细对比文章参考：

　　预处理

　　实时数据预处理部分使用blink流计算处理组件（开源版本称为flink，blink是阿里巴巴内部基于flink的增强版）。目前常用的实时流计算开源产品有Jstorm、SparkStream、Flink。由于Jstorm没有中间计算状态，其计算过程中需要的中间结果必须依赖外部存储，这会导致频繁的io影响其性能； SparkStream本质上是用小批量来模拟实时计算，但实际上还是有一定的延迟； Flink 以其优秀的状态管理机制保证了其计算的性能和实时性，并提供了完整的 SQL 表达式，使得流计算更容易。

　　计算和持久性

　　数据经过预处理后，最终生成调用链路聚合日志和主机监控数据。主机监控数据会独立存储在tsdb时序数据库中，供后续统计分析。由于对时间指标数据的特殊存储结构设计，tsdb非常适合时间序列数据的存储和查询。调用链接日志聚合数据，提供给cep/graph服务进行诊断模型分析。 cep/graph service是闲鱼开发的一款应用，实现模型分析、复杂数据处理以及与外部服务的交互，借助rdb实现图数据的实时聚合。

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

　　04 详细设计和性能优化

　　采集

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

　　

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

　　由于指标数据（如cpu、内存、jvm指标）的获取需要调用本机的服务接口，所以尽量减少请求的数量。在 logtail 中，一个输入占用一个 goroutine。闲鱼通过自定义输入插件和处理器插件，通过服务请求（指标获取接口由基础监控团队提供）在一个输入插件中获取多个指标数据（如cpu、内存、jvm指标），并将其格式化为一个json数组对象在处理器插件中被拆分成多条数据，以减少系统中io的数量，提高性能。

　　传输

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

　　预处理

　　预处理主要通过blink实现，主要设计和优化点：

　　写一个高效的计算过程

　　blink是一个有状态的流计算框架，非常适合实时聚合、join等操作。

　　在我们的应用中，我们只需要注意对有错误请求的相关服务链接的调用，所以整个日志处理流程分为两个流程：

　　1、服务的请求入口日志作为单独的流处理，过滤掉请求错误的数据。

　　2、其他中间环节的调用日志作为另一个独立的流处理。通过在traceid上加入上述流，实现了错误服务所依赖的请求数据的插入。

　　

　　如上图所示，双流join后，输出的是与请求错误相关的所有链接的完整数据。

　　设置合理的状态生命周期

　　blink本质上是在做join的时候通过state缓存中间数据状态，然后再匹配数据。如果状态的生命周期过长，会造成数据膨胀，影响性能。如果状态的生命周期太短，将无法正确关联一些延迟的数据。因此，需要合理配置状态生命周期，并允许该应用的最大数据延迟。 1 分钟。

　　使用niagara作为statebackend，以及设定state数据生命周期，单位毫秒

state.backend.type=niagara

state.backend.niagara.ttl.ms=60000

　　打开 MicroBatch/MiniBatch

　　MicroBatch 和 MiniBatch 都是 micro-batch，但 micro-batch 的触发机制略有不同。原则上，在触发处理前缓存一定量的数据，减少对状态的访问，从而显着提高吞吐量，减少输出数据量。

　　开启join

blink.miniBatch.join.enabled=true

使用 microbatch 时需要保留以下两个 minibatch 配置

blink.miniBatch.allowLatencyMs=5000

防止OOM，每个批次最多缓存多少条数据

blink.miniBatch.size=20000

　　对动态负载使用动态再平衡而不是再平衡

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

　　开启动态负载

task.dynamic.rebalance.enabled=true

　　自定义输出插件

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

　　1、与rdb等内存数据库相比，它的吞吐量还是有很大差距（差一个数量级左右）。

　　2、在接收端，也需要根据traceid进行数据关联。

　　我们通过自定义插件异步向RDB写入数据，同时设置数据过期时间。存储在 RDB 中的数据结构中。编写时只使用traceid作为消息内容，通过metaQ通知下游计算服务，大大降低了metaQ的数据传输压力。

　　图形聚合计算

　　收到metaQ的通知后，cep/graph计算服务节点会根据请求的链路数据和依赖的环境监测数据实时生成诊断结果。诊断结果简化如下：

　　

　　表示这个请求是由下游jvm的线程池满造成的，但是一次调用并没有说明服务不可用的根本原因。分析整体的错误情况，需要对图数据进行实时聚合。

　　聚合设计如下（为了说明基本思想而进行了简化）：

　　1、首先利用redis的zrank能力，根据服务名或者ip信息给每个节点分配一个全局唯一的序号。

　　2、为图中的每个节点生成对应的图节点代码，代码格式：

　　- 对于头节点：头节点序号 |圆形时间戳 |节点代码

　　- 对于普通节点：|圆形时间戳 |节点编码

　　3、由于每个节点在一个时间段内都有唯一的key，所以可以使用节点代码作为key来统计每个节点使用redis。同时消除了并发读写的问题。

　　4、在redis中使用set集合可以很方便的叠加图的边。

　　5、记录根节点，通过遍历恢复聚合图结构。

　　汇总结果大致如下：

　　

　　这样，最终产生了服务不可用的整体原因，可以通过叶子节点的数量对根本原因进行排序。

　　05 收益

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

　　06 展望

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

　　未来可能的改进：

　　1、处理后的数据可以自动缩减或压缩。

　　2、复杂的模型分析计算也可以瞬间完成，减少io，提高性能。

　　3、支持多租户数据隔离。