郑州网络推广网站,wordpress 访问加速,静安建设网站,专门下载工程建设标准的网站1、设计背景
闲鱼目前实际生产部署环境越来越复杂#xff0c;横向依赖各种服务盘宗错节#xff0c;纵向依赖的运行环境也越来越复杂。当服务出现问题的时候#xff0c;能否及时在海量的数据中定位到问题根因#xff0c;成为考验闲鱼服务能力的一个严峻挑战。
线上出现问题…
1、设计背景
闲鱼目前实际生产部署环境越来越复杂横向依赖各种服务盘宗错节纵向依赖的运行环境也越来越复杂。当服务出现问题的时候能否及时在海量的数据中定位到问题根因成为考验闲鱼服务能力的一个严峻挑战。
线上出现问题时常常需要十多分钟甚至更长时间才能找到问题原因因此一个能够快速进行自动诊断的系统需求就应用而生而快速诊断的基础是一个高性能的实时数据处理系统。
这个实时数据处理系统需要具备如下的能力
1、数据实时采集、实时分析、复杂计算、分析结果持久化。 2、可以处理多种多样的数据。包含应用日志、主机性能监控指标、调用链路图。 3、高可靠性。系统不出问题且数据不能丢。 4、高性能底延时。数据处理的延时不超过3秒支持每秒千万级的数据处理。
本文不涉及问题自动诊断的具体分析模型只讨论整体实时数据处理链路的设计。
2、输入输出定义
为了便于理解系统的运转我们定义该系统整体输入和输出如下 输入
服务请求日志包含traceid、时间戳、客户端ip、服务端ip、耗时、返回码、服务名、方法名
环境监控数据指标名称、ip、时间戳、指标值。比如cpu、 jvm gc次数、jvm gc耗时、数据库指标。 输出
一段时间内的某个服务出现错误的根因每个服务的错误分析结果用一张有向无环图表达。根节点即是被分析的错误节点叶子节点即是错误根因节点。叶子节点可能是一个外部依赖的服务错误也可能是jvm异常等等。
3、架构设计
在实际的系统运行过程中随着时间的推移日志数据以及监控数据是源源不断的在产生的。每条产生的数据都有一个自己的时间戳。而实时传输这些带有时间戳的数据就像水在不同的管道中流动一样。 如果把源源不断的实时数据比作流水那数据处理过程和自来水生产的过程也是类似的 自然地我们也将实时数据的处理过程分解成采集、传输、预处理、计算、存储几个阶段。 整体的系统架构设计如下 采集
采用阿里自研的sls日志服务产品包含logtailloghub组件logtail是采集客户端之所以选择logtail是因为其优秀的性能、高可靠性以及其灵活插件扩展机制闲鱼可以定制自己的采集插件实现各种各样数据的实时采集。
传输
loghub可以理解为一个数据发布订阅组件和kafka的功能类似作为一个数据传输通道其更稳定、更安全。
预处理
实时数据预处理部分采用blink流计算处理组件开源版本叫做flinkblink是阿里在flink基础上的内部增强版本。目前常用的实时流计算开源产品有Jstorm、SparkStream、Flink。Jstorm由于没有中间计算状态的其计算过程中需要的中间结果必然依赖于外部存储这样会导致频繁的io影响其性能SparkStream本质上是用微小的批处理来模拟实时计算实际上还是有一定延时Flink由于其出色的状态管理机制保证其计算的性能以及实时性同时提供了完备SQL表达使得流计算更容易。
计算与持久化
数据经过预处理后最终生成调用链路聚合日志和主机监控数据其中主机监控数据会独立存储在tsdb时序数据库中供后续统计分析。tsdb由于其针对时间指标数据的特别存储结构设计非常适合做时序数据的存储与查询。调用链路日志聚合数据提供给cep/graph service做诊断模型分析。cep/graph service是闲鱼自研的一个应用实现模型分析、复杂的数据处理以及外部服务进行交互同时借助rdb实现图数据的实时聚合。
最后cep/graph service分析的结果作为一个图数据实时转储在lindorm中提供在线查询。lindorm可以看作是增强版的hbase在系统中充当持久化存储的角色。
4、设计细节与性能优化 采集
日志和指标数据采集使用logtail整个数据采集过程如图 其提供了非常灵活的插件机制共有四种类型的插件
inputs: 输入插件获取数据。processors: 处理插件对得到的数据进行处理。aggregators: 聚合插件对数据进行聚合。flushers: 输出插件将数据输出到指定 sink。
由于指标数据比如cpu、内存、jvm指标的获取需要调用本地机器上的服务接口获取因此应尽量减少请求次数在logtail中一个input占用一个goroutine。闲鱼通过定制input插件和processors插件将多个指标数据比如cpu、内存、jvm指标在一个input插件中通过一次服务请求获取指标获取接口由基础监控团队提供并将其格式化成一个json数组对象在processors插件中再拆分成多条数据以减少系统的io次数同时提升性能。
传输
数据传输使用LogHublogtail写入数据后直接由blink消费其中的数据只需设置合理的分区数量即可。分区数要大于等于bink读取任务的并发数避免blink中的任务空转。
预处理
预处理主要采用bink实现主要的设计和优化点
1:编写高效的计算流程
blink是一个有状态的流计算框架非常适合做实时聚合、join等操作。 在我们的应用中只需要关注出现错误的的请求上相关服务链路的调用情况因此整个日志处理流分成两个流 a、服务的请求入口日志作为一个单独的流来处理筛选出请求出错的数据。 b、其他中间链路的调用日志作为另一个独立的流来处理通过和上面的流join on traceid实现出错服务依赖的请求数据塞选。 如上图所示通过双流join后输出的就是所有发生请求错误相关链路的完整数据。
2:设置合理的state生存周期
blink在做join的时候本质上是通过state缓存中间数据状态然后做数据的匹配。而如果state的生命周期太长会导致数据膨胀影响性能如果state的生命周期太短就会无法正常关联出部分延迟到来的数据所以需要合理的配置state生存周期对于该应用允许最大数据延迟为1分钟。
使用niagara作为statebackend以及设定state数据生命周期单位毫秒
state.backend.typeniagara
state.backend.niagara.ttl.ms60000 3:开启 MicroBatch/MiniBatch
MicroBatch 和 MiniBatch 都是微批处理只是微批的触发机制上略有不同。原理上都是缓存一定的数据后再触发处理以减少对 state 的访问从而显著提升吞吐以及减少输出数据量。
开启join
blink.miniBatch.join.enabledtrue
使用 microbatch 时需要保留以下两个 minibatch 配置
blink.miniBatch.allowLatencyMs5000
防止OOM每个批次最多缓存多少条数据
blink.miniBatch.size20000 4:动态负载使用 Dynamic-Rebalance 替代 Rebalance
blink任务在运行是最忌讳的就是存在计算热点为保证数据均匀使用Dynamic Rebalance它可以根据当前各subpartition中堆积的buffer的数量选择负载较轻的subpartition进行写入从而实现动态的负载均衡。相比于静态的rebalance策略在下游各任务计算能力不均衡时可以使各任务相对负载更加均衡从而提高整个作业的性能。
开启动态负载
task.dynamic.rebalance.enabledtrue 5:自定义输出插件
数据关联后需要将统一请求链路上的数据作为一个数据包通知下游图分析节点传统的方式的是通过消息服务来投递数据。但是通过消息服务有两个缺点
1、其吞吐量和rdb这种内存数据库相比比还是较大差距大概差一个数量级。 2、在接受端还需要根据traceid做数据关联。
我们通过自定义插件的方式将数据通过异步的方式写入RDB同时设定数据过期时间。在RDB中以数据结构存储。写入的同时只将traceid做为消息内容通过metaQ通知下游计算服务极大的减少了metaQ的数据传输压力。
图聚合计算
cep/graph计算服务节点在接收到metaQ的通知后综合根据请求的链路数据以及依赖的环境监控数据会实时生成诊断结果。诊断结果简化为如下形式 说明本次请求是由于下游jvm的线程池满导致的但是一次调用并不能说明该服务不可用的根本原因需要分析整体的错误情况那就需要对图数据做实时聚合。
聚合设计如下为了说明基本思路做了简化处理 1、首先利用redis的zrank能力为根据服务名或ip信息为每个节点分配一个全局唯一排序序号。 2、为图中的每个节点生成对应图节点编码编码格式 对于头节点头节点序号|归整时间戳|节点编码
对于普通节点|归整时间戳|节点编码 3、由于每个节点在一个时间周期内都有唯一的key因此可以将节点编码作为key利用redis为每个节点做计数。同时消除了并发读写的问题。 4、利用redis中的set集合可以很方便的叠加图的边。 5、记录根节点即可通过遍历还原聚合后的图结构。 聚合后的结果大致如下 这样最终生成了服务不可用的整体原因并且通过叶子节点的计数可以实现根因的排序。
5、收益 系统上线后整个实时处理数据链路的延迟不超过三秒。闲鱼服务端问题的定位时间从十多分钟甚至更长时间下降到五秒内。大大的提升了问题定位的效率。
6、未来展望 目前的系统可以支持闲鱼每秒千万的数据处理能力。后续自动定位问题的服务可能会推广到阿里内部更多的业务场景随之而来的是数据量的成倍增加因此对于效率和成本提出了更好的要求。 未来我们可能做的改进 1、能够自动的减少或者压缩处理的数据。 2、复杂的模型分析计算也可以在blink中完成减少io提升性能。 3、支持多租户的数据隔离。
原文链接 本文为云栖社区原创内容未经允许不得转载。
