百度搜索与推荐引擎的云原生改造 | Geek大咖说第一期

导读：从去年开始，百度MEG（移动生态事业群）架构平台上的用户产品逐步进行云原生改造，现在已基本完成。现阶段更多关注动态弹性能力、动态管理机制的建设。本期「Geek大咖说」，咱们邀请到来自推荐技术架构部的传玉老师， 跟你们聊聊百度搜索与推荐引擎云原生改造的阶段性策略，以及对将来发展的思考。

嘉宾简介 ：传玉

2012年起专一于搜索引擎与推荐引擎方向；2016年开始负责自有的资源调度和容器编排系统的研发工做；2019年开始负责部分通用基础组件的研发工做，并开始在MEG用户产品内部全面推动云原生架构改造。

01 核心关注两个“效率”，实现降本增效
“说云原生的目标是让整个开发上线应用的过程更简单，这一点我是赞成的。百度的搜索与推荐引擎规模都很是庞大、业务极其复杂，尤为是搜索，有着20多年的历史，没法彻底按照一套新的理念来设计逻辑。因此，咱们在尝试云原生时，必须结合咱们本身的基因和现状。”
云原生架构的主要价值在于效率的提高，包括资源利用效率和研发效率两个方面。
从资源利用效率上，指望经过容器化和动态资源调度实如今线服务的充分混布，让集群总体资源使用更加均衡，更加高效，从而下降总体的机器成本。此外，经过云平台实现高效率的资源化交付取代物理整机交付，提高资源的流转效率，让内部的资源可以更快速地流转到重点业务上，支持业务的快速发展。
在研发效率上，一方面经过微服务改造，解耦不一样业务团队的迭代，减小团队间的互相影响，去提高业务迭代效率。另外一方面指望把通用基础架构能力下沉到云原生基础设施上，提高新业务架构能力的基线水平。
例如一些局部故障容错能力，在一些业务线上相似的架构机制已经很成熟了，但对于新的业务线很难直接复用，每每还须要再踩坑，参照成熟业务线的经验，逐步建设，若是咱们能把这些通用的能力以标准化和规范化的形式沉淀到云原生基础设施里，那创新业务线就能比较简单地复用，少走弯路，尽量少欠技术债。
此外，云原生架构对研发效率上的提高，还体如今下降线上问题的处理以及维护上人力和时间。 一般业界有个说法：一个存储系统好很差用，关键看他的运维水平。
但实际上，不只是存储系统，对于不少创新项目来说，若是太多的人去支持维护线上服务的运行解决线上问题，那么投入研发上的人力就相对减小了，相应的发展速度可能就会受影响 经过一些云原生的基础设施，咱们能够把各类常规的运维操做标准化和自动化，好比机器故障的自动维修，服务实例故障自动迁移，服务容量的自动化调整。一方面能够减小运维的人力成本，另外一方面不少状况下自动化的系统能比人工作的更好。 “在以前，咱们也是有自动化机制的。但应用云原生架构带来的好处，是让咱们可以经过一个更规范、更标准、更可持续发展的路径，去作这些自动化的机制。就是把那个大量的人力从这种线上服务的维护中解放出来。在团队规模不变的状况下，维护人力减小了，能全力投入研发上的人力天然就多了，总体研发效率也就上来了。” 整体来讲，云原生最大的意义在于提升效率，提升了总体研发的baseline。
尤为是在作新产品时，可以省去购买资源的成本，在基础阶段也省去用太多的人力投入来保障产品上线顺利。成本越低、能作的创新就越多。这样就让每个新产品都避免输在起跑线上。

 02 规范服务设计标准，为云原生改造立好规矩
