作者|

本文介绍了如何设计搜索引擎系统的稳定性保证解决方案。

背景

搜索引擎是电子商务平台交易链接的核心链接，搜索引擎的高可用性直接影响交易效率。作为的关键系统，搜索引擎具有很高的复杂性和系统尺寸。此外，所有购物指南方案都依赖于搜索搜索能力。搜索服务的稳定性和可靠性已成为对西雅最多业务方案的可用性功能的衡量。如何确保搜索服务的稳定性和高可用性已成为一个巨大的挑战。

作为的核心系统，搜索具有以下突出特征：

鉴于产品搜索引擎的上述主要特征，本文详细介绍了搜索在系统中的各种努力，希望为读者提供一些灵感。

武搜索整体体系结构

在正式引入搜索稳定性保证计划之前，我们需要对搜索技术有一个简单而粗略的了解。

我们已经比较了许多外部开源搜索引擎，但是它们都无法完美地支持背景中列出的要求。 使用阿里巴巴最新的搜索引擎平台HA3。 HA3是一种非常有效，智能和功能强大的搜索引擎，完全满足了搜索的要求。

它是基于准实时的搜索引擎，也是一个相对常用的开源搜索引擎，但是它扩展算法/绝对实时的能力远非HA3。在相同的硬件条件下，基于1200万个数据的单机器性能比较测试，HA3比开源系统的QPS高4倍，查询延迟的速度低4倍。大规模数据量场景中的性能和稳定性仍然远远落后于HA3。

搜索系统操作过程

下图是搜索系统结构图，该图主要分为两个过程：

索引施工过程

索引构造是我们所谓的离线过程。其执行人①负责以搜索引擎格式构建不同存储类型的纯文本产品数据。原始产品数据有两种类型。一个是存储在存储中的全部产品数据。这种周期性（通常是在周期中）通过DUMP②产生，另一个是实时数据。更改产品信息后，业务系统将立即将其同步到消息系统。 ④更新索引最终分发给在线服务。

搜索查询过程

搜索查询是我们所说的在线流程。 搜索服务应用程序启动搜索请求，并通过SP⑤安排服务功能。

首先，SP启动QP⑥算法服务调用，进行用户意图预测，并获得对辅助信息进行排序；

然后，结合QP返回的结果和业务系统的查询参数，向HA3搜索引擎启动了查询请求。

HA3搜索引擎⑦收到查询请求后，将将QRS⑧分发给搜索引擎，以执行倒置索引召回，统计，条件过滤，文档评分，分类和抽象生成；

最后，QRS集成了返回的结果并将其返回到SP，而SP在重复数据删除后将其返回到服务系统。

武搜索系统团队组成

的操作和维护系统是一个非常复杂的结构，涉及许多团队的强大合作。

首先，HA3搜索引擎团队必须在底部提供核心搜索引擎功能支持，这主要负责HA3搜索引擎核心功能的构建和维护，并提供和维护引擎操作以及维护操作平台以及实时引擎搜索服务。

然后是在HA3搜索引擎上自定义的算法团队，优化了用户搜索体验，通过算法模型了解的非结构化产品，可以预测和提取结构化信息，用于搜索引擎产品索引。监视和维护QP群集服务，开发和使用HA3引擎分类插件，进行召回数据存储桶实验，并进行验证和调整。

最后，我们的业务工程团队连接整个搜索过程并监视整个搜索链接的可用性。主要维护搜索对接，HA3搜索引擎访问管理，SP搜索服务编排，制定合理的查询计划的数据，以及 的统一在线查询服务的研究，开发和维护。

本文还解释了如何从业务工程团队的工作角度确保复杂搜索业务系统的稳定性。

稳定治理

部署体系结构优化

独立的网关部署

HA3引擎通过SP提供了基于HTTP协议的搜索服务API。对于诸如之类的复杂搜索场景，如果每个上层业务使用搜索服务通过介绍SP HTTP接口参数，则所有上游服务都需要关心SP的剪接语法，这将大大增加开发成本。此外，如果SP具有语法调整或由于特殊原因而不兼容和升级，那么所有高级企业都需要纠正逻辑，这是不合理的。

为了使搜索系统的业务系统完全使业务系统完全解除，千元搜索通过统一的业务搜索网关为的高级搜索服务提供了简单，一致的分布式服务，并与SP与SP连接以阻止SP的上游商务系统的渗透。

