我对搜索重构的浅浅的理解

智联平台组

总体思路

基于我所知道的，目前的设计思路我可以这样来归结

1. 上层做融合。（ 或叫Gateway，或叫中间件 ）
2. 每个sharding做基于本Sharding的计算（包括二排和三排）。
3. 后端有离线计算算法进行业务处理。

个人的经验是：架构的重构最好这样来处理：

1. 先定义技术方向，定义最终的几个阀值。（比如QPS，召回率。。。）
2. 再定义大的架构模式。
3. 再定义阶段性目标。

这里的QPS和艾总聊过后，大概得出的值是：

1. 设计目标是3000QPS
2. 线上支持至少1500QPS
3. 目前比较平均的保持在600-800QPS
4. TPS 暂时不知道。

召回率没有得到数据，但可以这样来考虑

1. 从历史数据中归总之前用户"满意/不满意"的场景，用数据来分析不同场景下的召回率大概的一个指标。
2. 根据已知的指标，定义一下下一步期望的指"。
当然"。这里面很重要的就是通过历史数据来收集"测试数据集"。

Ok, 这样，我们的架构设计就有了“性能”和“准确度“两个维度了。

”准确度“上的设计

我理解的数据模型有这两个特点

1. "万能"的数据模型并不存在，或很难存在，虽然深度学习达到了一定的水平，但难度依然很高，而且只在某些领域效果明显。
2. "性能"与"精度"的矛盾依然存在。

我个人在这方面的经验是：出现问题时不妨“分而治之”

举几个例子：

1. 如果职位搜索在北京的满意度高，在天津的满意度低，不妨做两个模型。
2. 如果员工搜索在行业A和行业B满意度不一样，不妨也做成两个。
。。。

这时候会有这样的几个问题：

1. 工作量太大，这么多模型怎么处理的过来?
这时候可以用通用模型垫底，业务上的重点行业，地点进行有针对性的模型训练，这样模型上的投入就以业务为导向了。
2. 这么多模型如何选择？
我建议的解决方法：
    A. 通过规则引擎由产品经理来配置。(根据他们得到的数据和经验。)
    B. 通过关键字进行分流。
    C. 当然也需要模型团队根据反馈不断的优化测试值和模型。

这样，通过分而治之的方式，可以让技术，产品一同参与到性能提升上来，而且也能在工程上可以分段来优化（也容易控制工作量和项目周期）。

我在下面提到的"模型group"的理念，就是基于此的，"模型可以由业务层进行选择，而且模型上线下线全部通过配置来做，也就是希望能够提供这样的能力"。

同时，"兜底"模型还可以提供一些容灾能力。这些模型和对应的数据可以存到Sharding上。

”性能“上的设计

我的建议是：

1. 分而治之。（不光是分片，最好还分层）
2. 计算和数据越近越好

大体的思路如下

Gateway（或说是中间件吧）提供几个职责：

    A. 根据不同负载向不同的Sharding做转发。（轮训算法最好不要是简单轮训，当然前期没问题，最好是能支持探测sharding负载基础上的轮训算法）
    B. 支持"浅"分页功能。（这样将Slor集群重心放到搜索上，而不是分页上）
    C. 支持并处理"业务"召回。（比如在搜索结果上加上商业逻辑等）
    D. 支持应急性能调控及配置。（比如说性能高峰期将一部分流量导入到快速模型上，将查询数据降低。。。）
    E. 支持流量导入不同模型（为A/B test和其它方面做准备）

"Solr及二排三排”的几个设计点：

    A. 支持搜索和预测（基本的，肯定要支持）。
    B. 支持数量配置。
    C. 支持无痕模型切换。
    D. 支持timeout。
    E. 支持离线Features的存储
    F. 根据情况将模型数据和一部分模型计算的结果缓存到本地。

Prediction层（三排）设计

这个就是我最近一周一直在做的事，在下面的链接中。
https://www.zybuluo.com/yanglfyangl/note/1266159

大概的调用流程