​导语 | 搜索和推荐是用户获取信息的两种主要方式，在贝壳也是帮助客户找到房子的主要手段，那么二者都有哪些相似和不同之处？是否可以使用同一套架构来实现？统一架构之后又能带来哪些收益呢？本文是对贝壳搜索推荐部平台架构负责人——高攀在云+社区沙龙online的分享整理，希望与大家一同交流。

 

点击视频查看完整直播回放

 

 

 

 

贝壳为大家提供了找房、买房的一整套服务。由于买房是一个非常重要且复杂的事情，它的流程很长，不可能像买书、买衣服一样，线上下单支付就完成了。买房的过程一般都会有一个线下的经纪人参与，就是我们俗称的“中介”。

 

所以贝壳的主要业务场景是人、房、客三者的连接匹配。人是指经纪人，房是房子，客就是我们的 C 端用户。

 

这三者的连接和匹配都是搜索的几个核心场景，比如“人客”的连接，我们有客源检索系统（经纪人找客户）和经纪人检索系统（客户找经纪人）。

 

而“人房”连接主要对应 B 端的房源搜索，就是提供给经纪人使用的房源搜索。比如当大家去线下的链家门店，告诉经纪人想要什么样的房子后，经纪人一般就会通过 B 端房源搜索系统帮你到合适的房子。

 

 

B 端搜索比 C 端搜索更复杂一些，是专门给有经验的经纪人使用的，是另一套搜索系统，包括新房、二手房、租房、链家直营、海外等各场景的B端房源检索，这些都属于“人房”连接。

 

“房客”匹配就是大家比较熟悉的 C 端的搜索推荐了。比如大家无论是上贝壳APP，还是PC站或者小程序，都会经常见到的二手房、新房、租房、海外、地图找房等各频道的搜索。以及各种首页推荐、相关推荐、猜你喜欢等推荐页面。

 

对我们来说，C 端目前是更核心的场景，因为 C 端的搜索推荐会直接影响到公司的线上商机转化率，需要我们持续不断的去优化搜索推荐的效果，提升点击率、转化率等，所以后面的介绍会主要围绕 C 端展开。

 

为了更好的支撑这些核心业务场景，作为搜索推荐平台而言，我们主要关注三个点：效率、成本和稳定性。效率包括“房客”匹配效率和研发迭代效率，成本包括人员成本和机器成本，稳定即是服务需要保证99.99%以上的高可用性。

 

 

下图就是大家可以在贝壳 APP 上看到的，搜索推荐的常见场景：贝壳 APP 首页中的主搜框、二手房、新房、租房、海外、必看好房、商业办公、查成交、找小区、地图找房等等。

 

随手进入一个频道，比如二手房频道，在上面输入自己想要的小区名、商圈名等等，就会返回给你想要的结果。

 

 

如果不进入搜索频道，在首页往下滑的话，会进入到推荐的首页。不需要任何关键词，直接给你推荐你可能感兴趣的小区、房子等等。

 

 

作为平台，除了核心业务，我们还赋能了很多其他场景，比如搜索平台当前一共赋能了 500 多个场景。

 

C端搜索包括上面提到的新二租等，目前承接了贝壳 60% 的线上商机。B 端的搜索包括房源搜索、客源搜索、装修搜索等等。除此之外，还支持了很多内部其他事业部需要用到搜索的业务，比如签中平台、交易平台、人事行政等等。

 

推荐方面，目前赋能了 300 多个场景，主要是在C端，同样包括二手房、新房、租赁等等，承接了 15% 的线上商机。场景主要有首页的推荐、相关推荐、猜你喜欢、feed 流等等。

 

 

 

和很多公司一样，在贝壳，搜索和推荐之前是分属于两个不同的团队各自发展的，整体代码架构差异都很大，所以我下面会先分别介绍两个平台各自的演进过程，然后再介绍搜索推荐架构统一的过程。

 

 

贝壳搜索平台主要经历了四个阶段：搜索服务、搜索平台、搜索云平台和搜索中台。

 

2017 年时还只是一个简单的搜索服务，主要用于链家二手房的搜索。随着公司业务的快速发展，很多其他业务线也都需要搜索能力。于是本着不重复造轮子的原则，我们把搜索服务进行平台化，开放它的能力，对各业务进行赋能，从而成为了搜索平台。

 

 

