浅谈有赞搜索质量保障体系

star2017 15天前 ⋅ 39 阅读

作者:张家瑜

部门:业务中台/测试开发

前言

有赞搜索中台的前身是 ES 中间件,并没有一个中台的概念,相应的就会有一个问题,业务接入搜索场景的时候还需要为此投入开发资源同步搜索设计,一个需求上线往往耗时很久,重复性工作较多,所以就有了后来的搜索中台的成立,将搜索完整链路的复杂性折叠成一个简单完整的搜索产品,让业务方直击搜索需求,无需费心搜索实现;在此前提下,如何针对搜索中台进行一个从 0 到 1 的完整的质量保障也是一个挑战,且中台面临的问题可能跟传统业务面临的不大一样,保障手段也需要更多样化。

一、搜索质量面临的问题及痛点

目前搜索业务架构如下图所示,笼统的说可以分两层,最上面一层协同网络效应层,也就是服务业务层,包括商品、交易、会员、营销、资产这几个核心业务场景,还有外围的零售、教育、美业、直播业务,第二层折叠效应层,将各种底层能力折叠在一起,包括索引写,索引读,索引管理,集群管理,其中集群管理包括双机房同步、索引重建、重载、监控等,依赖的组件不限于 ES,还有 Hbase、DTS、Flink、DP 等;

图片

针对服务应用层、底层能力支撑层都面临着不同的问题,概括的分为三个部分,分别是影响面评估不准、流程规范为零、稳定性较差:

图片

痛点 1:影响面评估不准

服务业务层面临的最大的问题就是业务场景评估,目前有赞搜索业务几乎包含 B 端 C 端大部分核心业务,读场景占比量更大,例如 B 端商品管理页面、订单管理页面、会员业务搜索等,这时候就会遇到一个问题,如果 ES 进行了升级或者底层做了改造,怎样才能保障上游各个业务场景都没有问题,怎样保障回归用例完全覆盖,避免引发业务线上故障,是搜索中台核心要考虑的问题。

痛点 2:底层稳定性较差

这块问题主要集中在底层集群,ES 集群抖动会直接影响上游业务,在搜索前期不仅缺少一系列的监控报警,双机房切换也是纯手工一行一行操作,除此之外搜索涉及到的技术栈不止 ES 组件,还涉及到 Hbase、Flink、DTS、NSQ 等等,期间任何一个组件出现问题都会导致搜索读写异常,线上出现任何波动我们除了重启只能坐以待毙,需要整理出一套见招拆招的紧急预案;除了集群自身的问题,业务方的正确使用也是一个关键点,例如大 in 操作或者数组 oversize 这些如何避免,慢查 query 如何及时检测优化等等。

痛点 3:流程规范为零

有赞搜索中台刚开始是以 ES 中间件为基础一步步搭建起来的,流程规范为零,一条业务线从搭建初始到后面能够正常运转,中间少不了开发跟测试同学之间做好的各种约定,且双方能够很好的执行这些约定才能保障这条业务线的稳定性,搜索中台的业务迭代很复杂,除了一些项目支持、日常支持之外,还会有比较多的压测需求、索引迁移、集群切换等等,针对每个模块都需要制定相应的规范及约定。

为了解决上述痛点,搜索中台质量侧从如下几个方面进行落地实践:

二、多方位保障手段

1 基线用例集补齐

为了保证用例集尽可能的覆盖业务场景,搜索中台的持续集成包括三个部分:流量回放 + 小流量场景补全(ci 集成用例)+ 场景用例执行集;

  • 流量回放:目前搜索主要接流量回放的场景都是读场景,经评估搜索读应用可接入应用 12 个已接入 12 个,涉及读接口 35 个,每个读接口对应的场景都配置相应标签识别,整体可覆盖读场景 80% 以上,但是流量回放有个弊端,能覆盖 80% 的场景,剩余的 20% 的场景因流量太小可能采集不到,这样就需要额外的集成用例补充以保证用例集的完整;

