• 写在前面

刚当上产品经理的小明又想到了一个好点子，他带着好主意去咨询了研发团队，研发小哥告诉他：这个需求直接查数据库是搞不定了，得请搜索研发团队协助支持。传闻中搜索研发团队很忙碌，使用的技术也很高端，一个创新项目的需求，排期起码得接近一周啊。“他们这么忙，会搭理我这么个小项目的需求吗？”小明嘀咕着，去找了搜索研发团队的产品经理。当天晚上下班前，小明想要的搜索接口上线了。小明身边的产品经理们纷纷侧目：搜索研发团队这是打了鸡血了？

随着公司业务量不断增加，需要接入搜索引擎的项目越来越多，其中有不少是初创项目，对搜索引擎的应用只是浅尝辄止。作为支撑部门，面对接入搜索引擎需求，搜索研发团队一向来者不拒，然而项目数量激增，也伴随这工作量的增加。当前的搜索引擎框架，虽然能够支持高度定制，但从项目的立项到上线需要不少开发人力。而且初创的小型项目也用不到搜索引擎框架提供的高度定制功能。在此条件下，能够快速定制搜索引擎接口的搜索开放平台应运而生。

• 系统需求

1.  快速提供搜索接口

需求方与搜索研发团队沟通，基本都是为搜索接口而来，搜索引擎能够精准定位到目标数据，而且在数据体量大、业务复杂的前提下，依然能做到快速响应，这让搜索引擎技术被众多研发团队和产品团队所信任。原有搜索引擎需要二次开发，排期久，耗时长，开放平台需要克服这些问题，快速输出搜索接口。

2.  保证数据实时性

部分搜索接口数据不能保证实时，这取决于业务特性。搜索接口并不直接依赖业务方数据库，而是依赖索引，因此索引数据需要保证实时。

3.  能够精准定位搜索内容

需求方希望用户只输入少量文本，就能精准匹配到数据，这依赖搜索引擎的分词策略。搜索开放平台需要支持多种分词方案，以满足不同的业务场景。

4.  可视化业务排序规则

许多接入搜索引擎的项目，都对排序有独特的诉求，比如按照某个字段值升序或降序排序，有多个字段值时按不同权重排序等，开放平台需要能够指定这类排序规则。

5.  提供全方位监控

搜索接口运行过程中，需要有监控数据输出，便于接入方查询接口访问情况，也方便搜索引擎研发团队排查问题。

• 系统设计

1.  设计思路

目前团队的搜索引擎框架面面俱到，能够完成各种定制需求，但在功能完备的同时，搜索引擎框架也需要二次开发，后续也需要人力维护。其业务流程如下：

搜索开放平台的业务流程与团队现有的搜索引擎框架基本相似，但力求流程精简，将可以抽象的服务全部抽离，并提供默认的解决方案。获取搜索引擎接口要快速简单，甚至要做到零代码，几步配置操作便能完成。创建索引、数据同步和监控都只需要在平台上配置即可实现。完成配置后，实时生成搜索引擎接口，交给业务方调取。精简后的业务流程如下图：

2.  架构设计

搜索开放平台定位为一个平台系统，要考虑到将来会有越来越多的应用接入，因此在设计上要有一定的前瞻性，在设计初期重点考虑了以下几点：

（1）可视化操作

搜索开放平台力求零代码生成搜索接口，搜索引擎必须依赖索引，索引包含索引结构和数据同步策略，索引结构和数据同步策略需由可视化界面操作。系统会根据SQL生成索引Schema结构，用户只需要在系统界面中选择分词器、词元匹配方案等栏目，并将数据字段描述信息补充完全即可。

（2）支持水平扩展

整个架构体系采用了开源可扩展的分布式解决方案。索引存储采用ElasticSearch，数据同步采用Storm，数据同步命令采用Redis存取。技术产品都支持分布式扩展，为将来接入更多项目做准备。

（3）平台普适性

搜索开放平台力求为更多项目提供搜索支撑，而各个项目的具体需求是千变万化的，开放平台需要从具体业务中不断抽象，得到能够应用于大部分搜索项目的业务特性，针对这些特性进行迭代优化。目前搜索开放平台拥有5套分词方案，多样的查询策略，都是从众多项目中提炼而来。

（4）安全可靠

搜索开放平台将监控范围布局到全系统，在数据同步器和接口访问模块都做了监控，监控区分平台中的应用，可根据各个应用标识单独配置监控参数，当系统运行过程中某项指标超出阈值，监控系统会即刻发送微信、企业qq或邮件到系统维护人员和各个应用负责人，维护人员名单可配置。

3.  流程设计

平台将索引定义和数据同步功能全部整合在后台服务管理中，后台管理系统与Redis集群交互，通过Redis与Storm集群传递命令，命令包括重建索引、增量更新索引、发布系统和删除索引。Storm集群提供处理数据Bolt和清理索引Bolt，也为将来处理多数据源提供可能。ElasticSearch集群内嵌了搜索研发团队提炼出的分词器插件，以满足旅游行业的分词特性，并且分词策略仍在持续扩展中。应用服务器作为另一个与用户沟通的媒介，对外提供搜索接口，对ElasticSearch的查询语法做抽象，让用户不需具备查询语法知识也能轻松使用搜索引擎，详细架构如下图：

4.  数据同步策略

索引结构确定后，需要将数据搬迁从DB或是其他渠道（目前仅支持DB）迁移到索引中。需要做到数据的自动化全量更新和增量更新。更新周期可以通过配置系统灵活的调整。

开放平台需要对使用方的业务逻辑进行解耦，即开放平台尽量避免与业务逻辑直接接触，将复杂的业务逻辑集中在使用方的操作范围内，因此，会通过使用方编写业务SQL，通过开放平台的配置，实现集中化处理业务逻辑的操作。

5.  接口服务与监控

在搜索开放平台中，用户能够接触的功能模块是数据同步模块和接口模块，这两块服务是搜索开放平台的核心，数据的实时性和接口输出都依赖于这两块功能，用户感知程度也最高。因此这两个模块是监控功能的重点。

数据同步服务监控，包含4个监控维度：

（1）数据同步策略规范监控，数据同步时间间隔是由用户配置的，但系统规定重建时间间隔必须大于更新时间间隔，重建时间间隔不得小于60分钟，增量更新时间间隔不得小于1分钟，当用户配置信息不符合规范时，则给出告警。

（2）数据同步结果状态监控，当检测到最近一次数据同步状态是失败的，则给出告警。

（3）同步及时性监控，当数据同步间隔与用户配置的时间间隔信息不符，则给出告警。

（4）索引文档数量大幅变化监控，当发现数据同步后索引文档数量发生激增或锐减，则给出告警。

接口服务监控，包含3个维度：

（1）访问量监控，可对每个项目的访问量设定单独阈值，若每分钟访问量超出阈值，则给出告警。

（2）请求延时监控，可对每个项目的请求延时设定阈值，当延时超出阈值，则给出告警。

（3）请求错误数量监控，对错误数量设定阈值，当请求发生错误的数量超过阈值，则给出监控。

为了让每个应用负责人能够根据自己的应用特性去配置监控模型，搜索开放平台提供了区分应用的监控模式，每个应用负责人可为其应用配置独立的监控模型。

监控指标目前包含三个：单位时间访问量，请求延时和请求错误数，针对这三个指标，每个应用可以设置独立的阈值，当系统运行过程中指标超出阈值时即可实时给出告警。

6.  难点攻克

在平台研发与维护过程中，团队也攻克了不少问题：

（1）无效索引处理策略

开放平台项目与索引采用一对多机制，每个项目的每个版本都会生成一个索引，因此集群会产生大量索引。开放平台有专门的过期索引处理机制，会定期对无效的索引进行清理，每个项目至少保留最新的两个索引。

（2）新老索引切换策略

当有新版本发布，随即会产生一份新的索引，但此时的接口还是使用上个版本的索引，开放平台会对此维护一个索引标识，当新索引创建完成，开放平台会修改此标识，接口服务会根据最新的标识得知接口访问的最新索引，从而快速完成索引切换。

（3）索引指令处理策略

每个项目都将会有全量和增量的操作，项目完成发布后，开放平台会根据接入方的配置策略生成指令，提交给开放平台的消息队列，开放平台数据同步器会顺序从消息队列中获取指令并执行，从而将管理后台与开放平台同步器进行解耦。

（4）更强大的SQL查询

开源的SQL解释器可以将SQL解释成符合ES规范的query查询语句，但插件无法实现平台自身的业务，开放平台对插件做了扩展，将扩展的业务查询与SQL查询进行整合，形成更好的查询方案。

（5）突破分词器瓶颈

在业务多样性的要求下，搜索开放平台内置的分词器已经无法满足业务需求，于是开发平台对分词器进行扩展，在开源IK分词器的基础上，增加了中文拼音分词器和前缀分词器，并且采用了具备同程旅游业务特性的专业词库，解决平台的分词查询问题。

• 操作流程

  搜索开放平台力求简洁和零代码，获取搜索接口被优化为4步配置：

（1）基础信息维护，用户填写应用的中文名和英文名，对应用用途做简要描述。

（2）配置数据源，用户在此处编写SQL，SQL需要能查出搜索接口所需的业务数据，SQL查询出的数据会被同步到索引中，成为搜索接口的数据来源。

（3）数据同步策略，包括全量同步和增量同步策略，全量同步会将SQL查询到的全部数据同步到索引中。增量同步会以最近更新时间为基准，只同步上次同步之后被修改的部分数据，因此增量同步需要编辑增量更新时间字段名。

（4）索引结构配置，可选择对某个字段进行分词设置，并选择词元匹配方案。

（5）保存与发布，发布后会进入索引创建过程，系统会自动完成全部准备工作，并提供搜索接口呈现在页面上。

• 总结与展望

目前搜索开放平台接入了6个项目，业务方从发起需求到获得搜索接口，最快只需要5分钟，为业务团队和搜索研发团队节省了大量时间。在项目稳定运行的同时，平台依旧任重道远，搜索开放平台被期许了更多功能：

（1）多数据源支持

目前平台只支持DB数据源，并不支持跨库查询。随着业务的发展，接入搜索引擎的项目会需要支持跨库查询，或是从MongoDB、WebService乃至其他ElasticSearch实例中获取数据

（2）分词器与搜索引擎框架接轨

现有搜索引擎框架很强大，能够通过配置指定分词器，灵活可靠。ElasticSearch的分词器是以插件形式内嵌的，添加分词器需要对集群进行部署，当集群规模扩大，部署分词器和其他插件将费时费力。

（3）自定义排序

当前排序可指定权重，更深入的自定义排序需要人工干涉ElasticSearch的打分机制，将索引数据与打分关联，自定义数据相关度。