搜索平台到 2018 年的时候，已经接入了 100 多个业务，日均有 5 个亿的流量。

 

成为搜索平台之后，我们发现接入的业务越接越多，每接一个业务都需要占用一定的时间，造成大家大部分的时间都花在业务对接上，没有多少时间可以用于本身平台的技术迭代，长此以往，将很难有技术提升和沉淀，无论是对平台还是团队的同学，都是极为不利的。

 

所以我们在2019年的时候，把原来的搜索平台的整个业务对接部分，进行了流程化、线上化、产品化、自助化，进而升级为搜索云平台。

 

到2019 年时，整个搜索云平台接入了 300 多个业务，日均 10 亿流量。由于有了搜索云平台，业务方可以通过云平台在线上自助完成绝大部分的业务接入和上线工作，释放我们大部分搜索研发人力，所以我们可以将更多研发资源投入到搜索效果的优化和稳定性优化等方面。

 

于是在2020 年的时候，我们的搜索云平台进一步升级为搜索中台，到目前为止我们已经接入了500多个业务，日均20亿流量。可以看到我们整个系统的架构是随着业务的发展不断的去迭代进化的。

 

 

搜索服务最开始的架构非常简单，底层使用的是 SolrCloud，上层是两个服务：写入服务和查询服务。

 

写入服务提供全量更新数据和增量更新数据的功能，查询服务有简单的 Query 解析、召回服务和排序服务，上层是一个统一的 API 接口，提供写的接口和读的接口，还有配置变更的接口，是一个非常简单的搜索服务。

 

             

 

升级为平台之后，我们为了降低业务接入的成本，快速对接业务数据，在数据流这块有一个大的改进。可以直接监听业务方的数据变更，通过MySQL binglog同步到搜索平台。底层的引擎也升级为了 ES 集群。

 

查询服务做了一个拆分，上层是带效果的查询服务，包括Query解析、召回、排序在内的SearchService，下层是一个基础的查询服务BasicSearch，直接和ES 集群对接，做一些基础的召回。

 

一些不需要特殊召回排序策略的业务可以直接查询BasicSearch。上层会有统一的网关，做流量收口，统一对所有的业务方的请求进行鉴权，然后分发到下层各个服务。

          

前面提到，成为搜索平台后接入的业务越来越多，导致RD 有大量的时间都花在业务接入上。

 

因为早期一个业务接入有很多步骤，比如需要先发邮件做需求沟通，然后再发邮件做需求的排期，RD 进行开发联调，然后发邮件说明联调通过，然后 QA 联调，发邮件QA联调测试通过，最后才能进行业务上线。

 

可以看到这整个流程非常繁琐，从最开始的提需求到最后的上线需要经过8个步骤，当业务多了之后，如果总是走这种线下人工对接的方式，效率是非常低下的。

 

 

为了改变这个状况，我们开发了搜索云平台，搜索云平台的核心思路，是把整个业务对接的流程进行线上化、产品化、自助化。之前 RD 联调通过之后还需要手动修改 QA 测试环境的配置，QA 联调通过再去修改线上环境的配置。

 

这里会有两个问题，一是整体效率低下，另外由于大部分是人工配置上线，所以很容易出错，从而造成线上故障。

 

为了解决这个问题，我们搜索云平台的实现方案是，把配置统一放到 Mongo 中，联调通过后可以一键把 RD 环境的配置同步到 QA 环境。QA验证通过之后，再一键同步到线上环境，省去了中间人工修改测试环境配置和线上环境配置的整个过程，从而大大提高了效率。

 

其次是整个业务接入功能的平台化。上层我们开发了各个可视化模块，包括分词效果的可视化：可以直接看到不同分词器的分词效果，从而选择自己想要的分词器。数据流的可视化：可以看到数据流的同步情况，包括性能如何，还有多少数据未同步等等。接下来是 SLA 可视化、数据变更记录、配置变更记录等等。

 

下面是各模块耗时统计，包括业务 RD 耗时、业务 QA 耗时、搜索 RD 耗时、搜索 QA 耗时和长耗时主动干预。

 