图片

  • CI 集成用例:我们单独搭建了搜索测试工程:bit-search-platform,用以补充剩下的小流量场景用例及异常用例,包括业务层的 ic-search 和 showcase-render,底层的 es-proxy 及 console 等等;

图片

  • 场景用例执行集:以上两种都是针对应用级别的用例,但是如果支持项目的话,需要单独的用例执行集,方便开发自测和测试回归,我们针对几个大模块在接口测试平台补充了相应的核心场景执行集,例如:C 端商品搜索、B 端商品搜索、搜索 BOS 场景等。

图片

2 业务及集群稳定性实践

原架构中底层 es-proxy 承接整个公司的读写流量,不同业务公用一套应用难免就会相互影响,例如商品业务这边有大量读操作过来了,走到 proxy 会把线程池占满,请求会大量堆积在线程队列里无法处理,从而影响其他业务线。此问题是线上偶发问题,在测试环境和压测中会被放大,测试抛出风险推开发出优化方案。优化方案最终采取 dubbo 分组隔离的方式进行业务隔离,如下图:商品业务线走 ic 分组、交易业务线走 trade 分组,这样的话大流量的 C 端商品读并不会影响到交易订单搜索了,实现了业务单元的影响隔离;本次的架构升级给后续的整个搜索业务和集群的稳定性做了不少贡献。

图片

接下来会从三个方面具体介绍搜索稳定性保障:性能专项、演练预案、监控治理:

2.1 性能专项测试

目前搜索业务的性能需求主要分以下三点:

  1. 业务域如交易域和商品域核心索引搜索场景基线 SLA 支持及 es 底层线上单链路摸高;
  2. 各业务方对 ES 千奇百怪的使用方式引发的超时 reject 等进行压测比对(nested 嵌套、multi_search、agg 等);
  3. ES 版本升级时,官方提供的专门针对 ES 集群的压测工具,通过搭建集群环境及不同类型数据的准备,对 ES 单 datanode 和多 datanode 进行压测比对,得出集群整体基线 SLA;

压测过程中共发现性能问题粗略计算下来 26 个,主要集中在强弱依赖,这就涉及到强依赖如何进行兜底、弱依赖如何降级的问题;

图片

图片

下面统计了一下从 2019 年中开始到目前为止通过性能压测手段间接推进落地的一些措施,核心在限流降级:图片图片

2.2 演练及紧急预案

2.2.1 演练

针对异常及故障进行常态化演练,包括 ES 双机房切换演练、索引迁移演练、业务线日常演练,异常演练等等,截止目前为止大大小小的演练执行了大概 18 次,值得一提的双机房切换演练,往年 ES 双机房切换方案无脚本化执行,纯手工敲命令,全靠经验跟临场发挥,切换耗时基本 1 个小时以上,且每次切换必修数据,耗时耗人耗精力,演练的目的是为了快速高效切换,一键脚本化,保障了切换时间保持在 10 分钟内,打破了“ES 一切换必故障”的魔咒!

图片

2.2.2 预案

通过演练以及结合线上问题预估出可能的风险,推进开发进行一些技术改造,配合执行验证预案效果,下图为核心的几个预案:

图片

简单举例:

ES 异常处理 Tips:



ES 集群异常场景大部分都会涉及到一个索引切流到备的操作,我们通过 apollo 配置双机房分流,紧急情况直接切备:

图片

但是如果切备还解决不了问题,就需要对集群做更细粒度操作,问题大致可分为以下几个异常场景:

1、proxy 线程池满

  • 先检查确定问题诱因,proxy 或者 ES 集群,观察 ES 集群是否健康
  • ES 集群问题,处理不过来负载高出现 reject
  • 写 reject 提高吞吐量,修改 refresh_interval(默认 5s)改大
  • 读 reject,增加 proxy 层 Tesla 索引限流
  • 如果某一机器出现 reject,分片迁移,使集群平衡