一开始，搜索服务是在相对较大的基础应用程序中构建的，其中许多其他无关的业务场景。这种部署方法对具有高稳定性要求的业务模块具有很大的安全风险：

因此，将搜索服务部署到独立的容器分组中，并为搜索服务添加了应用A，该应用程序被用作每个业务使用搜索服务的独立网关。同时，它连接到下游SP搜索服务，以确保服务隔离和稳定。

前部部署图如下：

多机房灾难恢复部署

最初，连接到产品搜索服务的HA3搜索引擎仅部署在一台计算机室中。当这款计算机室有严重的问题时，它将对上游业务产生重大影响，甚至可能导致失败。鉴于此，将产品搜索引擎的在线离线群集部署到灾难恢复中。在我们进行详细扩展之前，让我们粗略地了解HA3引擎转储过程的原理：

如上图所示，HA3发动机转储过程的一般过程可以简单地分为以下步骤：

可以通过HA3发动机操作和维护平台手动触发上述过程。执行上述过程后，将生成新的索引。新的索引群集服务可用后，在线实时模块将将查询服务切换到新的索引群集以完成索引更新。我们称这个完整的过程为“全数量”。

全金额完成后，当系统更改新产品信息并且相应的数据表具有实时更新（我们称其为增量函数，并且通过消息通知通过 /ODPS表实现了DB表），离线转储引擎将感觉更改，然后在相应的镜像数据表中更新产品数据。根据上述离线转储过程中的步骤，此更改信息将被传递到引擎的上层，直到成功更新引擎指数中的相应数据，否则它被中间的系统规则丢弃。我们称此实时数据更新的过程为“增量”。增量更新还有另一个渠道：算法学生可以使用一种特殊的方法直接更新需要通过增量消息更新的数据而无需通过转储过程，并将数据直接更新为HA3引擎索引。

武的商品量迅速增长，并且已经达到了数十亿美元。连接了数百个索引字段。由于武的非结构化原因，只有一小部分索引字段用于业务使用。其中大多数是算法访问的索引，例如大量提取的标签数据，矢量化数据等。这些矢量化数据非常大。最终的情况是，产品搜索引擎的转储处理逻辑相对复杂，索引数据的总量非常大，并且增量消息量的量也很高。此外，当前的产品订单清单，因此数据更新的实时要求很高，这给稳定性带来了很大的限制。

索引数据是搜索引擎内容的核心。如果输入引擎的索引数据存在问题，或者新更改的数据未更新到引擎索引中，则将直接影响搜索服务的质量。

在部署一台计算机室的搜索引擎时，转储通常会完全失败或延迟，甚至由于某些不稳定的因素而停止。一旦引擎转储出现问题，基本上很难恢复。在许多情况下，甚至需要重新运行以解决问题。但是，千元产品索引数据的尺寸很大，而且一次全额进行全部数量通常需要半天以上。无法迅速停止出血，这对业务产生了很大的影响。因此，将搜索引擎部署在双计算机室中，以恢复灾难（M/N计算机房）并互相备份。

两个离线转储室使用相同的引擎配置和相同的数据源来产生相同的索引数据，分别由两个在线房间使用。这两个计算机室的在线交通比率也可以根据需要进行实时调整。当M计算机室中存在不可逆的问题时，会自动或手动将所有流量切换到N计算机室以实现快速在线出血，然后按照步骤进行故障排除，以解决M计算机室问题。

下图显示了最终的搜索室部署：

尽管双引擎计算机室的部署增加了机器资源的成本，但除了上述商业灾难恢复优势外，还有以下好处：

发动机需求的发布之前缺乏有效的灰度过程。当搜索引擎和高风险发行版中发生重大更改/升级时，您可以首先在单个计算机室中测试小型流量beta，然后在通过数据比较和验证后将其发布到另一个计算机室中；

通常，单个计算机室可以支持所有搜索和查询服务的流量。当遇到大型促销活动或大规模活动时，两家计算机室被安装以同时提供服务。这样，搜索服务能力和容量可以直接加倍，从而避免了单个计算机室的频繁扩展和扩展的麻烦。

在性能评估期间，可以在计算机室进行压力测量，而无需单独进行交通。即使停机时间是由压力测量引起的，也不会影响在线业务。