MEG架构平台在2019年时已经全面云化。可是，多数服务的迁移仅仅是部署方式从物理机部署转变为PaaS平台容器内部署，并无针对云环境以及云能力进行架构上的改造和升级来得到更大的成本和效率上的收益。基于这一问题，指望经过进一步规范MEG架构平台服务设计标准，实现从云化架构到云原生架构的转变。 “实现云原生化以前，咱们已经具有必定的基础。首先是从整个组织上具有了微服务的思想；其次是从实践上制定了一系列微服务最佳实践的标准，创建了《MEG用户产品架构云原生内部规范》；第三，咱们已经有一系列公共的基础设施。” 传玉参考了业内普遍承认的云原生应用的特征，结合百度内部的先行实践，为了保证云原生架构落地的效率和效果，从如下三个方面来规范服务模块设计：

一、微服务化： 每一个服务粒度应该在限定的范围内； 二、容器化封装： 一个服务的部署，应该只依赖基础架构以及本容器内的组件，而不该该依赖其余业务服务； 三、动态管理： 每一个服务应该能够动态调整部署，而不影响自身对外承诺的SLA。

*各项规范的评估方式：

规范	验收方式
资源开销	由资源平台统计，按实例总数计算符合规范的比例
部署时间	由PaaS平台统计，按实例总数计算符合规范的比例
单一包描述	由业务自行上报，OP验收 - 以部署平台收到包描述，可以自动完成服务部署为准，按实例总数计算符合规范的比例
仅存在资源依赖	业务上报，OP验收 - 以PaaS平台在任意资源知足的机器上可完成实例部署&启动&测试为准，按实例总数计算符合规范的比例
经过Naming Service访问	业务上报，OP验收 - 经过PaaS平台迁移实例，可以成功迁移，且系统无异常为准，按实例总数计算符合规范的比例
可容忍单点异常	OP验收/混沌工程实验验收，按实例总数计算符合规范的比例
服务状态可感知	业务上报，OP验收 - 以PaaS平台可以正常识别服务启停为准

*业务总体评估方式：

一、 未接入PaaS的服务，以不知足标准计算； 二、 以服务为单位评估是否知足规范，只有当一个服务同时知足上述全部标准时，才认为一个服务是知足云原生架构规范的； 三、 每一个业务线以百分制计算云原生规范指数，计算方式为（符合规范的服务模块所占的quota总量 / 总quota），使用CPU quota/MEM quota，按比例低的计算； 四、 各单项分数，仅做为内部指标参考, 用于分析瓶颈，推进落地。

 03 划重点，云原生化的阶段性实现路径
从云化到云原生化，是一个很是复杂的过程。在制定了云原生改造规范后，陆续经历了4个阶段，分别是：微服务改造、容器化改造、动态管理、进阶云原生，而MEG的云原生化进程并未中止，而是朝着第5个阶段——声明式架构继续探索。
第一阶段：微服务改造
起初，百度MEG架构平台实现全面云化时，将全部的架构服务、资源都托管到内部的云平台上，可是当时仍遇到了对资源的利用问题。MEG架构平台推行云原生的第一件事，就是要求全部的服务去作微服务改造，消灭巨型服务。 “这些巨型服务，会致使总体的资源分配容易出现碎片，好比某个服务占用一台机器80%的资源，那剩下20%颇有可能分不出去，就会出现独占的现象，不能混布。还有一些服务在部署以前，要对整机的环境作一些修改。
所以，虽然当时全部的资源都托管在了云平台上，但咱们在使用时仍然与直接使用机器差别不大，OP投入了不少，总体线上资源利用率，包括资源的分配率，相对较低。”  微服务拆分以后，带来了几个变化：首先是性能提高。
虽然多了一些RPC的开销，但拆分以后，每个服务均可以被针对性的优化，全部的扩缩容操做亦可只针对这一服务的逻辑进行。所以从总体成本、延迟等各方面使性能达到大幅提高。
其次是研发效率提高。
按原来的产品和策略的迭代，不少时候一个服务须要几百人共同进行，上线耗时长。但拆分以后，虽然多出几十个模块，但一个模块只需两三我的迭代便可，也能够随时随地上线。这对研发效率总体提高是很大的。 “好比说咱们的Feed视频推荐服务，在拆分前是一个巨型服务，迭代频繁。单实例450 CPU，100G内存，单模块越40+ 策略RD参与开发，天天上线feature 10+个。因此在运营过程当中产生了大量资源碎片、上线时间长、内存迭代困难。
咱们作了3件事：

