jkeins宣布php技巧_阿里巴巴复杂搜索系统的靠得住性优化之路

搜索引擎是电商平台成交链路的核心环节，搜索引擎的高可用直接影响成交效率。
闲鱼搜索引擎作为闲鱼关键系统，繁芜度和系统体量都非常高，再加上闲鱼所有导购场景都依赖搜索赋能，搜索做事的稳定可靠成为了闲鱼大部分业务场景可用能力的衡量标准；如何保障搜索做事的稳定和高可用成为了极大的寻衅。

闲鱼搜索作为闲鱼核心系统，有以下几个突出的特点：

鉴于闲鱼商品搜索引擎以上紧张特点，本文详细先容闲鱼搜索在系统高可用上做的各种努力，希望能给读者一些启示。

闲鱼搜索整体架构

正式引出搜索稳定性保障方案之前，我们须要对闲鱼搜索技能有一个大略大致的理解；

我们比较过很多外部开源的搜索引擎，都不能完美支持背景中所列的需求点；闲鱼利用的是阿里巴巴最新研发的搜索引擎平台Ha3，Ha3是一款非常高效，智能强大的搜索引擎，它完备知足闲鱼搜索的哀求；

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返回的结果进行整合后返回给SP，SP经由去重再返回给业务系统；

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流程大致流程可以大略分为以下几步：

以上流程可以通过Ha3引擎运维平台手动触发实行，实行完上述流程后，会天生一份新的索引；新的索引集群做事可用后，在线实时模块会将查询做事切换到新的索引集群上，完成一次索引的更新；这个完全流程我们将其称之为\"大众全量\"大众；

全量完成后，当系统有新的商品信息变动，且相应的数据表有启用实时更新(我们称之为增量功能,DB表是通过binlog/ODPS表是通过Swift关照的办法实现)，则离线DUMP引擎会感知到这次变动，进而将相应的镜像数据表中商品数据更新，并会按上述离线DUMP流程中的步骤，将这个改动信息一贯向引擎上层投递，直至成功更新引擎索引中的相应数据，或者中途被系统规则丢弃为止；这个实时数据更新的流程我们称之为\"大众增量\公众；增量更新还有一条通道：算法同学可以利用分外的办法，通过Swift增量的办法直接将须要更新的数据不通过DUMP流程，直接更新到Ha3引擎索引中。

闲鱼商品量飞速增长，目前已经达到数十亿；接入了数百的索引字段，由于闲鱼商品非构造化的缘故原由，索引字段中只有一小部分供业务利用；其余大部分都是算法接入的索引，比如大量抽出来的标签数据，向量化数据等，这些向量化数据非常大；终极的环境表现为闲鱼商品搜索引擎的DUMP处理逻辑比较繁芜，而且索引数据总量非常弘大，增量量也处在非常高的水位，再加上闲鱼商品单库存的现状；因此对数据更新的实时性哀求非常高，这些都给稳定性带来了极大的制约。

索引数据是搜索引擎的内容核心，如果进入引擎的索引数据有问题，或者新变更的数据没有更新到引擎索引中，将直接影响搜索做事的质量；

搜索引擎单机房支配期间，时常会由于一些不稳定的成分，导致DUMP全量失落败，或者增量延迟，乃至停滞；一旦引擎DUMP涌现问题，须要规复基本都很困难，很多场景下乃至须要重新跑全量才能办理问题；但是闲鱼商品索引数据体量较大，做一次全量每每要大半天，没有办法快速止血，对业务造成了较大的影响；于是对搜索引擎进行双机房支配容灾(M/N机房)，互为备份；

两个离线DUMP机房采取相同的引擎配置和相同的数据源，产出相同的索引数据，分别供两个在线机房利用，两个机房的在线流量比例也可以按需实时调度；当M机房涌现不可逆问题时，自动或手动将流量全部切换到N机房，实现线上快速止血，然后再按部就班排查办理M机房的问题。

下图为终极的搜索机房支配情形；

进行引擎双机房支配虽然增大了机器资源本钱，但是除了上述业务容灾优点外，还有以下好处；

02流量隔离

上文独立网关支配一节中讲到，闲鱼搜索通过统一的业务搜索网关来供应大略同等的分布式做事，供闲鱼各上层搜索业务利用；利用统一的微做事，就一定带来上游不同业务优先级和可靠性保障的问题。

闲鱼搜索做事支撑了种类繁多的上游业务，为了统一对各业务场景的流量/做事质量进行度量和管理，在上游业务接入闲鱼搜索做事时，须要申请利用相应的业务来源，这个业务来源标示会伴随着全体搜索查询的生命周期；在日志采集时直策应用，从而可以针对业务维度进行监控告警，实时感知业务运行的康健情形(大略监控视图如下图)，也可以对详细业务进行流量管控，降级限流等；

搜索业务来源生命周期图

03分级监控体系

对高稳定性系统，当涌现问题，或者即将产生问题时，能即时感知，显得尤为主要；方便实时进行跟踪处理，防止连续扩大；目前利用的紧张手段是建立健全完善的多维度监控告警体系；

引擎根本做事监控

利用监控可以快速创造问题，如果监控的粒度够细还能进行问题的快速定位；不过有时也会存在误报或者漏报的情形，因此真实的监控一定要结合每个业务自身材系的特性，梳理出关键链路，针对关键链路进行多维度360度无去世角监控，并且进行合理的预警规则设置，监控预警才会比较有效；

闲鱼搜索引擎在线离线流程/各上游主要运用系统的核心链路上，建立了完备的日志数据采集模块，对关键指标进行了精准的监控预警设置；做到任何问题都能及时被感知到。
下图是搜索做事相应核心日志以及监控告警情形。

