蘑菇街小宝：揭秘双十一、双十二、黑色星期五de “阴谋”

小宝：今天分享的是搜索推荐系统架构的演变，包括从最早的导购时期、到后面的电商转型、再到现在品质升级后个性化需求日益增加，整个过程是怎么应对的，以及架构上的演变和思考。在推荐搜索架构的探索中，一路遇到不少的挑战，希望业界同仁能有所借鉴。

51CTO：请介绍一下蘑菇街主要业务以及研发团队。

小宝：蘑菇街是面向年轻女性的时尚电商消费平台，通过整合现在已有的资源，包括电商、社区、红人、内容等等，来服务于不同的女性用户。在最近消费升级的潮流中，蘑菇街也做了很多创新产品，比如蘑菇优选、直播购物、红人导购等等，希望能为年轻女性提供沉浸式的购物体验。

围绕蘑菇街的各条业务线，研发团队的架构也有完整的建设，以更好的支持集团业务发展。从最底层的平台运维技术、中间件技术，到上游的电商基础团队，再到电商业务、导购业务团队、直播业务团队、无线团队等。我们部门是数据技术部门，负责搜索、推荐、广告、流量业务以及对应的策略优化，部门定位是希望利用数据提升效率，包括通过对大数据的挖掘，提升商家广告的投放效率，排序流量的分配效率等，以更好支撑业务发展。

51CTO：探索搜索架构演变中，数据中心是必不可少的，存储也是非常关键的，这方面的经验请您分享一下。

小宝：数据中心这块主要从整个日志埋点采集处理链路上说一下。重点介绍一下埋点采集这部分，我们部门设计了ACM埋点规则，细化到算法实验，可以精确跟踪算法后的每一个实验。通过采集系统、采集数据仓库，以及后面一系列的数据清洗，包括提供支持报表，能够对算法现场效果实时精确观测。数据还需要支持算法能够灵活地进行对比实验，蘑菇街有A/B Testing的系统，包括提供配置化工具，支持算法能够便捷地做测试和效果的评估。

存储主要涉及在线搜索推荐系统的数据。推荐引擎的存储，最早是基于开源的Redis去做的，功能上比较简单，从当时场景、效果看，还是能解决问题的。搜索索引的存储最早也是依赖一些开源社区的框架Solr，后面整个业务慢慢发展后，框架已经无法蘑菇街的需求，因此，后面团队重新研发搜索推荐系统。

51CTO：在应对突发流量过程中做了哪些探索？积累了哪些经验？

小宝：对于电商网站来说，突发流量通常发生在大促期间，像618、双十一、双十二等等。要应对突发流量，首先需要梳理现有业务，因为电商业务还是非常复杂的，链路也比较长，比如详情页、加购、下单、支付等。需要对复杂业务进行合理的拆分，我们现在内部对每块业务做了比较好的服务化拆分和梳理，各系统间的职责也比较清晰，面对突发流量也能比较好的去应对。

另外，大促期间的突发流量是不可避免的，因此，需要提前预估并做好预防工作。我们的研发团队在这块做了很多工作，包括现有的全链路压测系统和大促前的压测演练，能够提前根据业务量预估流量，按量级模拟现场真实程度去做压测，按照近几次的大促经验来看，全链路压测系统还是能比较好地做好预估容量，避免突发流量造成局部服务不可用而影响全局。

但是，大促期间即使做了周全的压测仍有突发情况的发生，所以要有灵活的容灾降级策略，避免突发流量拖垮核心业务。这部分目前各业务也都做得比较好，也有对应的开关系统等支持，在全链路压测期间也会做相应的演练。

最后，我们也有通用的监控报警系统，目前大部分业务也都接入了，确保故障能够第一时间被发现和处理。

51CTO：结合您的经验，您认为搜索推荐系统架构的构建过程中，有哪些问题是需要重点关注的？

小宝：前期的重点是系统能够快速地支持业务，这时候，不需要花费大量时间构建复杂的系统；业务需求满足后，需要考虑如何更好地提升算法效率,满足个性化的排序需求；系统和业务变得复杂后，越来越多的算法同学加入进来，这时候需要考虑如何合理分工、如何让算法专注于做模型训练/排序调优，如何提升开发人员的效率，以及提升整个线上的排序效果。

51CTO：未来的搜索推荐系统您认为会发生怎样的变化？

小宝：变化主要源于业务、算法的变化。业务变化源于集团的战略，业务变化带来的挑战是整个体系的计算量和存储量变得更复杂和多变；算法的变更则要求我们能更加了解算法流程，从而在工程上去支持算法变现（比如深度学习框架的应用）。不论哪个变化，对工程师来说，都需要去关注业务，关注业界前言技术，并提前做好相应的技术储备。