作者：黑夜路人

时间：2022年11月

现在搜索技术已经是非常主流的应用技术，各种优秀的索引开源软件已经很普遍了，比如 Lucene/Solr/Elasticsearch 等等主流搜索索引开源软件，让我们搭建一个优秀的站内搜索引擎效率已经非常高了。

但是ES等只是解决了底层索引存储的问题，实际在具体要落地一个具备工程应用价值的搜索引擎，还是有很长的路要走，很多工程化的东西要去实现落地。

今天我们就基于电商的搜索场景，大概通过这些开源技术和一些基本的其他技术，如何搭建一个采用Golang为后端语言，完成具备落地实践性的搜索引擎工程实践。

电商网站大家都比较了解了，无论是某宝、拼夕夕、JD等等都是非常主流对大家日常生活影响很大的电商网站，基本从用户视角的使用流程链路，我们需要切换到技术工程师的视角去落地这类电商搜索引擎。

我们需要搭建的电商搜索引擎，需要具备能够快速找到用户需要的商品，还需要做一些营销考虑的扩展功能，所以我们定位的目标就是，完成一个基于电商场景的搜索引擎架构，能够达到：召回率高，时效性高，索引更新快 等目标。

搜索业务流程：       

核心搜索业务流程：搜索入口 -> 搜索触发 -> 内容输入 -> 点击搜索 -> 反馈结果

    

搜索基本技术架构：

技术实现框架组件：

后端技术框架：Go + Golang技术框架 Kratos 框架进行后端服务开发

搜索索引存储：Elasticsearch(Opensearch)

中间缓存热数据：Redis

实体持久存储：MySQL

消息交换MQ：Kafka

按照整个业务流程、从输入到输出链路，我们看看  输入数据（输入/灌数据、索引构建）、搜索前（搜索发现）、搜索中（查询处理、索引召回、排序）等环节把整个技术落地架构进行描述。

整个电商搜索各模块规划：

索引构建主要是把原始内容（商品名等）变成一个倒排索引的过程，整个过程最关键包括：需要索引什么数据、数据分词、构建倒排索引。因为使用的是ES，所以最后构建倒排索引这个环节我们忽略，基本ES把整个环节过程解决了。

整个数据进入ES索引库中，总体的数据索引构建的主要技术架构：

整个电商搜索，最核心的就是商品信息，我们每个上核心的就是商品类别、商品名称、上SKU/SPU 标识、商品的详情描述信息 等关键数据。

我们整个整个存储到ES索引中的核心数据主要设计如下：

商品索引 maping：

存量数据处理：

一般同步依赖的索引数据包括：商品属性, 商品类目, 商品标签, 商品优惠活动, 商品评价维度, 商品评价标签, SPU信息 等等信息，这些信息都需要考虑比如说用脚本定期任务方式更新数据，如果是过去的存量数据，都需要批量通过脚本灌入到ES中完成索引构建工作。

增量数据索引处理：

商品标签（标签、评价标签） 数据索引处理：

   

营销标签数据索引处理：

倒排索引的创建：

分词：使用分词器进行文档分词。

分词可以选择不同的规则：后期可以根据召回率来选择不同的分词器。

构建分词词典：把经过分词器处理的分词，创建一个全量分词词典库。

构建倒排链：构建词典跟文档的对应关系，创建一个倒排链。方便后续快速搜索出对应的文档。

针对词条的中文分词技术：

目前兼容Lucene/ES可以用的分词器比较多，ES有内置的分词器，主要是很对英文场景，如果需要解决中文分词问题，可以自由选择很多开源分词器，目前中文分词内置使用比较多的是IK分词器，当然还有其他选择，包括 ik-analyzer、Jieba(结巴)、ansj_seg、jcseg、HanLP 等等，还有零零总总各种云厂商自己实现的分词器。

如果是在es下场景使用，可以按照自己的业务场景找合适的分词器以达到最好的分词效果，决定整个搜索效果质量，个人推荐 IK 或 Jieba 分词器，应用比较多，可以找到的资料也比较多。（一家之言）

在用户准备进行物理实际商品搜索前，还会有很多基本的搜索相关服务，或者是搜索相关推荐类内容给予到用户侧，这些主要是用户引导类的动作，主要包括 搜索底纹、历史搜索、搜索发现等前置搜索场景。