交通隔离

如上述独立网关部署部分所述，搜索通过统一的服务搜索网关为的高级搜索服务提供了简单，一致的分布式服务。使用统一的微服务不可避免地会带来不同上游业务优先级和可靠性保证的问题。

搜索服务支持各种各样的上游服务。为了统一测量和管理每个业务方案的流量/服务质量，当上游服务连接到搜索服务时，您需要申请使用相应的业务来源。这个业务源标记将伴随整个搜索查询生命周期。它直接在日志收集期间使用，因此您可以监视和提醒业务维度，并实时感知业务运营的健康（简单监视视图如下所示），您还可以控制特定服务的流量，降级和限制流量。

搜索业务来源生命周期图表

分级监控系统

对于高稳定性系统，在出现问题或即将出现问题时能够立即感知到这一点尤为重要，这对于实时跟踪和处理很方便，以防止进一步扩展。当前使用的主要方法是建立声音和完整的多维监控和警报系统。

基本引擎服务监控

使用监视快速发现问题，如果监控的粒度足够好，它可以迅速找到问题。但是，有时会有错误的警报或丢失的报告。因此，实际监控必须结合每种服务自己系统的特征，以整理关键链接，进行多维360度，无盲点监控关键链接并执行合理的预警规则，以便监视和预警更有效。

搜索引擎在线脱机过程/已在重要上游应用程序系统的核心链接上建立了完整的日志数据采集模块，并且对关键指标进行了准确的监控，并进行了警告设置，以便可以及时了解任何问题。下图显示了搜索服务的相应核心日志和监视警报情况。

模拟用户行为的在线业务监控

如上所述，搜索引擎的索引音量相对较大，要求许多团队一起工作，搜索过程相对复杂，并且添加算法学生对的非结构化产品进行了很多AI识别。此外，是一种单股产品，对实时发动机的要求很高。

以前已经制定了一些灾难恢复保证计划，但是需要进一步改进实时的看法，以便迅速了解数据的准确性，是否存在更新延迟以及延迟时间多长时间。

解决方案是从业务层面进行实时监控和警报，提取K类K，该类别具有大量的产品，并且经常更新。在的后端业务系统中，类别k通过一定时间的间隔（可以实时调整时间步长）用作关键字和类别，并根据产品更新时间索引订购，以降序订购，模拟用户投票，并回顾满足要求的产品的首页。然后根据引擎回忆数据的产品更新时间和当前系统时间比较差异。如果时间超过阈值（可以实时调整），则意味着存在严重的数据更新延迟，然后发送警报消息。

压力测试

全链路压力测量

搜索服务和上游服务系统通过全链路压力测量进行了转换，并使用真实的在线用户请求构建了大规模的压力测量数据。在确保它不会影响在线服务的正常进展的前提下，请验证超大流量模型中链接的容量和资源分配是否合理，在链接中找到性能瓶颈点，并验证网络设备和集群容量。

发动机单连接压力测量

HA3搜索引擎在线流程支持在高峰时段重播在线交通查询的方法，以进行引擎在线服务绩效压力测试。

HA3搜索引擎离线过程通过在一段时间内重播增量消息来支持引擎转储的增量性能压力测试。

灰度释放

西亚尤产品的非结构化特征与授权授权密不可分。在我们的研发周期中，许多算法学生与两个算法团队保持了深入的合作，这将 带到了搜索，但也给我们带来了团队合作和研发效率的巨大挑战。

算法团队，发动机团队以及业务工程团队，一个非常大的搜索项目开发团队，有许多新的算法模型，新的引擎转换和新的业务模块，需要每周启动。

将直接启动大量新的逻辑更改，这将带来许多问题：

因此，迫切需要一个灰度实验保证系统，它不仅可以用于协调和隔离整个搜索业务中的各种模块，并对每个模块进行单独的结果评估，还提高了每个人的协作效率，从而使每个模块可以进行快速试验和误差并迅速进行误差。

为了解决上述非常重要的问题，商业工程团队开发了一种用于搜索实验灰度计划管理的实验管理系统。系统函数如上图所示，具有以下特征。

紧急计划

基于评估分析或经验，应预先针对搜索服务中潜在或可能紧急情况的关键点制定应急计划。当满足某些条件时，进行多维和多级自动降解以及当前限制，或者将手动计划配置为手动干预。