整个搜索云平台就是为了提升业务接入的速度，通过耗时统计可以方便的看出耗时比较长的是哪个环节，从而针对性去优化该环节，就像慢查询优化一样。

 

平台管理方面第一步是打通数据流的依赖，然后是自助接入和自助运维：包括索引管理、集群管理、分词管理、服务复制等功能。

 

这些功能大大提高了RD的接入效率和运维效率，于是我们进一步再去提高QA的测试效率，开发了自助测试和自动审核上线等功能。

 

底层是监控报警平台，包括全链路追踪平台、监控平台、报警平台和值班管理。如下是我们整个搜索云平台的功能模块图。

 

 

举例来说，业务方通过平台填写需求然后申请接入，到搜索 RD 这边根据需求会填一些对应的配置，之后业务方可以自己进一步完善配置，比如数据源的地址，然后会自动同步到 ES 集群中。

 

业务方还可以通过平台创建自己的表结构，指定有哪些字段，哪些字段需要分词、哪些需要建索引等。通过配置监听数据源、回调地址、索引结构后，再进行数据检验，最后就可以配置生效，返回给业务对应的搜索接口，业务方就可以自己去联调了，联调通过开发环境、测试环境、线上环境同步配置后，整个流程就走完了。在顺利的情况下，一个业务从接入到上线最快可能半天就完成了。

 

最终通过云平台的上线，我们整体的业务接入效率提升了 3 倍，之前平均下来一个业务接入需要 9 天，现在只要 3 天就够了，搜索 RD 人效提升了 6 倍。之前是通过人工变更上限，现在是通过平台自动化同步，故障率也降低了 60%。

 

通过这些效率的提升，我们释放了大量的研发人力，这些人力就可以投入到效果优化和稳定性优化上，从而进一步升级为搜索中台。 

 

如下是搜索中台的架构图，上层的网关和之前的一样，负责统一的鉴权、分发、限流、熔断、降级。数据流会通过事件构造、数据构造等模块写入分布式搜索引擎。

 

查询层会通过中控模块进行各个服务的调用，进行 Query 的纠错、改写、分类和理解。然后调用召回，召回模块会根据召回策略或召回模型进行底层数据的召回。然后再调用排序模块，经过实时排序模型的精排后将最终结果返回给用户。

 

同时我们进一步完善了统一的服务治理平台：包括注册中心、配置中心、负载均衡、消息总线、熔断降级、链路追踪、监控报警和服务编排等模块，最终形成了我们的搜索中台。

            

 

贝壳推荐平台的架构演进也经历了四个大的迭代，最早期就是简单的基于内容和规则的推荐引擎，后面进一步增加了用户画像和协同过滤进行个性化推荐，再通过实时计算和实时模型实现实时个性化推荐，最后为了提升业务接入和迭代效率，推荐平台做了一个大的升级重构，支持业务配置化接入，最终升级为智能推荐平台。

   

 

早期基于内容的推荐非常简单，底层通过对一些房源数据（二手房源、租赁房源等等）进行离线计算，使用Content-based推荐算法，直接离线算出相似房源、热门房源等，然后写入 Redis。

 

在线推荐服务再从 Redis 中查出离线计算好的可能感兴趣的房源，然后直接返回给用户进行推荐。

         

 

在内容推荐的基础上，我们引入房源特征、实时用户画像和实时用户行为记录，升级为实时个性化推荐。

 

个性化推荐底层新增经纪人作业数据、用户行为日志等数据，然后通过离线计算进行数据清洗和特征工程，生成房源特征和用户画像。

 

再通过协同过滤算法，进行协同过滤推荐，然后把这些数据批量更新到在线存储引擎，包括离线计算好的召回数据、特征池和过滤集等。

           

和之前的架构类似，各业务线都有独立的推荐服务，直接查询在线存储得到召回数据和特征数据等，然后根据策略计算后返回给用户。

 

业务系统会经过 AB 实验平台对流量进行分流，进行效果迭代实验。同时，业务系统和推荐服务都会将实时埋点日志回流到实时计算服务和离线数仓中。从而实时更新召回数据和特征实现实时个性化推荐。

 

 

为了提升业务接入效率和效果迭代效率，实时个性化推荐进一步升级迭代，将在线推荐服务进行拆分重构，下层离线计算和实时计算基本不变。

 