“搜索底纹”：就是在搜索框中底下展示一些其他用户或者是推测用户想要搜索的关键词，方便用户不用自己输入，直接点击，或者是通过这种方式引导用户到某个想要推广的商品中，达到推广的目的。

“历史搜索”：就是记录用户过去搜索过什么词汇，方便用户重新快速点击历史词汇进行搜索，减轻输入词汇负担。

“搜索发现”：主要就是给用户推荐其他用户在搜什么，或者是推测用户喜好，或者同类用户喜好，给用户推荐一些搜索词或商品，达到流量分发的目的。

针对这些前置场景，整个技术流程和技术设计流程如下。

 1. 搜索底纹：

通过自建搜索发现词库，轮播展示搜索发现词，进行底纹展示。

2. 历史搜索：

搜索接口服务记录用户历史搜索关键词，为后续搜索优化提供原始数据。

             

3. 搜索历史 - 数据更新：

搜索接口进行query分析的同时记录用户的搜索关键词，更新至搜索历史记录，定期按规则剔除无效搜索词。

4. 搜索发现：

点击搜索发现词，实现推荐词搜索，通过自建搜索发现词库，获取对应用户所属分组的发现词。

5. 搜索发现 - 词自建更新逻辑：

主要是针对搜索发现场景中的词汇建立和更新逻辑。

用户引导主要实现的是搜索前的业务逻辑，进行搜索提示，快速输出最终的query搜索词，进行索引搜索下发。
 

1. 整个核心搜索服务架构

从索引构建到前置的用户搜索引导等动作后，就到了实际的关键词搜索的关键步骤中。整个搜索流程主要是包含 QP（查询词处理）、索引获取、索引排序、输出展现 等关键环节。这些环节，单一的ES是无法解决这个问题的，所以需要完成自己的整个前置搜索服务（AS）的设计考虑。

完整的搜索服务可以认为是 AS + ES + DB的架构，整个搜索服务的基本架构图：AS（自有Go搜索服务） -> ES -> DB 的整个层次结构

在整个从底到上的搜索服务整合以后，核心自有开发的整个搜索服务（AS）架构图如下：

 这个架构图可以看到，AS 一个主要的功能是通过一个个业务插件来代表相应的搜索。一个最简单的插件只需要包含对应的ES search API，它实际上就是一个配置项，说明es的地址。这样AS就是一个纯代理。

但是在商品搜索以及推荐需求都是不是ES本身能够支持的，所以就需要根据需求写相应的Query rewriter，rerank等算法插件。这样就实现了框架和业务分离，AS具有极强的扩展性和复用性。

上面家投入总体按照每个分层的描述：

搜索聚合层：提供搜索入口的统一接口，适配 PC搜索，APP搜索，H5搜索等

业务搜索层：管理不同的搜索业务 比如：商城搜索 内容搜索 工具搜索 等，为上层搜索聚合提供领域内搜索数据。

插件化计算层：提供插件化的相关性计算框架，提供丰富的相关性库，比如query分析库，query改写库，排序库，过滤库等，上游不同的搜索服务可以灵活选配插件。

反向代理层：基于底层搜索引擎的代理层，包括了：搜索分片，搜索引擎切换，搜索服务降级，底层数据存储切换，搜索数据缓存。代理层都实现了相同的接口比如：搜索数据，推送数据。

如果整个业务会有未来拍照搜索 语音搜索 扫码搜索 都可以在在AS层进行插件化扩展，充分利用三方图形识别能力等最终得到有效的query搜索词，进行索引下发。

2.  QP(Query Processor 查询词处理，获取准确召回的核心入口动作)

上面说了，从索引构建到前置的用户搜索引导等动作后，就到了实际的关键词搜索的关键步骤中。整个搜索流程主要是包含 QP（查询词处理）、索引获取、索引排序、输出展现 等关键环节。

对于整个QP环节，是前置核心环节，为了达到核心的查询效果，能够获取更多相对准确的召回结果，所以QP环节是非常重要的。

QP主要包括这些需要进行的工作：

搜索归一：

读时：搜索引擎中对query查询，需要做归一化处理，以提高结果的召回率。字符串的归一化处理包括：繁体转简体，全角转半角，大写字母转小写。

写时：建联倒排时，会先对字符串做归一化处理，然后再分词取term,用户查询时，也会对查询串做同样的操作，这样就能找到对应的倒排链。

拼写纠错：

