1、现状 & 问题

搜索中⼼化管理的⼀个⽐对就是业务侧⾃建搜索体系, 在谈谈搜索中台前先聊聊业务侧⾃建搜索带来的挑战,烟囱式的搜索体系⾯临:

• 技术跟⻛

别的团队⽤ES/Solr于是也跟着⽤, 未考虑搜索引擎与其⽤来解决的业务场景。

• 使用规范性

团队成员背景不同，对于搜索相关业务跟搜索引擎理解不同, 导致搜索引擎的使⽤⽅式五花⼋⻔, ⽐如喜欢⽤关系型数据库的⽅式理解Elasticsearch、业务在引擎侧使⽤定制化脚本/插件篡改业务字段、数据同步跟业务代码耦合等。

• ⼀致性问题

根据使⽤场景, 少量业务侧使⽤ES作为唯⼀数据源, 但⼤多团队会使⽤关系型数据库作为权威数据源, 基于关系型数据数据中单表/多表之间的数据建⽴异构索索引, 业务⾃⼰搞同步往往⾯临数据同步上的⼀致性, 搜索 & 精确匹配上的实时性挑战。

• 业务与搜索引擎之间的耦合

业务代码中需要考虑 ES 索引数据的同步、字段值的变更、数据体量、请求模式跟流量; 引擎侧需要集成业务定制化插件, 定制化script等⾮通⽤配置。

• 孤岛问题

涉及团队协作的应⽤场景, 互相甩锅, 推卸责任, 项⽬进度强依赖对⽅。

• ⽞学问题

Elasticsearch虽然设计理念为简单&开箱即⽤, 把它作为⼀个⿊盒产品使⽤依旧会遇到不少底层相关问题。

• etc

随着搜索业务场景的扩展, 当研发部⻔各个团队需要花很⼤⼀笔成本解决各种搜索相关问题时, ⼀个数据统⼀管理 & 能⼒复⽤的搜索中台自然而然的诞⽣了。

2、中台认知

中台是⼀个抽象概念(可能有些地⽅把它定性为⼀种战略), 个⼈认为如果能折叠搜索链路中的通⽤部分,统⼀管理数据并将业务具象部分以扩展点的⽅式让业务侧协作(e.g 插件, 配置化,脚本,可视化⻚⾯配置 etc), 这样的系统可称为搜索中台。

你也可以称它为搜索中台、搜索平台甚⾄是搜索⼯具集产品,纠结于对⼀个系统的主观定性并不重要。

架构没有绝对的优劣之分, 当项⽬处于初创阶段,⽤户规模和数据体量都不⾼时, 业务⾃⼰实现搜索能⼒能让搜索链路更加贴近业务, 在实现业务功能上不需要强迎合中台的条条框框跟约束(中台需要海纳所有业务场景)。

搜索模块中⼼化管理的有⽆, 搜索中台的覆盖⾯取决于企业搜索相关的业务模式。

3、基础模块

3.1 能力篇

聊聊基于ES的搜索中台模块前先简单梳理⼀下中台折叠的基础能⼒。

图1:搜索中台职责

这是我认为从职责维度上⼀个简单版搜索中台的覆盖⾯：

• 1、能⼒之间有协作。

⽐如索引⽆感知重建能⼒不单由任务调度、全量任务、索引别名&setting修改能⼒组合,还会跟索引⽣命周期、增量任务、索引模版模块等交互(e.g 索引重建完毕后调⽤⽣命周期模块删除⽼索引)。

• 2、工作边界的划分。

图1从职责维度上抽象描述了搜索中台样貌,个⼈认为搜索中台的建设最核⼼的⼀点即为⼯作边界的划分, 每个能⼒模块单元不等价⼀次具像化的功能实现。

⽐如在⼆维⽕我们使⽤阿⾥云elasticsearch⾃带的流量监控配合极限数据平台, 在⽹易使⽤哨兵平台 + es 定制化采集器的⽅式进⾏流量监控(如果打开ES monitor功能, 单从kibana上也可以⼀定程度上观测到流量)。

⼀个能⼒模块的实现可以是最low的⼿动操作,⼀个专属的项⽬⼯程, ⼀个简单的脚本, ⼀个可注⼊插件等等, 是否做到⾃动化、可配置化甚⾄进阶到产品化取决于现有的基础能⼒⽀持程度、搜索业务需求、团队资源等综合因素(甚⾄为爱发电嘿)。

• 3、中台建设不是一蹴而就的事。