重构的目的主要用于解决早期的“烟囱模式”，不再每个业务场景对应一个独立的推荐服务，而是用同一套推荐服务支撑上层的所有业务，新接业务直接复用上线，而非重新开发启动一个服务，从而极大的提升效率。

        

为了达成这个目的，我们对整个推荐服务做了拆分，进行逻辑分层，分为应用层、计算层、数据层和模型层。

 

应用层主要对外提供API接口，以及处理简单的业务规则和配置管理。计算层包含推荐的几个核心流程，如召回、融合、排序和过滤，会分别调用数据层和模型层。数据层统一对下层的在线存储系统进行基础的数据查询。模型层进行在线特征工程后会调用模型服务进行在线预测。计算层拿到数据层返回的结果后进行策略融合，然后调用模型层进行模型精排，最终返回给业务系统。

 

 

 

我们回忆一下搜索平台和推荐平台的大体架构，可以发现他们有很多地方是相通或相似的。我们可以先对比一下搜索系统和推荐系统的相同点和不同点。

 

 

先看相同的地方，首先搜索推荐两个系统的目的都是为了解决信息过载的问题，并且从贝壳的业务场景来看目的也是相同的，都是为了提升线上的商机转化率，进行房客的匹配。

 

从流程来看，二者都包含了几个核心模块：召回融合、模型排序、业务重排和推荐理由。

 

数据上，特别是贝壳的搜索推荐，都会用到这几份核心的数据：房源详情、房源特征、用户画像、用户行为特征等等。算法模型也是可以复用的，比如我们现在使用的 WDL 和 DeepFM模型，都可以用于搜索推荐两种场景。

 

平台工具同样是可以复用的，搜索和推荐都会用到 AB 实验平台、机器学习平台、模型管理平台和效果分析平台等。

 

再看不同点，从行为上来看，搜索是非常主动的行为，推荐是被动的。从意图上来看，搜索的意图一般都很明确，而推荐只需要有模糊的偏好就可以。Query 是显而易见的，搜索大部分场景都会有 Query，但是推荐没有。

 

搜索对个性化要求是比较弱的，推荐是非常强的根据用户画像进行个性化推荐的需求。多样性同样搜索会比较弱，推荐会比较强。搜索是强相关的，推荐相关性不需要太强，会希望可以推出一些“惊喜”。

 

搜索的数据实时性要求是特别高的，数据要求秒级更新，比如一个房子已经卖出后就不能再被搜出来了。而推荐的数据很多都是天级更新的。还有一个不同点是已读过滤，推荐基本是读过的就不会再推荐了，但是搜索就不会，读过也会展现。

 

 

上面相同和不同的对比也部分解释了我们为什么要做架构统一，这里我再具体说明一下。

 

第一个原因就是我们前面介绍的，他们是完全可以统一的，从整体的目的、功能、流程、架构上都是相通的、相似的。

 

第二个原因是我们统一的核心目的：降本提效，也即是本次分享的标题。

 

既然它的目的、流程、功能架构都是相通相似的，那我们用同一套架构、同一个套代码来完成肯定是可以提升我们整体效率的。我们的工程和算法人员都可以复用。代码、数据和特征模型也都可以复用，从而降低开发和维护成本。

 

之前由于是两套完全独立的系统，搜索团队有自己的工程研发和算法研发，推荐团队也有自己的工程和算法，各自维护自己的系统，这样肯定是会有很多重复工作在里面。统一之后，两边都需要用到的一些平台、工具也都可以复用了，避免重复造轮子。

 

             

以上三点通过架构统一都可以直接解决，后面两点是我们希望在统一的过程中优化的。比如常规策略的效果迭代可以支持界面配置上线，简化流程，降低上线成本。

 

其次需要把召回、排序、重排、理由各模块进行解耦，支持分层实验，可以专人专项，各司其职，比如有的人专门负责优化召回，有的人专门负责优化排序，进一步提升整体的研发效率。

 

所以整体而言，我们核心目的就是希望做到搜索推荐架构统一后，达成一个1+1大于2的效果，在各方面都降低成本，提升效率。

 