第一， 按推荐业务逻辑，拆分为聚合和召回两层； 第二， 召回层按召回算法区分，拆分为若干并行的召回服务，召回服务部分可丢； 第三， 聚合层拆分为机器学习预估服务和聚合服务两块，机器学习服务使用avx指令集加速。”  

Feed视频推荐服务改造的成果是：

l  单个大模块拆分为10+个小模块，最大的模块内存占用 < 40G. l  总体cpu占用减小23%，内存占用减小84% l  延迟下降50+ms，稳定性从不足99.9%提高到99.97% l  迭代效率大幅提高，完全消除了搭车上线互相block的状况.

第二阶段：容器化改造
MEG架构平台作容器化改造，就是要求全部的服务把它依赖的东西，都放到容器内。实现全部服务的一键式的部署，也就是自动化的部署。 可能如今的一些新兴的 互联网企业中并不存在这一的问题，由于你们不少服务自己就是基于 Docker 的。但百度搜索系统具备二十年历史，必须花时间去作这件事。这个过程当中，一个典型是改造搜索的BS模块，它的年龄几乎和百度搜索同样大。 二十年前，百度架构师在设计BS时，考虑的是尽量占满整机资源。 “那个时候 SSD 很是昂贵，因此设计BS时，就但愿能把SSD用满，同时，为了方便，并无所有显示申请，好比你声明了用10G，而实际上却用了60G。这在当时没什么问题，由于一台机器只有一个服务，使用资源时不管是显示仍是隐式，都跟别人不要紧。如今的磁盘硬件已经跟二十年前彻底不一样了，单个服务的计算量每每不足以占满征集整机资源，为了不浪费，就须要把其余服务混布上去。这样一来，问题就出现了，就得改。” 第一件事，每一个服务显式地声明自身须要占用的资源，改掉贪婪式抢占的策略。
把全部的资源放在他本身的容器里。也就是说，把BS从一个机器级的服务，变成了一个容器级的服务，不占用容器外资源。作到这一点，才能让容器编排系统的调度能力真正发挥做用。 第二件事是提高服务的部署效率。
有一些比较老的服务，可能部署的时候须要去拉不少额外的数据，甚至部署的时候还须要op去人工作一些机器的参数和配置调整。这都会致使部署无法自动化执行，或者部署的速度太慢。为了改善效率，须要把服务对于物理环境的依赖都消除，只依赖容器内的环境。此外，咱们也须要作P2P的下载优化，和一些数据的实时化的改造，去优化服务启动的速度。 “咱们以前曾经用过一个存储数据类的服务，逻辑上来讲是能迁移的，但实际上一个实例的迁移大概耗费8小时。这种的可迁移性就没有太大意义。由于存储 数据服务受副本数/容量/并发数的限制，好比说一个集群有成百上千个实例，但最多一轮只能迁移几个， 而后迁移一轮的话，要耗费8个小时。那整个集群迁移的时间就会很是长。想进行内核升级、操做系统升级、故障维修等就会很是麻烦。所以，咱们要作P2P分发优化，作数据下载和数据分发的优化，把部署速度提上去。”