建设过程最好紧贴着业务跟需求⾛, ⽐如在折叠搜索能⼒过程发现写流量的波动对业务搜索影响较⼤(e.g ⾼峰写占⽤过多数据节点资源), 可以考虑把流量控制能⼒优先实现(e.g 以消息消费的⽅式异步写⼊)。

此时像索引⽆感知重建、数据迁移等其他能⼒暂时是靠⼿动操作先扛着。

3.2 协作篇

以基础组件协同的角度来看看搜索中台, 原则上具体组件的选择不该有强依赖。

图2:搜索中台模块协作

图⼆以模块协同的维度看待搜索中台(基于本⼈实践经历),相⽐图⼀更具象化, 但也固定了部分技术选型:

• 图中绿⾊部分代表应⽤已实现, ⻩⾊代表应⽤核⼼部分基本实现, 红⾊代表应⽤只实现部分能⼒(建设中)。
• 图⼆的⻆度看待搜索中台, 虽然更加具象但也带来了⼀系列软约束(e.g 定义了增量 & 全量模块,带来了对消息中间件、数据平台的依赖。

个⼈建议⽤⼀种"轻松"的⽅式看待它: ⽐如ETL平台既可以选择阿⾥dataworks，也可以选择⽹易猛犸，搜索⼊⼝管理应⽤在业务早期/不复杂场景下可以先不考虑(e.g 业务应⽤直连ES),原则上建议先实现热需求。

对于"轻松"的理解因⼈⽽异, 这⾥分享⼀张⼆维⽕落地的搜索中台协同架构图。

图3:⼆维⽕搜索中台模块协作

3.3 具象篇

这⾥, 展示图⼆部分核⼼模块的⼯程设计, 其中 tis-sync & stream-linker & bp-admin在可配置化改造完毕后我将放⼊github(tis-sync & stream-linker整合成⼀个项⽬来降低理解难度, 将会在《轻量级搜索中台实践--Beta篇》附上地址, 欢迎⼤佬们指正)。

3.1 tis-sync

⽆业务属性的数据缓冲 & 同步应⽤。⽀持ES⽂档的单写⼊&批量写⼊. 以命令模式实现ES的数据变更操作(index/update/delete), 配合组合模式实现对搜索引擎的批量数据写⼊/变更。

图4:Tis⼯程结构

• 扩展点 Tis-sync应⽤⽀持监听nacos配置变更事件, 通过对该事件的监听管控ES写⼊流量 => pause/resume 消费者。

Tis-sync应⽤扩展了类似upsert能⼒(IndexOperationCommand的⼀种实现), 通过Elasticsearch "get by id" API fetch ⽂档数据到tis-sync, 将增量更新数据应⽤到原⽂档，随后将新版本⽂档数据通过 IndexWriteCommnad(封装了ES Index相关API)index ⾄ Elasticsearch 集群。

简单来说, Tis-sync 定位是⼀个轻量级、⽆业务属性的⽤于数据同步的消费者组件, 对于数据同步秉承所⻅即所得的理念 => 不基于业务篡改接受到的数据消息内容。

可通过接⼝IndexWriteCommnad实现向redis, HDFS, mongoDB,Clickhouse等异构数据源的同步

• 产品化改造点

基于历史原因, Tis-sync承载了索引同步的全量, 增量(基于时间范围扫Mysql表,⾮监听binlog模式)任务，考虑到维持Tis-sync纯粹性, 未来可：

• 移除旧版增量任务,并将全量任务改造成业务属性可配置化模式；
• 移除旧版增量任务, 将全量任务迁移⾄数据平台(猛犸+Spark)；
• 移除旧版增量 & 全量任务,并将全量任务逻辑改造成可配置化迁移⾄其他应⽤；
• 数据源与⽬的端的可配置化 => 进阶版为基于管理者的可视化⻚⾯上允许修改；
• 基于管理者的索引维度消费者停开控制的可视化。

图5:tis-sync基于mysql的全量数据同步

3.2 Stream-linker

简单来讲,如果系统基于Canal实现增量数据订阅与MQ消息⽣成.在增量数据同步上需要解决不同数据源与端之间的数据描述⽅式不同与各种定制化需求(e.g 基于MySQL建⼀张Hive⼤宽表从数据上直接体现关联性)可以试试streamlinker。

Stream-Linker是⼀款轻量级⽤于解决不同数据体同步的产品,抽象层接⼝适配了多款消息队列(当前⽀持kafka，可通过实现stream.linker.bus.CanalMsgConsumer适配其他消息队列产品消费者),⽀持声明式⽣成消费者组与消息数据处理&关联的细⼒度控制(接⼝实现⽅式).各个业务场景的Consumer与对应数据handlers之间的隔离保障了可靠性。

图6：stream-linker⼯程结构

• StreamLinkerStarter

应⽤启动⼊⼝, 基于轻量级容器框架Solon 搭建, 根据配置信息⾃动⽣成不同消息队列产品消费者。

（1）基于BatchID & ID 接⼝定义, 将每个消费者关联⼀组数据处理handlers(CanalMsgHandler)。

（2）基于每个消费者, 包装MsgHandlerBundle对象 维护消费者与handlers联系, 并为消费者分发线程资源。

（3）CanalListeningHandler 模版类, 基于消费Canal消息场景定义了⼀套模版函数, 包含消息识别与快速失败, Canal消息体反序列化与转Map & 消费分发关联CanalMsgHandler 能⼒。

图7：Stream-linker关联后的异构索引

• stream-linker总结

Stream Linker 简单轻依赖, 秒级启动, Canal消息消费&数据编织&同步场景只要在资源⽬录 app.yml 下定义 Consumer类型与数量(简单场景下只需要配置数据处理器id, NDC/Canal topic, 消息队列类型三项即可), 随后继承 CanalListeningHandler ⾃定义数据关联&同步逻辑, 即可在代码层⾯上实现数据关联与向任意数据端同步能⼒:

（1）消息队列消费者初始化可配置化；

（2）数据关联逻辑以接⼝CanalListeningHandler实现⽅式扩展(代码形式)；

（3）极度的轻量级, 毫秒级启动。

• 产品化改造点

（1）业务数据关联执⾏器的可配置化(第⼀阶段:单表配置 => 第⼆阶段:多表关联配置 => 第三阶段:基于管理者的可视化关联数据模型)；

（2）基于管理者的消息队列依赖的可视化变更(future)。

3.2 索引管理服务 bp-admin(重构中)

• 背景：

搜索中台核⼼依赖组件的管理者, 全局调度与产品可视化的管理⼊⼝。

• 承载了组件的健康检查(上⽂tis-sync的消费、停开、stream-linker的消费⽣产, kafka,Elasticsearch等健康状态)
• 数据的⼀致性(源、终端之间)检查者
• 数据模型可视化关联&字段过滤⼊⼝(控制stream-linker)
• 索引纬度数据同步pause/resume 可视化管理⼊⼝(控制tis-sync)Tis-sync & stream-linker 依赖的源终端可视化配置⼊⼝
• 索引业务⽆感知重建流程调度者
• 索引数据& 报警推送

图8:bp-admin管理下的索引业务无感知化重建

简单来讲, Tis-sync & Stream-linker的组合 已经具备了搜索中台数据同步的基本能⼒, 在⼀定改造下两者皆可以以配置⽂件修改的⽅式控制数据的关联,过滤,业务处理, 同步等核⼼流程。

但是业务侧需要⼀定程度上理解这两款组件并且增加业务逻辑相关的配置。

Admin应⽤将⼀系列搜索链路上的复杂度(数据编织, 同步, 增量,全量,重建 etc)折叠成了⼀款可视化产品。

业务侧⽆需理解搜索中台底层逻辑, 只需要在可视化界⾯上提供业务数据模型之间的关联关系(单表场景⽆需提供), 即可在Admin应⽤上管理, 监测, 控制异构数据的同步状况。

4、未来

中台并不是⼀款⼀撮⽽就的技术产品,需要结合组织架构与业务架构,中台赋能业务,折叠业务通⽤部分。

中台基于业务搭建，将搜索链路中通⽤部分收编, 业务定制化部分以扩展⽅式嵌⼊⾮核⼼流程(插件式、配置化、可视化管理)。

上⽂只代表个⼈理解, 我希望能通过⼀⽂将⼀个简单的搜索中台展示出来,如果有任何⻅解欢迎联系本⼈。

搜索中台实践是⼀个⻓期的过程, 我会在轻量级搜索中台实践--Beta篇对本⽂进⾏补充, 附带改造后的核⼼应⽤⼯程地址。

5、作者介绍

作者 KK，前二维火搜索平台负责人，现网易富媒体团队搜索平台研发，Elastic 认证专家，死磕 Elasticsearch 知识星球嘉宾。