其次还有一些附带的好处，比如说提升整体的稳定性。因为搜索相对而言稳定性的要求会比推荐更高，并且整个搜索的流量比推荐大很多，所以之前搜索团队的服务治理更加完善一些，有整套的服务治理体系，推荐这边偏少一些，完成架构统一后，推荐可以直接复用之前搜索的整套服务治理体系。

 

另外还可以进一步的提升性能。之前贝壳推荐系统的召回是基于搜索的，推荐召回会直接调用搜索的网关，然后搜索服务再去调用底层引擎，比如说 ES 等等，所以会经过好几次的网络传输。

 

当我们把架构统一之后，就不需要区分搜索和推荐了，推荐的服务可以和搜索服务一样，直接查询底层 ES，减少网络调用，从而提升推荐系统的性能。

 

       

上图是搜索推荐架构统一之后的整体架构图。其实和之前的架构相似，但把搜索和推荐做了一个集成。上层还是各个业务线：二手房、新房、海外、租赁等等各业务线调用统一的网关，进行流量分发、鉴权、熔断、限流、降级等，然后调用底层各服务。

 

前面提到的搜索云平台统一进行各业务接入，以及整体的配置化管理和上线。然后会复用之前搜索整套服务治理体系：注册中心、配置中心等等。数据流会对业务方数据变更进行监听，实时同步数据到在线存储引擎中。

 

我们做的主要的大的重构是在查询层，对原搜索和推荐系统的各模块进行了统一的整合。

 

最新的查询层主要分为六个核心模块，请求一开始会通过中控模块做参数校验、策略调度、缓存和兜底，然后中控会去调用下层各模块，先是意图解析模块（搜索使用，推荐不需要），拿到意图解析的结果后再去调用召回模块，召回的时候会先获取一些用户画像和特征，然后进行多路召回和融合过滤，返回给中控。

 

中控得到召回的数据后调用排序，排序包括粗排和精排，接下来是重排，再之后调用理由模块，补充推荐理由，比如“满五唯一”，“近地铁”等等。拿到理由之后就会最终反馈给业务方，完成整个搜索推荐调用的过程。

 

中控负责各个模块的调度，比如推荐可以直接调用召回，然后排序、重排等。

 

同时在存储方面，我们增加了几个新的引擎能力，之前只有文本检索的 ES 引擎，后面增加了向量检索引擎和图检索引擎。

 

剩下的模块和之前推荐和搜索都是一样的，同样会实时回流业务方的埋点日志然后进行实时计算和离线计算。以上就是我们架构统一之后的搜索推荐新架构。

 

介绍一下几个比较核心的服务：

 

 

中控服务的设计原则是希望它尽量不要有业务逻辑，通过减少迭代最大化的保证中控服务的稳定性。

 

我们看到中控的核心是决定下层各个模块的调度，中控会对下游各个模块做降级，所以下游各个模块的异常都不会影响整体搜索和推荐的请求，但如果中控出了问题可能就会对线上的稳定性有影响，所以我们需要尽量保证中控服务的稳定性。

 

中控主要负责参数校验、调度、缓存、降级等功能。比如推荐不需要走 NLU 就可以直接跳过这个模块，还有一些场景不需要走重排或理由也都可以通过中控的配置直接跳过。

其次中控可以对一些对模块进行缓存，比如 NLU 和理由结果都可以缓存。

 

最后中控最大的作用就是降级，任何下游服务超时或异常都不会造成业务方的查询异常，各个模块都有默认超时时间设置，但同时会实时计算剩余时间，各模块的实际超时时间是该模块默认超时时间和剩余时间的最小值。

 

比如一个常规的调用链，开始调用意图解析，再调用召回，再反馈给业务方。假设我们调完重排要调用理由的时候，发现理由服务挂掉或者响应超时，中控则会跳过理由模块直接返回，相当于是降级返回。

 

如果召回模块超时，中控也会跳过召回模块，直接访问 ES 或 Redis，然后再拿这些结果去走后续的流程，相当于跳过整个召回逻辑直接拿基础引擎返回的召回数据传给排序走后面的流程。

 

最坏的情况下如果底层的存储引擎都挂掉的话，中控会直接去查 Redis 的缓存数据或者默认数据然后返回给用户。

 