每当您发现在线问题时，都需要快速停止流血以避免问题的放大。拥有自动计划将自动发现问题并自动融合它们。我们需要密切注意系统的操作以防止反弹。如果有反弹并对业务产生重大影响，请快速手动干预实施降级计划。完成出血后，详细检查特定原因。当问题的根本原因无法在短时间内确定，如果出现问题时发生任何更改或释放，则更改或释放将尽快回滚。

对于系统中所有级别的依赖服务，系统负载保护受到断路器的保护。我们使用由 [4]独立开发的资源调用控制组件，该组件目前是开源的。或者，您也可以使用降级流量限制工具。

问题故障排除

将搜索链接连接到阿里巴巴搜索问题解决平台。在搜索实时查询请求的每个步骤中输入的参数信息/输出数据信息将在此工具平台上详细显示，以促进各种问题的随访和数据信息的比较。

每个查询条件下每个桶的实验召回数据都可以可视化，以促进每个实验与每个召回产品的各种详细信息之间的效果比较，包括业务数据和算法标签数据，以及与每种产品相对应的每个引擎插件的计算状态，可以详细阅读。

您还可以根据产品ID，卖方ID和卖方Nick披露产品索引信息。您可以在发动机索引中检查相应产品的详细数据。如果数据与预期的一单击不同，则可以单击一键查询。

连接到这个解决问题的平台后，您可以直观地掌握引擎的操作状态，搜索召回的链接状态，并在快速发现问题的根本原因并立即修复问题方面发挥了非常重要的作用。

摘要和前景

本文主要介绍了如何在复杂方案中确保搜索引擎服务的稳定性。它主要用建筑部署，隔离，容量评估，风险感知和控制来解释，并介绍了如何稳定地支持20+在线搜索业务场景，快速发现和恢复在线问题，并可以有效地预测和避免风险50个案例，从而极大地改善了搜索服务的用户体验并确保搜索在一年中并非无效。

在上述治理计划之后，大大保证了武搜索系统的稳定性。同时，我们将继续加深我们的努力，以高级搜索功能的高可用性和易用性，使上游业务更加顺畅。

我希望为所有读者带来一些想法和灵感。

参考：

ha3：

ODPS ::

注解：

①：一个为HA3提供完整，增量和实时索引服务的系统。

②转储：我们调用生成索引数据离线转储的过程。搜索引擎的完整/增量索引是通过系统生成并分布到在线部分的。

③：这是一个分离计算和存储的高效且可靠的消息系统。

④：它是搜索引擎查询的执行者。倒索引召回，统计，条件过滤，文档评分，分类和摘要生成的过程均已完成。根据业务需求，有时摘要（）分开分开以构建一个独立的摘要群集。

⑤SP：是一个统一的搜索服务接口。它的责任是根据用户指定的查询条件（关键字，类别等）获得计划结果，制定查询计划，查询主要的搜索系统，并直接获得最终结果并将其返回到上游业务。

⑥QP：是用于预测用户搜索意图的查询服务。它的责任是确定要搜索数据的数据集（引擎），要检索哪种数据，并通过预测用户的搜索意图和收集相关信息来帮助对检索到的数据进行排序。

⑦：这是搜索在线查询部分，其中包括QRS和其系统中的两个基本角色。

⑧QRS：用于接收用户查询，分发用户查询以收集，集成返回的结果，并最终将其返回到上游业务。

⑨ODP：开放数据，开放数据处理服务； ODP是由阿里巴巴独立开发的分布式大规模数据处理平台，提供丰富的数据处理功能和灵活的编程框架。它主要提供批处理结构化数据的存储和计算，并可以为大数据提供大量数据仓库以及分析和建模服务的解决方案。本文中的ODP专门指的是存储的脱机表数据。

推荐的活动

来自各个互联网公司的一线专家也在不断提高其运营和维护能力，从被动消防操作和维护转变为基于机器学习，自动化操作和维护实践的主动和精致的操作和维护实践，智能操作和维护实践，基于全链接日志监控实践等。

混乱的工程实践在云原生架构下

Uber核心订单调度系统及其集群管理的演变

原木平台构建的最佳实践

计算机室大规模灾难恢复练习练习