仿照用户行为的在线业务监控

上文提到，闲鱼搜索引擎索引体量比较大，须要很多团队共同协作，搜索流程繁芜度比较高；而且有算法同学的加入，对闲鱼非构造化的商品做了很多AI识别，加上闲鱼都是单库存商品，对引擎实时性哀求非常高；前面已经做了一些容灾的保障方案；但是对实时性的感知上还须要更进一步，才能及时知道数据的准确情形，是否存在更新延迟，以及延迟韶光大概是多久等一系列康健度信息；

解法是从业务层面进行实时性的监控告警；提取出闲鱼商品量比较大更新也比较频繁的类目K，在闲鱼的后台业务系统中，通过jkeins间隔一定韶光（韶光步长可以实时调度），利用类目K作为关键词和品类，根据商品更新韶光索引降序招回，仿照用户轮询的办法发送搜索查询要求，召回知足哀求的第一页商品；然后根据引擎召回数据的商品更新韶光与当前系统韶光进行差值比对，大于阈值时长（可以实时调度）解释存在较严重的数据更新延迟，则进行告警信息发送；

04压测

全链路压测

对搜索做事以及各上游业务系统进行全链路压测改造；并利用线上真实的用户要求布局大批量的压测数据，在担保不影响线上业务正常进行的条件下，验证链路在超大流量模型下系统的容量和资源分配是否合理，找到链路中的性能瓶颈点，验证网络设备和集群容量。

引擎单链路压测

Ha3搜索引擎在线流程，支持通过回放线上高峰时段查询流量的办法，进行引擎在线做事性能压测。

Ha3搜索引擎离线流程，支持通过回放一段韶光Swift增量的办法，进行引擎DUMP增量性能压测。

05灰度发布

闲鱼商品的非构造化特性，离不开算法赋能；在我们的研发周期中，与两个算法团队，相称多的算法同学保持着深度互助；给闲鱼搜索带来了超过式的发展，但是在团队协作和研发效率上也给我们带来了极大的寻衅。

算法团队、引擎团队、加上业务工程团队，非常大的搜索项目开拓小组，每周都有非常多的新算法模型，新的引擎改造，新的业务模块须要上线。

大量的新增逻辑改动直接上线，会带来很多问题；首先是代码层面，虽然预发环境有做充分测试，但也难保没有边缘逻辑存在测试遗漏的情形；纵然预发测试都完备覆盖，但线上和预发究竟环境不同，线上大流量环境及有可能会暴露一些隐蔽的代码问题；第二方面，假使代码没有任何质量问题，但所有功能全部绑定上线，所有逻辑都殽杂在一起，如何评定某个模块上线后的效果成为极大的困扰，特殊是算法模型的优化，和业务上新模式的考试测验，都须要根据详细的效果反馈数据指标来辅导进行下一步的优化方向；

因此急需一套灰度实验保障体系，不仅可以用来折衷和隔离全体搜索业务中各个模块，做到对各模块进行单独的效果评估；并且还能提高大家的协作效率，让各模块能进行快速试错，快速迭代；

为理解决以上非常主要的问题，业务工程团队开拓了一套实验管理系统，用来进行搜索实验灰度调度管理，系统功能如上图所示；其具有以下特点。

06应急预案

根据评估剖析或履历，对搜索做事中潜在的或可能发生的突发事宜的关键点，事先制订好应急处置方案；当知足一定的条件时进行多维度多层级的自动降级限流，或者配置手动预案进行人工干预；

任何时候创造线上问题，首先须要快速止血，避免问题的扩大；具有自动预案会自动创造问题，自动熔断，我们须要密切关注系统的运行情形，防止反弹；若涌现反弹，并且对业务有较大影响时，快速人工参与实行降级预案；完成止血后再详细排查详细缘故原由，当短韶光无法确定问题根源时，如在问题涌现时有过变更或发布，则第一韶光回滚变更或发布。

对系统中各级的依赖做事，熔断降级已经系统负载保护，我们利用的是阿里巴巴自主研发的资源调用掌握组件Sentinel[4]，目前已经开源；或者也可以利用Hytrix降级限流工具；

07问题排查

将闲鱼搜索链路接入阿里搜索问题排查平台，搜索实时查询要求的各个步骤输入的参数信息/产出的数据信息都会在此工具平台详细展示，方便各种问题的排查跟进，以及数据信息比拟；

可以对各查询条件下各个分桶的实验召回数据进行可视化显示，方便各个实验间的效果比拟；以及每个召回商品的各种细节信息查看，包括业务数据和算法标签数据，还包含每个商品对应的各引擎插件算分情形，都能详细阅览；

还可以根据商品Id，卖家Id，卖家Nick进行商品索引信息的表露；可以排查相应商品在引擎索引中的详细数据，如果数据和预想的有出入，详细是离线DUMP哪一步的处理逻辑导致的状态非常，都能一键查询。

接入此问题排查平台后，能非常直不雅观的节制引擎的运行状况，搜索召回的链路状态；对快速创造问题根源，即时修复问题都有非常重大的浸染！

总结与展望

本文紧张先容闲鱼如何保障繁芜场景下搜索引擎做事的稳定性，紧张从架构支配，隔离性，容量评估，风险感知&管控等方面进行阐述，先容了如何稳定支撑20+线上搜索业务场景，做到了快速创造规复线上问题，高效提前预知规避风险案例50+，极大程度提升了搜索做事的用户体验，保障了闲鱼搜索整年无端障；

经由上述管理方案后，闲鱼搜索系统稳定性得到了极大的保障，同时我们也会连续深耕，在搜索能力的高可用、更易用上更进一步，让上游业务更加顺滑；

希望给各位读者带来一些思考和启示。

本文作者：元茂