用户输入的query并不总是正确的，错误的输入可能导致查询结果不符合预期或者是无结果，因此需要对用户的输入进行拼写检查。

查询分析中提供的拼写检查功能，对查询词中的错误进行纠正，给出正确的查询词。并根据纠错的可信度高低，决定当前查询是否用纠错后的词进行查询。

搜索分词：

分词器：ES 中处理分词的部分被称作分词器，分词器决定了分词的规则。ES 自带了很多默认的分词器，比如Standard、 Keyword、Whitespace等，默认是 Standard。

当我们在读时或者写时分词时可以指定要使用的分词器。对query进行分词可以更有效的命中倒排索引，对应的文档就可以被召回。

词权重：

主要分析了查询中每一个词在文本中的重要程度，并将其量化成权重，权重较低的词可能不会参与召回。这样可以避免当用户输入的查询词中包含一些权重低的词时，仍然按用户输入的查询词限制召回，导致命中结果过少。

停用词：

通过开源停用词库以及自己维护停用词表的方式来判断停用词，去掉在搜索中无任何意义的词。比如：中文 ”的“ ”在“， 英文中的 ”a“ "an" ,所以在处理query词的时候

需要去掉停用词，同样在分词构建索引的时候也会去掉停用词，减少不必要的索引空间。

query改写：

通过上述操作进行query改写，获得最终的改写结果，进行搜索下发。

具体QP示例：

在QP中关于搜索分词部分内容，可以参考上面“搜索索引构建”内容中分词的一些基本技术参考。

3. 搜索结果排序

我们通过QP把关键字丢给了ES等服务按照某些策略，比如 BM25 等排序算法获取了一些倒排索引中的数据，然后这些数据可能不能满足最终前台显示的搜索结果数据，就需要我们针对整个搜索结果数据进行非常有效的排序。

整个排序过程，可以理解为是一个“漏斗式架构”，就是把检索的数据一层层过滤后，最终输出到前端显示：

数据排序 - 粗排：

粗排阶段的目标是从大量的候选商品中筛选出合规 相关且成交率高的商品。对搜索结果进行第一轮的海选，按照表达式对文档进行算分，并按照算分结果进行排序。

数据排序 - 精排：

精排阶段的目标是在粗排的基础上，基于用户的行为特征，对搜索结果进行第一轮的海选，按照表达式对文档进行算分，并按照算分结果进行排序。
 

4. 搜索结果展示

通过以上的层层环节处理，最终我们获取的排序后的搜索结果给前台进行搜索结果显示，完成整个关键环节。整个展现层的业务技术架构设计大概如下：

导购筛选：通过搜索结果重新组织导购筛选导购。

数据展示：通过搜索结果重新组织各种搜索场景下需要展示的数据。增加删除相关信息。

类目筛选：通过搜索结果重新组织导购筛选类目。

本文不是展现搜索引擎的内部技术，搜索引擎内部技术大家可以搜索参考我之前写的一个技术文章《黑夜路人：全文搜索引擎技术原理入门》，了解更基本的原理。

本文主要是在现有 ES 等良好开源软件基础上，如果在类似于电商这样的业务场景下面，在类似于使用Golang这种开发语言，去通过工程化方式，设计架构开发一个可靠解决各种业务场景问题的电商搜索引擎，整个是一个搜索引擎工程技术设计的思路。

其实如果需要延展，比如做商品的“以图搜图”，或者是做“推荐”功能，按照用户兴趣或购买习惯推荐更多好商品，或者按照类似商品，推荐其他商品，那么整个技术架构还需要升级成为下面这样的升级机器学习的“搜索+推荐”的引擎技术架构：

需要变成如上的技术架构，还需要更多工作，主要是需要进行很多工程化机器学习的工作，这个也是未来下一步可以继续延展的。

希望学习完本文，你能够在现有 ES 等良好索引存储开源软件基础上，如何在类似于电商这样的业务场景下面，去通过工程化方式，设计架构开发一个可靠解决各种业务场景问题的电商搜索引擎。

## End ##

    以上就是本篇文章【【原创】使用Golang的电商搜索技术架构实现】的全部内容了，欢迎阅览 ！ 文章地址：http://dfvalve.xrbh.cn/news/7212.html 
     资讯      企业新闻      行情      企业黄页      同类资讯      首页      网站地图      返回首页 迅博思语资讯移动站 http://keant.xrbh.cn/ , 查看更多