2、CPU 高负载爆满

  • 清除集群缓存
  • 更改索引刷新时间,将 refresh_interval(默认 5s)调大
  • 切到备机房,将问题索引切到备机房
  • 迁移分片,使集群平衡
  • 针对索引限流,避免影响其他索引,Tesla 限流
  • 重启,某个节点上执行

3、某一节点不可用

  • 切备,单独索引切备
  • 重建索引,导入备份数据

2.3 监控治理

搜索承接将近 300 个的索引,每个索引的慢查或者错误使用都可能会拉高整体集群的 load,所以急需一套完善的监控体系实时监控各条业务线及索引的操作情况;

搜索监控治理主要为事前、事中、事后:

事前监控

ES 慢查统计、Top Query、错误码监控、总体性能指标、操作占比等,这些以天网大盘的形式实时监测,目前总共配置了 11 个大盘,主要是为了提前感知到业务方错误使用的方式和慢查 Query 的业务场景,如下图所示:

图片图片

事中监控

主要包括应用级别监控,底层集群监控,另外还有依赖的中间件监控,Tesla 告警等,主要是应用发布或者集群索引迁移的时候能够及时观测应用及集群情况;

应用级别:L1L2 级别应用已经全部覆盖,告警项有 rt、同比、线程池、KV 及 NSQ 等;

ES 集群:grafana 监控 26 个,告警涉及到每个集群的 CPU、磁盘、bulk 及 search 操作,load 等;

中间件主要有:kv、nsq 配置在应用级别,flink 监控告警配置在任务级别;

此外错误日志治理是 2021 H1 重点,为了提高 error 日志的准确性,降低排查难度,目前 L1 应用 error 量至少降低 60%,报警粒度细化到了场景,例如“获取商品详情异常”、“店铺服务异常”、“美业深翻&value 过长”等等;

图片 图片

经过 2021 年上半年监控告警治理,线上有效 bug 数明显降低,如下图所示:

图片

事后监控

搜索事后监控场景不是很多,事后的线上数据如果有问题肯定也是“木已成舟”,主要包括 BCP 定时对账,即同步链路上 Hbase 与 es 数据对比,还包括一些索引级别的每天读写请求量,大部分是为了统计或后续索引优化提供依据。

3 搜索中台流程规范补全

俗话说:无规矩不成方圆,搜索各项流程的制定也是经历一波阵痛,有不少是依据线上问题和跟研发的合作磨合下一步步补充起来的,如下图所示:

图片

其中在研发提测质量上,搜索中台从搭建初始单测覆盖率为 0,针对这种情况,我们对搜索的应用进行了一个梳理,重新定义各应用的 UT 标准,其中 L1 级别应用增量覆盖率需要达 85%,L2 级别应用增量覆盖率达 75%,杜绝出现无断言或断言过简的情况,通过流程规范的卡点,目前搜索核心应用单测情况:

图片

此外集群切换规范包括切换步骤的梳理及各项 checklist,源于双机房切换演练中的一环,最后落定成统一的集群切换规范;

索引迁移规范包括新老索引切换前后的 check,例如切换索引 topQuery 新集群性能是否符合预期、是否要开始同版本写操作、是否有索引数据一致性保障方案等等。

三、未来展望

搜索现存问题和挑战还有很多,搜索结果排序还达不到灵活精排,搜索分词类目预测,产品词,近义词还比较零散,ES 提供的 ik_max 最细粒度分词能保证足够的召回量,但最细粒度的召回策略无法满足业务需求;所以对测试人员来说,提升搜索 GMV 任重而道远,业务场景也会更复杂,测试面需要更加广泛;智能搜索是未来,搜索算法技术测试方案需要探索落地,搜索保障手段需要更多样化。

最后的最后,有赞数据测试团队在线招人,AI 测试在路上,舞台已备好,欢迎小伙伴的加入!

招募优秀的你加入 👇

图片


本文地址:https://www.6aiq.com/article/1626726634052
本文版权归作者和AIQ共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出

更多内容请访问:IT源点

相关文章推荐

全部评论: 0

    我有话说: