文章摘要：本文是对业务检索平台的设计探索，分别介绍了平台产生的背景、系统架构、设计细节和优化措施。
本文首发自 微盟技术中心 微信公众平台~
一、背景
微盟业务检索平台在微盟新商业操作系统 WOS 中扮演着重要的角色，目前检索平台已为 WOS 多个中台和业务的亿级别数据提供检索服务，主要涉及促销、商品、交易、会员几个核心领域。通过对事件接入、构建流程和检索的标准化，为有检索诉求的业务和团队提供低成本，高效率的使用检索功能，减少对检索技术细节依赖和资源维护成本浪费。
二、为什么要有业务检索平台？
传统烟囱式架构：
优点：
- 资源隔离
- 快速迭代
- 业务独立
- 逻辑简单，读、写可能都在一个应用内完成
缺点：
- 技术依赖，业务都需要有人熟悉相关的搜索技术栈
- 管理维护成本较高
- 数据孤岛，业务之间数据相互独立，无法复用
- 数据一致性保障困难
- 可复用性差，新业务需要从0建设
- 可扩展性差
- 可管理性差，不能支持检索资源的统一管理和调配
随着业务的快速迭代和扩张，以上弊端会越发凸显，为了解决上述面临的问题，检索平台就诞生了。
三、业务场景及检索需求
目前已接入的业务：
以已接入业务分析,业务检索平台的业务场景包含管理端和用户端两类：
- 管理端的特点：面向管理人员，请求量低频，时实性高。
- 用户端的特点：面对C端用户的，请求量高，大促有突发流量和热点流量。
虽然业务不同，模型不同，但业务场景却区别不大，需要通用的检索能力，根据是否需要跨业务域分类：
- 单领域检索，只需要完成自身业务数据的检索，如：会员列表，需要支持数据的多条件联合检索。
- 多领域检索，多领域模型，需要聚合多个领域数据，如：活动、商品聚合检索，需要将活动数据和商品数据做联动检索。
四、业务检索平台的挑战
业务隔离： 业务隔离包含构建数据隔离和查询隔离，平台为每个接入方都提供一个平台唯一标识，所涉及的数据，索引，都会冗余上对应的唯一标识，对于检索请求，经过授权后，可支持跨业务查询，如：同时检索促销活动和拼团活动。
模型如何管理： 将业务模型与 ES 模型相分离，通过映射关系表来维护不同业务模型与 ES 的模型映射，在写入流程中，将业务模型转换成 ES 模型，进行索引定稿，查询时将 ES 模型再逆向解析为业务模型。既解决了 ES 索引字段的膨胀问题，又可以保持各业务的独立性。
索引如何构建： 在索引构建服务中，平台提供了基于节点的执行框架，执行框架会识别节点，根据不同节点关系，执行节点处理，进行索引构建。
如何保证数据的实时性与准确性，方案如下：
如何保证检索性能：
- 为了保持平台整体稳定运行，所有请求会按业务方进行请求隔离，每个请求会分配不同业务线程资源处理业务请求。主要包含调度线程与执行线程，并且相互分离。
- 针对慢请求，过量请求，会进行监控打点并且触发自动降级（降级方案策略由业务方确认）。
- 提供路由能力扩展支持，业务方可自定义路由规则。典型的场景为：冷热数据分离，定向路由。
五、业务检索平台设计方案
业务检索平台按职责划分将平台分为：事件接入服务、索引构建服务和检索平台服务。把所有的行为抽象为事件，把索引构建过程的步骤抽象为流程节点，把检索场景设计为泛化的检索，与业务剥离。1、系统架构
2、事件接入服务 主要完成事件接入、事件转换和事件分发。
-
多协议模型接入：包含Canal监听数据库、Artmeis通知变更消息、Dubbo接口和适配业务方的业务消息。
-
事件源：用于定义事件的来源业务方。
-
事件场景：事件的场景分类，目前已定义的有活动，活动适用，商品等。
-
事件模型对象，包含事件源，事件场景及事件具体数据。
-
事件状态维护及持久化处理。
-
事件分流：根据事件源和事件场景进行划分，分发到不同的业务处理队列。
核心流程：
3、索引构建服务 主要完成事件生命周期的执行和数据写入。
-
事件生命周期定义：对不同事件的处理节点定义和编排。
-
模型与索引转换：业务模型与索引模型的映射关系及转化处理。
-
节点执行编排框架，抽象构建过程，将事件节点组合执行，完成整个构建流程及异常上报。
-
事件的去重、聚合、幂等、限流处理。
-
针对特定的事件源，进行无锁化处理，提升构建性能。
核心流程：
4、检索服务
主要提供业务方管理,管理查询场景和查询配置,提供检索能力。
- 业务方管理，业务方的唯一标识管理，聚合多个业务方整合，形成新的业务方，进行跨业务的业务支持。
- 检索场景配置，配置对应的业务模型和请求模型。支持多版本存在，通过不同版本，能够极大帮助业务升级能力时，缩小影响范围。
- 泛化检索协议，基于场景配置，业务方可实时调整查询逻辑。
- 检索流程控制、查询路由、缓存策略、降级策略。
核心流程：
5、业务接入流程通过千寻系统可完成一站式的所有流程，包含入驻、集群配置、索引管理、索引模型关系映射、构建流程编排、查询流程编排、调试和发布。
六、价值
- 降本：
-
- 通过模型抽象及利用，将不同业务数据收拢，统一管理，硬件资源也比传统方式的降低50%。
- 增效：
-
- 通过检索业务的全流量分析，将各节点都标准化和配置化，极大地降低了对接成本和迭代成本。新业务对接最少1天，老业务简单迭代（增加字段，查询场景等），可通过配置化实时生效。
- 性能：
-
- 提供每日亿级的调用，峰值请求量10W，核心适用业务5千万的日调用请求，平均RT保持在2～3ms内。
- 关注点分离：
-
- 业务方专注于产品业务的迭代，屏蔽掉检索相关的技术依赖和底层资源的管理维护。
- 平台专注于系统稳定性，深入探索检索技术对其封装，提供简单易用能力支持，与底层资源打通，提供自助化的能力。
七、未来规划
-
配置化
-
- 接入方注册、索引管理、集群管理统一抽取到配置管理服务。
- 索引构建与检索接入动态在线编排，支持流程热加载能力。
-
可视化
-
- 接入服务、构建服务和检索服务数据指标可视化。
-
简单性、易用性提升
-
-
降低接入成本，往自助化建设。
-
提供性能诊断及优化建议能力。
-
自动化治理和运维（集群、索引）。
-
八、结语
本文是对业务检索平台的设计探索，分别介绍了平台产生的背景、系统架构、设计细节和优化措施。当前已为微盟集团多条产品线提供检索场景服务，后续也将继续探索，持续丰富功能，服务更多的业务，同时欢迎感兴趣的同学一起交流优化。