下一个模块的超时时间是根据上一个调用超时的时间决定的，业务方一般设置的超时时间为 1 秒钟，但实际上我们的平响是 50ms 左右。

 

比如在异常情况下我们调重排的时候发现已经花了 950ms，由于只剩下50ms，所以再去调理由的时候，理由模块的超时时间会被实时设置为 50ms，而忽略其默认的超时时间。

 

 

召回服务包括请求的构造，拿到 NLU 结果后会对请求进行纠错和改写，然后获取用户画像、房源特征等，再执行多路召回、融合和过滤。

文本召回会去调 Elasticsearch，策略召回会去查 Redis，向量召回查 Milvus，商业召回会去调用业务方的接口，过滤召回是推荐特有的，比如一些已读过滤。在多路召回之后会做一个整体的融合过滤，然后返回给中控走下一个流程。

 

 

重排服务涉及到非常多的业务规则，每个业务线都不一样，有一些是可以复用的，有一些是不能复用的，比如强插、置顶、混排等等。

 

为了便利的组合复用这些规则逻辑，重排实现了workflow的工作流机制。例如默认配置中会有去重、融合、计算得分、按字段排序等默认规则，而“opt-in”可以增加规则，“opt-out”可以去除规则。

             

通过这个工作流机制，我们很多方法都可以复用，通过简单的配置决定走哪些规则，不走哪些规则，这样绝大多数场景都可以通过配置化的上线去满足。

 

其实当前我们的架构统一还在进行中，因为我们的服务比较多，但已经取得了一些阶段性成果，至少从人效上已经提了一倍。

 

原来搜索工程是六个人，推荐四个人，一共十个人，现在合并后只需要五个人。效果迭代效率上也有三倍的提升，之前一些策略规则调整，从开发到测试到上线平均需要十天，现在通过配置化上线基本三天就够了。

 

 

 

未来规划主要有两点。

     

第一，沉淀通用策略模型组合，形成类似“策略套餐”，非核心业务可以自主选择，快速复用。

 

因为现在不管是算法还是工程，我们的资源都还是有限的，我们现在的业务量很大，接了成百上千个，不可能每一个业务都做优化。

 

我们希望可以通过沉淀一些通用的策略模型组合，把它打包成一个类似套餐的形式，一些非核心的业务就可以自主选择套餐复用配置好的模型和算法，进一步提升整体的优化效率。

 

第二，我们希望可以打造一个一站式的效果优化平台。

 

我们前面提到的很多系统，比如云平台、实验平台、模型管理平台等，目前都比较分散，并且有些平台工具是已经开发完善的，但有一些是还未开发完成的，比如样本管理、特征管理、实验管等。

 

我们后续会把各个平台和工具统一完善起来，同时全部打通，然后统一集成到一站式的效果优化平台中，包含业务管理、效果指标、机器学习、效果预测、流量实验、干预运营等各模块，从而进一步提升效果优化迭代的效率。

 

 

Q：问下老师，云平台如何监控的，都监控了哪些指标？

A：我们云平台监控的指标非常多，比如数据流方面，包括各模块写入耗时、写入量、写入QPS、实时率、丢失率等。查询方面：整体查询耗时、各模块查询耗时、平均耗时、999分位耗时、9999分位耗时、查询QPS、整体流量的大小、整体流量稳定性、各状态码（200、400、499、5XX）数量、比率等等。还包括慢查询的监控，比如超过100ms的数量、超过500ms的数量、比率等等。

 

以上主要是性能和稳定性的监控，还有一些效果的监控指标，比如点击率、曝光率和商机转化率等等。这些监控有的是通过日志监控，有的是指标上报监控，使用了各种监控系统。

 

Q：自动编辑生成数据结构，会不会引起结构不合理的情况？怎么避免？

A：其实会有，这个我们遇到过，其实刚才可以看到我们云平台有一个数据接口自动校验，早前我们没有那个功能，经常遇到用户自己编辑、自己填写表结构，什么字段、什么类型。

 

因为他编辑可能出错，当我们拉数据的时候，会发现他的数据源 MySQL中的字段结构和他编辑的是不一样的，有时是多了一个字段，有时是少了，有时表结构里写的是字符串类型实际上是数字类型。经常会出现这样的问题，然后发现数据导不进去、同步不了，导致数据阻塞。

 

所以我们后来增加了数据接口的自动校验，他填完之后，系统会马上他的拉取少量数据，几百条、几千条做验证，拉出来的数据和表完全一致才能够进行下一步。

 

Q：老师，这个链路追踪是如何做的，是全链路吗？

A：我们现在是全链路追踪，基于ES 的 APM做的。大家如果了解的话就会知道，它可以自动的收集各个模块的耗时，最终放到一个 ES 日志集群中，然后可以界面分析各个环节的耗时、整体的耗时等等。

 

Q：问一下老师，如何实现推荐多路并行召回的？

A：多路并行召回主要通过线程池并行的发送多个请求或查询多个搜索引擎，比如向量引擎、文本引擎等，拿到多条召回流的结果后再跟进融合策略进行多路融合。

 

Q：网关是 openresty+lua 做？

A：网关我们用的是 Zuul，Spring Cloud 中的网关组件。

 

Q：老师，搜索和推荐质量保证方面，有没有什么好办法？

A：搜索推荐质量保证，这个指的是什么保证？稳定性刚才已经提到，如果是稳定性方面，我们确实做了很多，刚才提到，有整套的服务治理稳定性保障体系。其次我们的服务肯定是分布式多机部署的，单个服务挂掉了，对整体服务没有任何影响，同时做很完善的限流熔断降级机制。包括我们底层的存储引擎，也都是双机房互备部署的。

 

我们也搭建了完善的监控报警系统，比如499、5XX，超过千分之一就会短信或者电话报警。效果指标同样有监控报警，比如点击率转化率突然大幅度降低，也会及时报警，然后定位分析。

 

一方面是完善监控报警，另外，从一开始设计的时候，就要考虑这方面的问题，比如刚才说的中控降级，就是在设计的时候就充分考虑下层每一个服务挂掉的时候我们该怎么办？我们要做到的就是任何一个服务挂掉，都不会影响整体的查询。其次还会进行季度性的线上压测，及时发现一些线上隐患，摸清线上实际的吞吐量。

 

Q：老师，数据中台是必须的吗？这个如何取舍？

A：其实数据中台跟我们今天讲的关系不是很大，但既然同学问到，我个人觉得不是必须的，肯定看公司场景，如果小公司数据没有那么多，肯定不需要建数据中台，如果是大公司数据非常多，需要各部门打通的话，就可能需要做数据中台。

 

Q：底层服务器是自己构建还是使用公有云，人效提高以后，大家还要加班么？

A：现在贝壳是既有自建机房，又有腾讯云的机房。我们现在是双机房备份的。最坏的情况下，有一个机房挂了，对业务不会有太大影响，可以实时的切换到另一个机房去。

 

然后是否需要加班，加班这个东西跟人效关系不大，如果业务需求比较着急的话，一般还是需要加班的。如果不是很着急，大家按常规迭代，基本上加班不会太多。

 

人效提升之后，大家就可以去做更多的事情，探索更新的技术。比如我们整体人效提升之后，原来需要十个人做的事情，现在只需要五个人就够了，腾出来的五个人就可以做新技术方向的探索，比如说新的向量引擎的探索，新的图数据库引擎，包括新的模型算法的研究等等，实际上就是盘子更大，做的事情更多，当然产出也会更多。

 

Q：监控都是自己开发的吗 有第三方厂商的产品吗？

A：都有吧，有一些开源的组件，也有自己研发的，还有一些公司其他平台提供的统一的监控系统。

 

Q：搜索平台和搜索中台最本质的区别是什么？

A：其实现在我们内部也不太说中台这个概念。如果一定要说区别的话，个人觉得就是中台相对平台更深入业务吧。做平台的时候，我们想的更多的是通用性，尽量少的在平台里做业务逻辑，不然的话就会觉得平台不够通用了。但做中台的时候，更多的是思考沉淀一些业务共性的问题解决方案。如果说只有一个业务有这种问题，可能让这个业务自己解决就行了，但如果像我们这样接了好几百个业务，很多业务都有某个相同或相似的问题，与其说每个业务分别去解决，倒不如由中台来思考一个统一的解决方案。

 

Q：可以内推吗？