10 月份 QCon上海2017上，360 搜索架构师郝一昕将带来演讲《360 亿级搜索容器云平台架构实践》，InfoQ 在这之前，对郝老师进行了一次采访。
这一次的采访，对读者来说是个学习搜索技术相关知识的大好机会，整理出的这篇文章虽然讲的是高深的搜索技术，但它从搜索引擎的相关知识点入手，简洁明了，读来大有裨益。
首先可能很多人像小编我一样会觉得，搜索其实就是指一个业务，但是 360 搜索作为国内知名度和使用量第二的搜索引擎，在每日上亿用户访问量的背后，竟然是有数百条业务线在满足用户不同的需求。
就算你知道搜索业务背后其实不仅是一种业务，那可能你也不知道它到底有多复杂。如果你连这都知道，那……那当我没说，静静地往下看就是了。
搜索产品虽然只是一个输入框，但后面提供的服务有很多不同业务引擎支撑, 每个业务引擎又有很多不同的策略,每个策略又有很多模块在协同，所以这背后的支撑系统其实是很复杂的。郝老师从以下几个角度去分析，虽然有打广告的感觉，但是客观息怒，这确实可以让人很快了解这些业务场景具体是怎么回事。
综合搜索
360 搜索引擎是一个综合搜索引擎。通过 360 搜索，用户可以了解时事新闻资讯，查找自己关心的任何主题的信息，还可以搜索各种问题的解决方案，甚至通过搜索辨别虚假信息、骚扰电话等等。
特色产品、创新
360 搜索有很多有特色的产品和创新。以信息内容消费的安全层面为例，360 搜索提供了大量的产品细节优化和创新，比如金融股票投资、健康等多个社会领域，包括了 14 类风险提示。网络信息生成环境纷繁复杂，我们极尽可能帮助用户避免被不靠谱信息欺骗。
多种垂直搜索服务
360 搜索针对不同类型的信息，提供相应 12 种垂直搜索服务，比如视频、音乐、图片、地图、应用软件、手机软件搜索和下载等，很明显地，每种垂直服务后边都是不同的业务线在支撑。
搜索体验
在搜索体验上，通过大量算法，甚至人工智能技术，保障用户快速找到他们需要的信息，同时在信息的权威性、多样性和展现形式上给用户提供更好、更智能的体验。
比如通过用户搜索的内容和访问偏好，对返回结果进行排序，将标题摘要进行一定程度的优化，以更容易理解的方式呈现给用户，并且更快速地去判断这些内容是否是他们需要的信息。
360 搜索也通过很多研究和试验，进行大量的搜索体验创新，比如搜索流式体验。360 搜索的技术人员使用大数据技术，每天挖掘出热点事件推送给用户，当用户浏览这些信息的时候，搜索结果会依据该热点的整体的时间线去梳理，给用户提供更丰富的信息流式浏览体验。
搜索实体化
比如用户在搜索医疗类的关键词或者疾病症状关键词的时候，360 搜索引用医疗人工智能技术帮助用户自我判断，自助分诊。同时通过搜索聚合进行信息权威度、价值的筛选，优先把权威专家、三甲医院医生，以及百科信息呈现给用户，提高用户信息消费安全性，进而降低用户被虚假信息误导的可能。
深度领域垂直问题解决方案
在产品理念上，360 搜索除了提供出色的搜索体验，满足用户各种需求，还提供深度领域垂直问题解决方案，比如搜索视频的在线播放体验、下载体验；比如搜索机票、火车票，360 搜索会提供可靠的预订票务方案；搜索天气，则提供天气预警、交通出行、空气质量等生活服务参考信息等。
深度消费体验
360 搜索不仅关注用户找到的信息的靠谱性，更关注找到之后的消费体验，也就是说具体问题解决的体验，比如下载软件的安全性，360 搜索会实时严格检查是否包含并病毒木马，也会关注访问速度等安全相关因素，对有风险的一定拦截掉，保障用户权益。
郝老师介绍完这些，我才突然明白，原来我们平时使用 360 搜索的时候，看似简单的一个搜索入口，背后竟然有那么强大的设计逻辑，而这所谓的“搜索业务”，还真的是需要很多业务线去支持，这早已超出了一个搜索知识小白的认知范畴。
接下来我从开发的角度请教了郝老师。其实，说起搜索引擎的开发，稍微知道一点网络开发的人会先想到“爬虫”，这似乎是最容易、最直接的一种网页搜索技术，直接拿起 Python 写个简单的爬虫脚本也不过几分钟的事，但是如果想要专业去做搜索引擎，那么这涉及到的东西有很多，也很复杂，郝老师为我们梳理了一翻。
首先，要知道网络爬虫其实只是搜索系统中的一个模块，搜索系统并不是只有一个爬虫。提供一定检索功能的搜索系统，使用开源软件就可以做到。
网络爬虫（抓取系统）有近百种开源；索引建库和索引检索有十几种，比如著名的 Lucene 以及基于 Lucene 的好几种分布式检索系统；数据存储和处理可以依托 Hadoop，国内的开源分词系统也有很多。
这些开源系统都有十几年的历史了。对于数据量和访问量不太大的情况，或者非核心业务、线下业务，上述组合有非常广泛的使用。
但是，实用的网页搜索由于其大数据量、高并发，以及对于搜索结果质量、搜索性能以及可靠性、稳定性的苛刻追求，现阶段只能是以自研为主，只有少数组件可依托开源系统。
搜索系统本身至少包含网页抓取、网页评价、反作弊、建库及在线检索、ranking 排序策略等模块。实现一个初级的网页搜索系统，基本脱离不开 IR（Information Retrieval）的范畴，像倒排索引、索引压缩、Google 的 PageRank、经典的打分策略 TF-IDF及 BM25等都涵盖在内。
当然随着时代的发展，一些可选件，比如近十年国内各搜索厂商开始铺开的机器学习及近期的深度学习可能日后也是一个初级搜索系统的必备品了。IR 主要还是理论指引，搜索引擎涵盖的各种大规模分布式系统的具体实现还要考校架构和工程的能力。
除了搜索系统本身，一个完善的基础架构也是必不可少的，最著名的比如 Google 的三驾马车GFS、BigTable、MapReduce，以及开源的 Hadoop。
对于网页搜索几百上千亿的数据容量、秒级的数据更新频率而言，没有一个类似 Hadoop 的数据存储与处理系统根本不可想象，Google 的三驾马车也正是搜索的现实需求催生出来的。
具体来讲，一个完整的搜索引擎主要由下面四个系统组成，涉及到大数据处理、网络通信、策略算法、高性能服务架构等方面的知识技术点（这里针对 360 搜索的规模）。
1. 网页抓取系统
如“爬虫”，这个系统主要通过各种策略 (种子站点、时效性和用户点击等等）从互联网抓取网页，一般网页抓取系统是一个分布式、多层次的，由几百台机器组成的分布式计算机群，抓取完成后将网页交付给网页分析筛选系统。
2. 网页分析筛选系统
主要负责对抓取后的网页数据进行分析处理，基于分布式计算框架将原始网页转化为结构化数据，并根据网页的特征和内容信息进行质量筛选，通过质量筛选的网页数据交付给网页建库系统。
3. 网页建库系统
基于分布式离线或实时（例如 Hadoop、Storm）计算框架对质量筛选网页进行属性提取、文本分词、创建结构化的正排和倒排索引数据，交付给网页检索系统提供检索服务。
4. 网页检索系统
基于几千台机器组成的检索服务集群，依赖网页建库系统提供索引数据，对用户请求的 query 结果进行倒排求交、排序计算（各种 ranking 策略）、检索结果合并等处理，将检索结果提供给用户使用。
在实际的搜索引擎应用中还需要考虑时效性和效果：
时效性
从用户检索的时效性方面，会将上述的四个系统部署成多个数据处理流程线，主要包括以下三个：
1. 实时索引
网页抓取产出的网页提交到基于 Storm 实时计算框架的分布式计算系统，进行网页分析、网页筛选和建库预处理，输入到消息队列服务（例如 kafka），线上机器读取消息队列进行实时建库，同时提供检索服务。
2. 增量索引
网页抓取产出的网页数据输出到分布式文件系统（例如 HDFS）和分布式数据库（例如 HBase）中，基于分布式离线计算框架进行网页分析，网页筛选和网页建库预处理，并将增量索引合入线上索引，提供检索服务。
3. 全量索引
直接读取分布式数据库中已经通过质量筛选的网页数据，基于离线计算框架进行分布式建库，并将索引数据推送到线上替换旧的索引，提供检索服务。
效果
从用户检索的效果方面，需要专门负责质量策略的计算，主要有以下两个方面：
1. 数据屏蔽
死链、色情、作弊、敏感等等，基于线上索引和策略，利用分布式离线或实时计算框架（例如 Spark、Storm）对线上网页进行策略处理，并将计算结果推送天级或者实时到线上，对线上的数据进行屏蔽处理。
2. 检索效果
根据网页质量、网页特征、用户行为等信息，利用离线或实时计算框架对线上网页进行策略处理，并将计算结果推送天级或者实时到线上，对线上的索引进行更新，提供更优的效果。
我们知道英文与中文搜索引擎是挺不同的，很直观的原因是“中文分词”问题，这个问题为什么会引起中英文搜索引擎如此巨大的差异，相信读者也跟我一样有一些疑惑，郝老师对此也进行了分析。
中文搜索与英文搜索算法策略大体上是相同的，但因面对的用户群的文化背景以及使用语言的不同，必然存在着诸多差异。
“分词”，这是英文天然不存在的问题。但它却是中文搜索的最重要、最基础模块之一。分词的准确率直接影响着搜索结果的相关性。
分词有两个难点：歧义切分和未登录词识别。随着大规模语料库的使用，机器学习技术的兴起，这些都已有较好的解决方案；另外在搜索引擎中分词粒度也是个需要权衡的问题，考虑到相关文档的召回率一般会做细粒度切分。
中英文搜索引擎的差异主要体现在中英文信息处理技术的使用上。搜索引擎对用户 query 的分析有语法、语义、语用三个层次，越往后越复杂，而中文又是重义不重形的语言，这又给以上各环节处理带来了更大的困难。
语法分析
语法分析主要指词性标注和依存分析。英文等屈折语在单词上有单复数、时态、动名词等变化，很容易区别不同词性；而汉语，同样一个词在不同语境下可能是名词也可能是形容词或动词等，同一个词在担任不同语法功能时完全没有形态变化，这给计算机进行自动标注及分类时带来了更多的挑战。同理，语义角色标注等都存在如上问题。
语义分析
近来在深度学习技术的助推下，自然语言处理技术也获得了极大的发展，语义向量表示将语义分析水平提升到一个新的水平。
随着研究深入，中文与英文差异也逐渐显露出来，英文能从单词的词根中获得大量的泛化语义信息，而中文词从其单字获取的信息确很有限，但已有研究表明，中文却可以从字的偏旁部首中获取大量的泛化语义信息。
语用分析
中英文搜索分别面对着东西方完全不同的文化背景的用户，他们可能有着很大不同的语言联想网络及隐喻风格。今后随着搜索引擎变得越来越智能，我们也会在不断的探索中接触并了解到两者在语用间更多更具体的差异。
以上，从搜索引擎所面临的不同自然语言问题角度谈了他们的差异，此外在工程上，中英文还存在编码识别、转换、对齐等一些具体问题，实际工作中虽然繁琐，但并未造成特别大的困扰。
技术的发展，其实很大程度上都是因为业务在驱动的，随着业务量的不断增大，业务类型的多样化，在这期间，搜索引擎也是在不断进行完善。
早期的搜索引擎索引的网页数量比较小，用户的查询也相对比较简单，通过倒排索引加基础的文本相关性算法（比如 BM25）就能较好地满足。
现代搜索引擎抓取的网页规模在数千亿，索引的网页通常也有几百亿，需要非常强大的数据处理能力和比较智能的排序算法支撑。
从用户查询的角度，随着搜索引擎的普及以及人们对搜索引擎依赖的加深，搜索引擎出现了大量非常复杂和口语化的查询。这就要求搜索引擎具备强大的查询理解能力，通过依存句法分析、机器翻译等 NLP 技术对用户提交的查询进行纠错、改写、核心词提取等处理，为后续的检索、排序提供指导。
从网页的角度，由于经济利益的驱动，互联网上存在大量作弊、采集网页，作弊手段层出不穷，这就要求搜索引擎具备“火眼金睛”，能够甄别出作弊网页并进行打压。
360 搜索最近一年基于安全大数据和大规模机器学习算法推出的后羿、哪吒等算法，就是为了打压采集以及利用“黑帽 SEO”手法恶意骗取流量的站点，保护用户的正常体验，建设良好的互联网生态环境。
从排序的角度，早期的搜索引擎在排序的时候只用到寥寥无几的特征，通过简单的人工规则或者线性模型拟合即可达到不错的排序效果。
现代搜索引擎在排序的时候通常用到成百上千维特征，人工规则或者简单的线性模型已经无法搞定，需要更加复杂的非线性模型来拟合这些特征（这类模型统称为 learning to rank 模型）。
同时，近年来深度学习技术的发展，为搜索引擎提供了更加强大的语义处理能力，基于 DNN/CNN/RNN 等深度学习模型计算出来的语义相似性特征是搜索引擎排序的非常有效的特征，在各大搜索引擎应该都有应用。
另外，搜索本身就自带人工智能基因，网络用户只需要输入简单的查询关键字请求，搜索引擎会理解用户意图从海量网页中返回用户相关网页链接结果。
然而随着移动互联网的发展，移动用户以语音、图片、以及地理位置等新的输入检索形态查询信息，获取知识和信息的方式也从传统的用户主动检索转变到被动的智能信息推送。
人工智能时代的到来，搜索将进化为智能助手，与其交流语言不再是搜索关键字，而是采用自然语言，搜索返回给用户不再是网页链接结果，而是直接给出答案并给予建议。
360 搜索正朝着这个方向而努力，值得一提的是今年 8 月 360 搜索五周年移动 APP5.0 我们发布了拍图写诗功能，得到了很好的市场反馈。360 搜索在未来将在机器翻译、智能问答、知识创造等 AI 前沿技术进行探索并进行产品落地。
接下来，以 360 私有云为例，郝老师从厘清私有云与公有云的区别入手，为读者介绍了云平台的相关知识，同时也分享了在构建 360 容器云时的一些思考。
云计算提出的愿景，是要像用水用电那样使用 IT 服务。企业无需自建 IT 基础设施，便可享受专业的高水平的 IT 服务，且按需付费，这就是公有云。对于一些大型企业，内部机构众多，总部集中建立 IT 基础设施，为各部门提供类似公有云的 IT 资源租用服务，则称之为私有云。
公有云资源丰富，但是可靠性与安全性有待商榷；私有云在安全性、稳定性上更有优势，缺点是建立成本高，共享性低。其实最近还有个概念比较火，叫做混合云。顾名思义就是融合了公有云和私有云的特点，在此基础上发展起来的一个概念，它是近年来云计算的主要模式和发展方向。
出于安全考虑，企业更愿意将数据存放在私有云中，但是同时又希望可以获得公有云的计算资源。在这种情况下混合云被越来越多地采用，它将公有云和私有云进行混合和匹配，以获得最佳的效果，达到既省钱又安全的目的。
其实大多数云是自下向上而来的，抽象并分割底层基础设施，以便达到降低管理成本和提高资源利用率的目的，这个是一个漫长发展的过程。不巧的是，360 搜索这边没有经历 IaaS 这个重要的阶段，准确地来说，过去几年 IaaS 架构并不能很好满足引擎对性能的需求。
但是，我们现在面临上面提到的需求，所以我们换了个思路，由业务需求出发去抽象 PaaS，然后重新设计和组合底层基础设施以便满足平台的需求，这便是 360 容器云。
容器云平台的搭建一方面是减轻了运维压力，但这不是最主要的。最主要的目的其实是省钱，也就是提高资源利用率。之前是以机器为单位，由人来做调度，粒度和效率显然不够，无论是设备资源还是人力资源都存在浪费。
还有一个，很多人其实经常忽视软件迭代流程中的发布这个环节，这个在搜索这边尤其重要，我们大量策略、算法要到线上环境去验证，同一个模块可能有很多个版本在同时运行，这是对发布效率的挑战。
其实我们最终的目的是把省下来的资源更多地投入到业务研发中去，并加速迭代效率，为用户提供更优质的搜索服务。
长期来看，随着平台周边设施的完善，当大家习惯了新的流程后，开发人员、业务运维、系统管理员这之间的夺命连环锁终于被打破。看到这点其实我们是很欣慰的。另一个方面，每个季度开完预算会，大家终于可以笑着走出会议室了（笑）。
还有一个方面，随着容器云思想在各部门之间传播，大家也开始关注自己的系统架构设计，很多陈旧的系统也开始重构，以便适应未来的云环境，并更有效地去迭代复杂的需求。
现在微服务这个词比较火，我们总说用容器去承载微服务，其实正是容器的思想，给了人们如何改造传统架构的启迪，推进了微服务的落地。
嘉宾介绍：
郝一昕，360 搜索架构师，现供职于 360 搜索，负责私有云平台的设计与研发；主要任务是云平台基础设施的设计与实现，包括网络、存储、调度系统等；Mesos 社区 Contributor 之一，与社区积极互动，建立了 360 搜索与社区的良好的合作关系；曾供职于爱奇艺，构建了网络基础设施监控系统与流量分析预警平台；对容器技术架构、自动化运维监控、网络架构有比较深入的理解。
