共计 5723 个字符，预计需要花费 15 分钟才能阅读完成。
导读 ：从去年开始，百度 MEG（挪动生态事业群）架构平台上的用户产品逐渐进行云原生革新，现在已根本实现。现阶段更多关注动静弹性能力、动静管理机制的建设。 本期「Geek 大咖说」，咱们邀请到来自举荐技术架构部的传玉老师，跟大家聊聊百度搜寻与举荐引擎云原生革新的阶段性策略，以及对将来倒退的思考。
嘉宾简介：传玉
2012 年起专一于搜索引擎与举荐引擎方向；2016 年开始负责自有的资源调度和容器编排零碎的研发工作；2019 年开始负责局部通用根底组件的研发工作，并开始在 MEG 用户产品外部全面推动云原生架构革新。
01 外围关注两个“效率”，实现降本增效
“说云原生的指标是让整个开发上线利用的过程更简略，这一点我是批准的。百度的搜寻与举荐引擎规模都十分宏大、业务极其简单，尤其是搜寻，有着 20 多年的历史，无奈齐全依照一套新的理念来设计逻辑。所以，咱们在尝试云原生时，必须联合咱们本人的基因和现状。”
云原生架构的次要价值在于效率的晋升，包含 资源利用效率和研发效率两个方面。
从资源利用效率上，冀望通过容器化和动静资源调度实现在线服务的充沛混布，让集群整体资源应用更加平衡，更加高效，从而升高整体的机器老本。此外，通过云平台实现高效率的资源化交付取代物理整机交付，晋升资源的流转效率，让外部的资源可能更疾速地流转到重点业务上，反对业务的疾速倒退。
在研发效率上，一方面通过微服务革新，解耦不同业务团队的迭代，缩小团队间的相互影响，去晋升业务迭代效率。另一方面冀望把通用基础架构能力下沉到云原生基础设施上，晋升新业务架构能力的基线程度。
例如一些部分故障容错能力，在一些业务线上相似的架构机制曾经很成熟了，但对于新的业务线很难间接复用，往往还须要再踩坑，参照成熟业务线的教训，逐渐建设，如果咱们能把这些通用的能力以标准化和规范化的模式积淀到云原生基础设施里，那翻新业务线就能比较简单地复用，少走弯路，尽可能少欠技术债。
此外，云原生架构对研发效率上的晋升，还体现在升高线上问题的解决以及保护上人力和工夫。
通常业界有个说法：一个存储系统好不好用，要害看他的运维程度。
但实际上，不仅是存储系统，对于很多翻新我的项目来讲，如果太多的人去反对保护线上服务的运行解决线上问题，那么投入研发上的人力就绝对缩小了，相应的倒退速度可能就会受影响
通过一些云原生的基础设施，咱们能够把各种惯例的运维操作标准化和自动化，比方机器故障的主动培修，服务实例故障主动迁徙，服务容量的自动化调整。一方面能够缩小运维的人力老本，另一方面很多状况下自动化的零碎能比人工做的更好。
“在之前，咱们也是有自动化机制的。但利用云原生架构带来的益处，是让咱们可能通过一个更标准、更规范、更可继续倒退的门路，去做这些自动化的机制。就是把那个大量的人力从这种线上服务的保护中解放出来。在团队规模不变的状况下，保护人力缩小了，能全力投入研发上的人力天然就多了，整体研发效率也就上来了。”
总体来说，云原生最大的意义在于提高效率，进步了整体研发的 baseline。
尤其是在做新产品时，可能省去购买资源的老本，在根底阶段也省去用太多的人力投入来保障产品上线顺利。老本越低、能做的翻新就越多。这样就让每一个新产品都防止输在起跑线上。
02 标准服务设计标准，为云原生革新立好规矩
MEG 架构平台在 2019 年时曾经全面云化。然而，少数服务的迁徙仅仅是部署形式从物理机部署转变为 PaaS 平台容器内部署，并没有针对云环境以及云能力进行架构上的革新和降级来取得更大的老本和效率上的收益。基于这一问题，冀望通过进一步标准 MEG 架构平台服务设计标准，实现从云化架构到云原生架构的转变。
“实现云原生化之前，咱们曾经具备肯定的根底。首先是从整个组织上具备了微服务的思维；其次是从实际上制订了一系列微服务最佳实际的规范，建设了《MEG 用户产品架构云原生外部标准》；第三，咱们曾经有一系列公共的基础设施。”
传玉参考了业内宽泛认可的云原生利用的特色，联合百度外部的后行实际，为了保障云原生架构落地的效率和成果，从以下三个方面来标准服务模块设计：
1、微服务化：每个服务粒度应该在限定的范畴内；
2、容器化封装：一个服务的部署，应该只依赖基础架构以及本容器内的组件，而不应该依赖其余业务服务；
3、动静治理：每个服务应该能够动静调整部署，而不影响本身对外承诺的 SLA。
各项标准的评估形式：
业务整体评估形式：
1、未接入 PaaS 的服务，以不满足规范计算；
2、以服务为单位评估是否满足标准，只有当一个服务同时满足上述所有规范时，才认为一个服务是满足云原生架构标准的；
3、每个业务线以百分制计算云原生标准指数，计算形式为（符合规范的服务模块所占的 quota 总量 / 总 quota），应用 CPU quota/MEM quota，按比例低的计算；
4、各单项分数，仅作为外部指标参考, 用于剖析瓶颈，推动落地。
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/lV…
举荐浏览
|百亿级流量的百度搜寻中台，是怎么做可观测性建设的？
|十亿级流量的搜寻前端，是怎么做架构降级的？
|百度信息流和搜寻业务中的弹性近线计算摸索与利用
———- END ———-
「百度 Geek 说」全新上线
有趣味的同学，也能够退出「百度 Geek 说微信交换微信群」，在群内持续交换。
如果，你对百度的其余岗位感兴趣，请退出「百度 Geek 说官网招聘群」，理解最新岗位动静，总有一款 JD 适宜你。
技术干货 · 行业资讯 · 线上沙龙 · 行业大会
招聘信息 · 内推信息 · 技术书籍 · 百度周边
