个体工商户经营范围网站开发,怎么把电脑网站做服务器吗,网站专题页设计,网站开发课程心得背景
搜索引擎是电商平台成交链路的核心环节#xff0c;搜索引擎的高可用直接影响成交效率。闲鱼搜索引擎作为闲鱼关键系统#xff0c;复杂度和系统体量都非常高#xff0c;再加上闲鱼所有导购场景都依靠搜索赋能#xff0c;搜索服务的稳定可靠成为了闲鱼大部分业务场景可…背景
搜索引擎是电商平台成交链路的核心环节搜索引擎的高可用直接影响成交效率。闲鱼搜索引擎作为闲鱼关键系统复杂度和系统体量都非常高再加上闲鱼所有导购场景都依靠搜索赋能搜索服务的稳定可靠成为了闲鱼大部分业务场景可用能力的衡量标准如何保障搜索服务的稳定和高可用成为了极大的挑战。
闲鱼搜索作为闲鱼核心系统有以下几个突出的特点
数据体量大对接闲鱼数十亿的商品引擎有效商品数亿索引庞大闲鱼非结构化商品需要与算法团队合作预测抽取有价值的结构化信息建立索引已创建数百的索引字段整个引擎索引数据量为T级别增量消息多日常增量消息QPS 数十万峰值QPS可以达到 数百万查询复杂很多特殊业务场景查询条件要求苛刻而复杂比如召回GROUP分组统计聚合/打散/去重关键词复合运算查询等实时性性要求高闲鱼中都是二手商品卖家商品的库存都是1商品上下架频繁对引擎数据的同步更新实时性要求非常高智能化扩展由于闲鱼商品非结构化特性为保障召回数据的效果以及相关性需要引擎具备智能插件扩展的能力能与算法开发人员协同
鉴于闲鱼商品搜索引擎以上主要特点本文详细介绍闲鱼搜索在系统高可用上做的各种努力希望能给读者一些启发。
闲鱼搜索整体架构
正式引出搜索稳定性保障方案之前我们需要对闲鱼搜索技术有一个简单大致的了解
我们比较过很多外部开源的搜索引擎都不能完美支持背景中所列的需求点闲鱼使用的是阿里巴巴最新研发的搜索引擎平台Ha3Ha3是一款非常高效智能强大的搜索引擎它完全满足闲鱼搜索的要求 Elasticsearch是基于Lucene的准实时搜索引擎也是比较常用的开源搜索引擎但是其在算法扩展支撑/绝对实时的能力上与Ha3相差甚远在同等硬件条件下基于1200万数据做单机性能对比测试发现Ha3比ElasticSearch开源系统的QPS高4倍查询延迟低4倍Elasticsearch在大规模数据量场景下的性能和稳定性与HA3相比尚有很大的差距。
01闲鱼搜索体系运行流程
下图是闲鱼搜索体系系统结构图主要分在线和离线两个流程 索引构建流程
索引构建即我们所谓的离线流程其执行者BuildService①负责将不同存储类型的纯文本商品数据构建成搜索引擎格式的索引文件。原始的商品数据有两类一类是存放在存储上的全量商品数据这个定期(一般以天为周期)通过DUMP②产出另一类为实时变更的数据在商品信息变更后由业务系统即时同步给消息系统Swift③。最终分发给在线服务的Searcher④更新索引。
搜索查询流程
搜索查询即我们所谓的在线流程闲鱼搜索服务应用A发起搜索请求通过SP⑤进行服务能力编排首先SP发起QP⑥算法服务调用进行用户意图预测并获取排序辅助信息然后结合QP返回的结果加上业务系统的查询参数向Ha3搜索引擎发起查询请求Ha3搜索引擎QueryService⑦中Qrs⑧接收到查询请求后分发给QueryService中的Searcher进行倒排索引召回、统计、条件过滤、文档打分及排序、摘要生成最后Qrs将Searcher返回的结果进行整合后返回给SPSP经过去重再返回给业务系统
02闲鱼搜索体系团队构成
闲鱼搜索的运维体系是一个相当复杂的构成其中涉及很多团队的鼎力协作
首先必须有Ha3搜索引擎团队在底层提供核心的搜索引擎能力支持主要负责Ha3搜索引擎核心能力的建设维护提供并维护引擎运维操作平台和实时引擎搜索服务。 然后是算法团队在Ha3搜索引擎上进行定制优化用户搜索体验对闲鱼非结构化的商品通过算法模型进行理解预测抽取出结构化信息供搜索引擎商品索引使用监控维护QP集群服务开发并使用Ha3引擎排序插件进行召回数据分桶实验验证调优。 最后是我们业务工程团队串联整个搜索流程监控维护整个搜索链路的可用性主要维护搜索对接的数据Ha3搜索引擎接入管理进行SP搜索服务编排制定合理的查询计划以及闲鱼搜索统一在线查询服务的研发维护工作。 本文亦是从业务工程团队的工作角度出发阐述如何对复杂搜索业务系统进行稳定性的保障
稳定性治理
01部署架构优化
独立网关部署
Ha3引擎通过SP提供基于HTTP协议的搜索服务API对类似闲鱼这样复杂的搜索场景每个闲鱼上层的业务如果都通过拼接SP HTTP接口参数的形式来使用搜索服务所有上游业务都需要关心SP的拼接语法会使开发成本剧增而且如果由于特殊原因SP进行了语法调整或者不兼容升级那么所有上层业务都需要修正逻辑这样的设计不合理为了让业务系统与搜索系统完全解耦并且提高搜索服务的易用性闲鱼搜索通过统一的业务搜索网关来提供简单一致的分布式服务供闲鱼各上层搜索业务使用并与SP对接屏蔽掉SP对上游业务系统的穿透 最开始闲鱼搜索服务与其他很多不相关的业务场景共建在一个比较庞大的底层应用中这种部署方式对稳定性要求很高的业务模块来说有非常大的安全隐患 1.各业务模块会相互影响存在一定程度的代码耦合同时还涉及机器资源的竞争风险比较高 2.应用太过庞大严重影响开发协作的效率和代码质量 于是将闲鱼搜索服务部署到独立的容器分组新增应用A供闲鱼搜索服务专用作为各业务使用搜索服务的独立网关同时对接下游的SP搜索服务保证服务是隔离和稳定的。 前后部署图如下所示 多机房容灾部署
在最初闲鱼商品搜索服务对接的Ha3搜索引擎只部署在一个机房当此机房出现比较严重的问题时对上游业务影响非常大甚至会引发故障鉴于此对闲鱼商品搜索引擎的在线离线集群进行双机房部署容灾在详细展开之前我们先大致理解下Ha3引擎DUMP流程的原理 如上图所示Ha3引擎DUMP流程大致流程可以简单分为以下几步
准备源数据评估业务需求将需要接入引擎的数据准备好一般业务数据大部分都是DB数据表也有少数的ODPS⑨离线数据表算法团队提供的数据绝大部分都是ODPS离线数据表DUMP拉取数据通过Ha3引擎团队提供的运维平台可以将这些表的某些数据字段接入到创建好的搜索引擎中后续DUMP执行的时候Ha3离线引擎会拉取这些接入的表字段数据形成一份引擎自用的镜像数据表在这一步中我们可以使用引擎团队提供的UDF工具对数据进行清洗/过滤等处理数据Merge引擎将所有的镜像表数据通过我们指定的主键进行Join最终形成一份数据大宽表供引擎创建索引使用这一步数据Join后还可以对最终的数据通过UDF进行进一步的清洗/过滤处理验证通过的数据才会进入到大宽表创建更新索引Ha3离线引擎通过buildService使用大宽表的数据与事先我们在Ha3引擎运维平台指定好的索引Schame对齐重新构建索引
以上流程可以通过Ha3引擎运维平台手动触发执行执行完上述流程后会生成一份新的索引新的索引集群服务可用后在线实时模块会将查询服务切换到新的索引集群上完成一次索引的更新这个完整流程我们将其称之为全量 全量完成后当系统有新的商品信息变动且相应的数据表有启用实时更新(我们称之为增量功能,DB表是通过binlog/ODPS表是通过Swift消息通知的方式实现)则离线DUMP引擎会感知到此次变动进而将相应的镜像数据表中商品数据更新并会按上述离线DUMP流程中的步骤将这个改动信息一直向引擎上层投递直至成功更新引擎索引中的相应数据或者中途被系统规则丢弃为止这个实时数据更新的流程我们称之为增量增量更新还有一条通道算法同学可以使用特殊的方式通过Swift增量消息的方式直接将需要更新的数据不通过DUMP流程直接更新到Ha3引擎索引中。 闲鱼商品量飞速增长目前已经达到数十亿接入了数百的索引字段由于闲鱼商品非结构化的原因索引字段中只有一小部分供业务使用另外大部分都是算法接入的索引比如大量抽出来的标签数据向量化数据等这些向量化数据非常大最终的情形表现为闲鱼商品搜索引擎的DUMP处理逻辑比较复杂而且索引数据总量异常庞大增量消息量也处在非常高的水位再加上闲鱼商品单库存的现状因此对数据更新的实时性要求非常高这些都给稳定性带来了极大的制约。 索引数据是搜索引擎的内容核心如果进入引擎的索引数据有问题或者新变更的数据没有更新到引擎索引中将直接影响搜索服务的质量 搜索引擎单机房部署期间时常会因为一些不稳定的因素导致DUMP全量失败或者增量延迟甚至停止一旦引擎DUMP出现问题需要恢复基本都很困难很多场景下甚至需要重新跑全量才能解决问题但是闲鱼商品索引数据体量较大做一次全量往往要大半天没有办法快速止血对业务造成了较大的影响于是对搜索引擎进行双机房部署容灾(M/N机房)互为备份 两个离线DUMP机房采用相同的引擎配置和相同的数据源产出相同的索引数据分别供两个在线机房使用两个机房的在线流量比例也可以按需实时调整当M机房出现不可逆问题时自动或手动将流量全部切换到N机房实现线上快速止血然后再按部就班排查解决M机房的问题。
下图为最终的搜索机房部署情况 进行引擎双机房部署虽然增大了机器资源成本但是除了上述业务容灾优点外还有以下好处
引擎需求的发布之前缺乏有效的灰度流程当搜索引擎有重大变更/升级出现高风险的发布时可以先在单机房小流量beta测试数据对比验证通过后再发布到另一个机房平常单机房能支撑全部搜索查询业务的流量当遇到大促或大型活动时将两个机房同时挂载提供服务这样搜索服务能力和容量直接能翻倍避免了单机房频繁扩缩容的困扰性能评估时可以单独对未承载流量的机房进行压测即使由于压测导致宕机也不会对线上业务造成影响
02流量隔离
上文独立网关部署一节中讲到闲鱼搜索通过统一的业务搜索网关来提供简单一致的分布式服务供闲鱼各上层搜索业务使用使用统一的微服务就必然带来上游不同业务优先级和可靠性保障的问题。 闲鱼搜索服务支撑了种类繁多的上游业务为了统一对各业务场景的流量/服务质量进行度量和管理在上游业务接入闲鱼搜索服务时需要申请使用相应的业务来源这个业务来源标示会伴随着整个搜索查询的生命周期在日志采集时直接使用从而可以针对业务维度进行监控告警实时感知业务运行的健康情况(简单监控视图如下图)也可以对具体业务进行流量管控降级限流等 搜索业务来源生命周期图
03分级监控体系
对高稳定性系统当出现问题或者即将产生问题时能即时感知显得尤为重要方便实时进行跟踪处理防止继续扩大目前使用的主要手段是建立健全完善的多维度监控告警体系
引擎基础服务监控
使用监控可以快速发现问题如果监控的粒度够细还能进行问题的快速定位不过有时也会存在误报或者漏报的情况因此真实的监控一定要结合每个业务自身系统的特性梳理出关键链路针对关键链路进行多维度360度无死角监控并且进行合理的预警规则设置监控预警才会比较有效
闲鱼搜索引擎在线离线流程/各上游重要应用系统的核心链路上建立了完备的日志数据采集模块对关键指标进行了精准的监控预警设置做到任何问题都能及时被感知到。下图是搜索服务相应核心日志以及监控告警情况。 模拟用户行为的在线业务监控
上文提到闲鱼搜索引擎索引体量比较大需要很多团队共同协作搜索流程复杂度比较高而且有算法同学的加入对闲鱼非结构化的商品做了很多AI识别加上闲鱼都是单库存商品对引擎实时性要求非常高前面已经做了一些容灾的保障方案但是对实时性的感知上还需要更进一步才能及时知道数据的准确情况是否存在更新延迟以及延迟时间大概是多久等一系列健康度信息 解法是从业务层面进行实时性的监控告警提取出闲鱼商品量比较大更新也比较频繁的类目K在闲鱼的后台业务系统中通过jkeins间隔一定时间时间步长可以实时调整使用类目K作为关键词和品类根据商品更新时间索引降序招回模拟用户轮询的方式发送搜索查询请求召回满足要求的第一页商品然后根据引擎召回数据的商品更新时间与当前系统时间进行差值比对大于阈值时长可以实时调整说明存在较严重的数据更新延迟则进行告警信息发送
04压测
全链路压测
对搜索服务以及各上游业务系统进行全链路压测改造并使用线上真实的用户请求构造大批量的压测数据在保证不影响线上业务正常进行的前提下验证链路在超大流量模型下系统的容量和资源分配是否合理找到链路中的性能瓶颈点验证网络设备和集群容量。
引擎单链路压测
Ha3搜索引擎在线流程支持通过回放线上高峰时段查询流量的方式进行引擎在线服务性能压测。 Ha3搜索引擎离线流程支持通过回放一段时间Swift增量消息的方式进行引擎DUMP增量性能压测。
05灰度发布
闲鱼商品的非结构化特性离不开算法赋能在我们的研发周期中与两个算法团队相当多的算法同学保持着深度合作给闲鱼搜索带来了跨越式的发展但是在团队协作和研发效率上也给我们带来了极大的挑战。
算法团队、引擎团队、加上业务工程团队非常大的搜索项目开发小组每周都有非常多的新算法模型新的引擎改造新的业务模块需要上线。 大量的新增逻辑改动直接上线会带来很多问题首先是代码层面虽然预发环境有做充分测试但也难保没有边缘逻辑存在测试遗漏的情况即使预发测试都完全覆盖但线上和预发终究环境不同线上大流量环境及有可能会暴露一些隐藏的代码问题第二方面假使代码没有任何质量问题但所有功能全部绑定上线所有逻辑都混杂在一起如何评定某个模块上线后的效果成为极大的困扰特别是算法模型的优化和业务上新模式的尝试都需要根据详细的效果反馈数据指标来指导进行下一步的优化方向 因此急需一套灰度实验保障体系不仅可以用来协调和隔离整个搜索业务中各个模块做到对各模块进行单独的效果评估并且还能提高大家的协作效率让各模块能进行快速试错快速迭代 为了解决以上非常重要的问题业务工程团队开发了一套实验管理系统用来进行搜索实验灰度调度管理系统功能如上图所示其具有以下特点。
实验灵活方便一个实验可以包含多个实验组件一个实验组件可供多个实验使用一个实验组件又可以包含多个实验分桶各页面模块的实验都可以在系统中实时调控包括实验的开/关以及实验之间的关系处理搜索实验埋点全链路打通统计各种实验数据报表统计数据接入了闲鱼门户和通天塔可查看各个指标不同分桶的实验曲线提升实验迭代速度提升算法/业务效率快速试错加速搜索成交转化的增长
06应急预案
根据评估分析或经验对搜索服务中潜在的或可能发生的突发事件的关键点事先制定好应急处置方案当满足一定的条件时进行多维度多层级的自动降级限流或者配置手动预案进行人工干预
任何时候发现线上问题首先需要快速止血避免问题的扩大具有自动预案会自动发现问题自动熔断我们需要密切关注系统的运行情况防止反弹若出现反弹并且对业务有较大影响时快速人工介入执行降级预案完成止血后再详细排查具体原因当短时间无法确定问题根源时如在问题出现时有过变更或发布则第一时间回滚变更或发布。 对系统中各级的依赖服务熔断降级已经系统负载保护我们使用的是阿里巴巴自主研发的资源调用控制组件Sentinel[4]目前已经开源或者也可以使用Hytrix降级限流工具
07问题排查
将闲鱼搜索链路接入阿里搜索问题排查平台搜索实时查询请求的各个步骤输入的参数信息/产出的数据信息都会在此工具平台详细展示方便各种问题的排查跟进以及数据信息对比
可以对各查询条件下各个分桶的实验召回数据进行可视化显示方便各个实验间的效果对比以及每个召回商品的各类细节信息查看包括业务数据和算法标签数据还包含每个商品对应的各引擎插件算分情况都能详细阅览 还可以根据商品Id卖家Id卖家Nick进行商品索引信息的披露可以排查相应商品在引擎索引中的详细数据如果数据和预想的有出入具体是离线DUMP哪一步的处理逻辑导致的状态异常都能一键查询。 接入此问题排查平台后能非常直观的掌握引擎的运行状况搜索召回的链路状态对快速发现问题根源即时修复问题都有非常重大的作用
总结与展望
本文主要介绍闲鱼如何保障复杂场景下搜索引擎服务的稳定性主要从架构部署隔离性容量评估风险感知管控等方面进行阐述介绍了如何稳定支撑20线上搜索业务场景做到了快速发现恢复线上问题高效提前预知规避风险案例50极大程度提升了搜索服务的用户体验保障了闲鱼搜索全年无故障
经过上述治理方案后闲鱼搜索系统稳定性得到了极大的保障同时我们也会继续深耕在搜索能力的高可用、更易用上更进一步让上游业务更加顺滑 希望给各位读者带来一些思考和启发。 原文链接 本文为云栖社区原创内容未经允许不得转载。