第三阶段：动态管理
动态管理这件事，主要说的“动态”，好比线上服务是否能随时迁移、随时扩缩容。
它分为两个层面： 一方面从业务自己来看，动态管理要求全部的服务都具有必定程度的弹性和容错能力。
由于线上的实例但凡涉及到扩缩容或迁移，就会出现短期内的重启或不可用。这就首先要求线上全部服务都具有必定的故障容忍能力。其次，服务须要具有自动的负载均衡的能力（最简单的方式就是使用naming service来访问服务），有新的实例加入，须要能自动去打散流量，有实例故障或者退场，也须要能及时屏蔽 另外一方面从基础设施层面来看，既然全部的服务都能随时作迁移和扩缩容。
那咱们就能够在服务的容量和流量上按需操做 实现自动化的按需分配。 “一旦某个业务要作一个运营活动，就须要临时作大量的扩容操做。这个过程在非云原生的模式下原来很麻烦，要先去找一批物理机，而后把服务部署到这批新机器上实现扩容，作完了活动之后再把服务下掉，以后再退出物理机，整个过程涉及到大量的人工操做，成本是比较高的。但在动态改造后，找物理机的操做就没有了。咱们全部的服务在一个大的资源池里面。任意业务短期内须要额外的资源，直接在里面扩缩容就行了。由于不一样业务的需求时段也不一样，还能错峰使用。 “再有就是资源使用的弹性上，好比说对于我本身的推荐系统来讲，若是资源池里有额外的资源可用，这能让个人推荐系统 经过更多的复杂计算 来提供更好的用户体验。因此在没有运营活动时，咱们用这部分闲置资源来提高推荐和检索效果。当有运营活动时，咱们再把这份资源吐出来给运营活动。这样方便咱们总体对资源进行平衡使用，并且这个过程应该是一个代价很是低的一个自动化的操做。”

第四阶段：进阶云原生
为了继续下降成本、提高效率，从2021年开始，MEG架构平台的云原生改造，在动态管理的基础上增长了像Serverless、Function as a Service等进一步的操做。 在改造以前，整个系统的那个容量是基本固定的，一旦有突发流量就只能降级。经过Serverless机制，实时监控流量，发现异常就能在几分钟内自动完成扩容。 而Function as a Service的话，是让研发效率提高到极致的一个方向。它能让业务同窗只关心本身想要实现的逻辑。至于在架构上怎么拆分微服务、怎么作流量的调控、怎么作作容量管理，所有交给底层的系统来执行。 

第五阶段 声明式架构
传玉提到，其实在进阶云原生阶段作的一些事情，都在向着声明式架构靠拢。好比Function as a Service就是声明式架构中关键的一环，包括Serverless机制的实现，最终目标也是但愿能把策略和架构完全解耦。 “如今不少架构在设计的初期都是没什么太大的问题的。但随着业务发展，运行了一段时间后每每都须要重构，由于随着业务的变化，系统面临的业务场景已经不同了。但架构的调整是很是复杂的，通常都会伤筋动骨，还会涉及到大量的业务策略逻辑迁移等。咱们指望尽量的把业务和架构拆分开，把业务逻辑和架构设计拆分开。这样业务描述逻辑时尽量简单，咱们的系统能够根据这些描述自动拆分Function，再把这些Function发送到系统里去执行。” 若是能作到架构&业务分离，那么MEG架构平台会变得很是灵活。
包括有哪些节点、执行哪些Function、用这些Function怎么去作链接、怎么去作组合，所有交由自动的推导系统去实现。如此一来，咱们的系统会变成声明式的，也就是说你在上面声明你的业务逻辑，它会自动推导出须要怎样的架构，自动去执行。  “这样这固然是一个最终的理想态。咱们在实现的路上，还须要作不少不少事情。” 以上，是百度MEG架构平台完成云原生改造的一些关键路径。在后续的分享中，传玉还会围绕服务治理、自动化、混沌工程等方面，重点聊聊过程当中的一些问题和解决办法。

原文连接

https://mp.weixin.qq.com/s/lVzHC5ISrQlog_ZKGdqNGw

推荐阅读

｜百亿级流量的百度搜索中台，是怎么作可观测性建设的？

｜十亿级流量的搜索前端，是怎么作架构升级的？

----------  END  ----------

「百度Geek说」全新上线

有兴趣的同窗，也能够加入「百度Geek说微信交流微信群」，在群内继续交流。

若是，你对百度的其余岗位感兴趣，请加入「百度Geek说官方招聘群」，了解最新岗位动态，总有一款JD适合你。

技术干货 · 行业资讯 · 线上沙龙 · 行业大会

招聘信息 · 内推信息 · 技术书籍 · 百度周边