作者 | zzbtie

导读

云原生环境下事务大规模迭代的本钱压力日益增大。咱们以Serverless理念为辅导，针对百度Feed的后端服务，从弹性、流量、容量视点构建多维度个性化服务画像，并依据画像对服务进行弹性弹性，随流量动摇自适应调整服务容量，有效地降低事务运转本钱，本文重点介绍上述相关战略与实践计划。

全文6542字，预计阅读时刻17分钟。

01 布景

随着云原生在百度内部各产品线的推动，微服务已成为各事务线的标配，在查找、引荐、广告这类重战略核算事务场景中，后端一般由许多微服务组成，这些微服务遍及存在如下特色：

• 实例多：每个服务由多个实例组成，微服务间经过rpc通信，服务一般支持横向/纵向扩缩容。

• 核算重：微服务包含比较复杂的事务逻辑，一般服务本地会加载一些战略词典进行复杂的战略核算，服务自身需求的cpu等资源比较多。

• 7*24h：服务一般运用固定的容量供给7*24h在线服务，并且由云原生组件进行守时的容量办理，例如冗余容量回收等。

百度App引荐服务（简称百度Feed）作为典型的引荐事务场景，后端包含很多战略复杂、重核算的微服务，这些后端服务遍及运用固定的容量为数亿级用户供给7*24h的信息流引荐服务。关于百度Feed的后端服务而言，用户流量存在着典型的波峰浪谷现象，而在流量低谷期和顶峰期运用相同的容量无疑存在资源糟蹋，本文介绍百度Feed在后端服务进行Serverless的实践，详细说明依据服务画像的弹性弹性相关技能计划与完成。

02 思路与方针

业界对Serverless的大规模实践在FaaS侧比较多，一般实例较轻量，容器的生命周期也比较短。而咱们面临的是比较“重”的后端服务，这类服务的实例扩容一般包含以下几个阶段：

• PaaS初始化容器：PaaS依据实例的quota需求（cpu、内存、磁盘等）寻找合适的机器分配容器，并初始化容器。

• 二进制文件与词典文件预备：将服务的二进制文件和词典文件从远程下载到本地，并进行解压。

• 实例发动：实例在本地依据发动脚本发动进程，并将实例信息注册到服务发现。

后端服务实例扩容的时刻一般在分钟级，而词典文件的下载与解压一般占全体扩容时刻70%以上，关于词典较大的实例则耗时更多，这导致后端服务面临流量改变时无法在极短的时刻内（例如秒级）进行弹性来保证容量安稳。然而这些后端服务的流量一般是周期性地动摇，具有显着的潮汐特征，如果咱们能对服务的流量进行较为精确的猜测，那么面临流量的上涨咱们能够适当地提早扩容来保证容量，面临流量下降能够进行必定的缩容来节约资源本钱，完成资源按需运用。

全体而言，咱们以云原生组件为根底，为每个服务描写出多维度的个性化服务画像，包含弹性维度、容量维度、流量维度，在保证服务安稳性的前提下完成服务容量随流量动摇的自适应调整。完成作用如下图所示，左图中常态办法下一个服务耗费的资源量是固定的不随着流量动摇而改变（资源量需满足峰值流量所需的容量），右图中Serverless形式下服务耗费的资源量随流量动摇而动态调整。

03 全体架构

全体的弹性弹性架构如下图：

• 服务画像：包含弹性画像、流量画像和容量画像，多维度描写了服务的个性化特征。

• 弹性战略：应对不同场景下的弹性战略，包含猜测弹性、负载反应弹性和守时弹性，是完成Serverless的根底中心战略。

• 云原生组件：包含PaaS和ALM（app lifecycle managent），其间PaaS担任履行服务的弹性动作，ALM担任办理一切触及服务的数据和战略。

• 资源：包含集团云和公有云两类弹性资源，Serverless支持两类云资源相关的服务弹性。

• 安稳性保证：为弹性弹性安稳性保驾护航的各类机制，包含弹性巡检、容量巡检、状况巡检和一键干涉等。

• 弹性渠道：完成全体战略的支持渠道，包含资源预查、流程编列、状况轮转和事件引擎等根底机制。

接下来别离介绍中心的战略和实践，包含服务画像、弹性战略、安稳性保证。

04 服务画像

百度Feed后端包含很多服务，各服务的词典文件巨细不同，有些服务的cpu核算比较多，有些则io比较多，各服务在可弹性性、流量动摇状况和负载才能都存在差异。因而咱们围绕服务的线上运转数据，从弹性维度、流量维度和负载维度构建个性化的弹性画像、流量画像和容量画像，多维度描写出每个服务的个性化特色。

4.1 弹性画像

方针：从可弹性视点描写服务的弹性才能。依据云原生方针、服务实例标准、实例布置搬迁时刻、资源依靠等维度描写服务的弹性才能，将事务内各服务划分为如下三类：

高弹性才能：彻底无状况服务，可随意无损弹性，弹性速度较快。

中弹性才能：有必定弹性才能，但需求较长时刻康复服务状况，弹性速度一般。

低弹性才能：几乎无弹性才能，需求较大的价值康复服务状况，弹性速度较差。

弹性画像构建：

对各服务从PaaS拿到多条最近实例扩容记载获取实例扩容时刻，取中位数作为该服务的实例布置时刻，结合该服务的实例quota（cpu、memory、磁盘），是否有状况，是否存在外部依靠，经过简单的规则将一切服务划分为高、中、低弹性才能；一起咱们推动服务进行标准化容器改造和存算别离来提高服务弹性。

弹性才能提高：

• 标准化容器改造：之前百度Feed事务内大部分服务实例都是非标准化容器，在端口阻隔、资源混部方面存在缺点，无法支持存算别离，影响服务的全体布置搬迁功率；经过推动服务标准化容器改造，各服务已支持跨资源池、跨云调度布置，可充分利用各资源池的碎片化资源，提高了资源交付功率与混部才能，有效改进服务的弹性弹性才能

• 存算别离：关于词典文件较大的后端服务，服务扩容的耗时会集在词典文件的下载与解压，咱们推动该类服务接入云盘同享卷，服务实例布置时可远程读取词典内容加载到内存中，减少词典文件的下载和解压耗时，明显提高了服务的布置和实例搬迁时刻，有效提高了服务的弹性弹性才能

4.2 流量画像

方针：

描写服务的流量改变趋势，猜测未来某个时刻的流量进而方便依据流量装备对应的容量。

流量画像构建：

• cpu运用量：尽管流量画像是依据前史流量数据来猜测未来流量数据，可是咱们不直接收集qps数据，而是运用cpu运用量来替代qps。首要原因是后端服务一般有多个rpc/http接口，不同服务的接口数量不同，而且一个服务内的不同接口的qps、功能存在差异，而单一接口的qps方针无法反响服务全体的资源耗费，这导致运用多接口qps数据和服务的资源耗费之间树立映射存在困难。后端服务首要的资源开支是cpu，而服务的cpu运用量是每个服务的单一通用方针，它直接反响了该服务在处理多接口请求时的全体资源开支，因而该方针比较qps能更直接的描写出服务的容量需求。

• 时刻片：后端服务的流量遍及呈24小时周期性动摇，咱们将一天24小时划分为多个时刻片；关于每个服务，咱们统计它的前史数据（例如曩昔N天在每个时刻片对应的流量数据）并依据前史数据来猜测未来某个时刻片的流量状况。例如将24小时划分为24个时刻片，每个时刻片对应1个小时，咱们想猜测某个服务在下午2点～3点对应时刻片内的流量状况，那么依据曩昔7天（N=7）该服务在下午2点～3点的流量数据来进行猜测。其间，时刻片的巨细可装备，时刻片装备的越小则对应时刻范围越小，关于流量在单位时刻改变较大的服务可装备较小的时刻片，而流量动摇较小的服务可装备较大的时刻片。

• 监控收集：对每个服务，周期性地收集它一切实例的负载数据（包含cpu运用量等）会聚为服务数据，并在对应时刻窗口（window巨细可装备）对数据进行滑润处理。例如每10s收集一个实例的cpu运用量会聚为服务的cpu运用量，运用1分钟的时刻窗口内服务的cpu运用量均值作为该时刻窗口对应的数据。在监控收集和数据处理过程中，运用绝对中位差算法来除掉各类反常离群数据点。

• 画像构建：对每个服务，核算出曩昔N天每个时刻片内各个时刻窗口对应的cpu运用量，对一个时刻片而言运用滑动窗口取其间最大的K个窗口数据均值作为该时刻片的cpu运用量，这样能够得到每个服务在曩昔N天每个时刻片内的cpu运用量数据；一起核算相邻两个时刻片的流量增加率，即（下个时刻片流量-当时时刻片流量)/当时时刻片流量。后续猜测弹性中会依据时刻片流量和流量增加率来猜测未来某时刻片的流量。

4.3 容量画像

方针：

描写服务的容量需求，一般用该服务的峰值cpu利用率来替代。例如一个服务在安稳时峰值cpu利用率达60%表示至少为该服务留有40%的cpu buffer来保证其安稳性。

容量画像构建：

• 容量与推迟：假定服务吞吐和流量不变的状况下，该服务的推迟往往与留有的cpu buffer呈反比，即留有的cpu buffer越少，推迟增加的越多。在百度Feed事务线中，非中心链路上的服务即使有少数的推迟上涨，也不会对体系出口推迟有直接影响，因而比较中心链路，非中心链路上的服务能够留有较少的cpu bufffer。

• 全体办法：不同服务的极限吞吐和对应的峰值cpu利用率是不同的，全体上经过机器学习办法为每个服务构建功能曲线，描写出每个服务需求留多少cpu buffer合适，全体办法如下图。

• 特征获取：经过实例监控收集+实例导流压测获取不同负载下服务的推迟数据。

• 模型构建：对服务的qps、cpu利用率、机器负载等一系列容器和机器的监控方针与服务推迟联系进行建模：f(qps, X)=latency。

• 画像核算：依据推迟模型，评价各服务在推迟可接受范围内（中心服务推迟不允许上涨，非中心服务推迟允许必定阈值的上涨）的极限吞吐和对应的cpu利用率。

05 弹性战略

为应对不同的事务弹性场景，咱们构建如下三类弹性战略来支撑事务弹性弹性：

猜测弹性：关于弹性较低的服务，依据各时刻片内的流量动摇，对未来流量进行猜测提早对服务容量进行规划调整。

负载反应弹性：关于弹性较高的服务，依据近实时服务负载改变，及时对服务容量进行弹性确保服务安稳。

守时弹性：有些服务在流量顶峰期改变较大，在非顶峰期改变较小，在顶峰期需求供给最大容量来保证安稳性，在非顶峰期不需求频频调整容量，经过守时弹性在顶峰期降临之前扩容，在顶峰期往后进行缩容，顶峰期和非顶峰期期间容量坚持不变。

5.1 猜测弹性

方针：

依据服务装备的时刻片，在当时时刻片内对未来时刻片的流量进行猜测，依据猜测流量对服务进行提早扩容、推迟缩容来应对不同的流量改变。

流量猜测：

• 关于当时时刻，结合流量画像中上个时刻片流量、当时时刻片流量和下个时刻片流量来核算，其间上个时刻片流量、当时时刻片流量、下个时刻片流量都取曩昔N天对应时刻片的最大流量，别离记为prev、cur和next。

• 针对prev、cur、next的 巨细联系，对流量趋势走向分为如下图4种case。

• case-1：prev < cur < next，全体流量处于上涨趋势中；当时应该为下个时刻片的流量上涨做好预备，进行提早扩容

• case-2：prev > cur < next，全体流量从下降趋势扭转为上涨趋势；当时应该为下个时刻片的流量上涨做好预备，进行提早扩容

• case-3：prev < cur > next，全体流量从上涨趋势扭转为下降趋势，当时时刻片处于流量顶峰状况，不做任何动作

• case-4：prev > cur > next，全体流量处于下降趋势，履行缩容动作

扩/缩容战略：

• 关于需求扩缩容的场景（如上case-1、case-2和case-4）别离核算出方针流量，其间方针流量=max(方针流量1，方针流量2)。

• 方针容量1依据上述4类case的流量来核算：

• 关于case-1和case-2，方针流量1等于next（相当于提早扩容）。

• 关于case-4，方针流量1等于cur（这儿不是依据下个时刻片的流量来缩容，不然容量或许扛不住当时时刻片，这儿仅依据当时时刻片流量来缩容，相当于推迟缩容）。

• 方针流量2=当时流量*（曩昔N天当时时刻片与下个时刻片的最大增加率），其间当时流量收集最近K个时刻窗口对应的cpu运用量。

• 依据方针流量和服务的容量画像（即该服务需求留多少cpu buffer）核算出方针容量，依据方针容量核算出该服务的方针实例数，联动PaaS对服务进行横向弹性。

5.2 负载反应弹性

方针：

依据服务近实时的负载状况，及时调整服务容量以应对流量突增改变。

扩/缩容战略：

• 数据收集：

• 通用监控：收集服务的近实时通用负载，例如cpu运用量，cpu运用率等。

• 自定义监控：支持以Prometheus metric办法自定义事务监控方针，例如服务的推迟方针、吞吐方针等。

• 收集周期可装备，一般运用滑动窗口的办法对监控方针进行聚合判别。

• 扩/缩容决策：依据服务的通用负载数据和自定义负载数据，结合服务的容量画像，核算出服务需求的方针实例数并进行横向扩缩容操作。

5.3 守时弹性

方针：

某些服务的流量在非顶峰期动摇较小没必要频频调整容量，顶峰期和非顶峰期期望固定但不同的容量。

扩/缩容战略：

• 核算流量画像中顶峰期和非顶峰期内相应时刻片的最大流量。

• 依据最大流量和容量画像核算服务在顶峰期和非顶峰期对应的方针容量。

• 依据方针容量，在顶峰期降临之前守时触发扩容动作（横向扩容），在顶峰期往后守时触发缩容动作（横向缩容），全体作用如下图。

5.4 弹性实践

• 上述三类弹性战略可依据装备分开独立运用，也能够按需组合运用：

• 关于弹性较高的function类核算，可运用负载反应弹性完成FaaS作用，关于弹性较低的后端重核算服务，可三类弹性组合运用；

• 当三类战略组合运用时，由于都对服务的实例数进行调整并一起生效，三类战略之间存在优先级，守时弹性>猜测弹性>负载反应弹性；

• 当负载反应弹性和猜测弹性或守时弹性组合运用时，负载反应弹性只能履行扩容动作不能进行缩容，缩容交由猜测弹性或守时弹性履行。因为当某服务cpu负载比较低时，或许是因为猜测弹性提早为下个时刻片的流量做预备而进行扩容导致的，此刻不能按照负载反应弹性进行缩容，对守时弹性也是同理。

• 重试机制：

• 猜测弹性和守时弹性的履行频率较低，触及一些战略核算及调用PaaS对服务实例数进行修正，全体操作不是原子性的，需求有重试机制；

• 负载反应弹性高频履行，可依据服务需求按需进行重试。

• 方针容量校验：上述每个弹性战略修正服务方针实例数都需求进行必定的校验。

• 约束方针实例数在合理区间范围：将方针实例数和每个服务容量画像中装备的实例上下限做比较，超过则滑润至上下限阈值；

• 约束单次扩缩容步长：将方针实例数和当时实例数做比照，约束每次扩缩容的份额，避免单次扩容太多导致资源缺乏，也避免缩容太多导致单实例流量飙升呈现内存oom。

06 安稳性保证

如何在大规模频频动态调整服务容量的一起保证服务安稳性至关重要，咱们从巡检和干涉止损的视点来建造相应安稳性才能，经过巡检防患于未然，经过一键干涉快速止损。

弹性巡检：周期性地触发服务实例搬迁，查验服务的弹性才能，提早暴露词典文件依靠反常等导致的弹性失利。

容量巡检：为各类服务装备告警战略，周期性地巡检服务各项资源容量，当容量缺乏时触发告警或一键预案。

状况巡检：查看各服务状况是否正常轮转，避免服务状况反常，例如顶峰期和非顶峰期对应不同的服务容量状况。

一键干涉：供给快速止损才能，守时线上演练避免才能退化，包含一键退出serverless预案、一键翻开/关闭实例软硬限预案等。

07 总结

全体作业围绕Serverless展开，经过弹性、流量、容量多维度的服务画像描写每个服务的个性化特色，依据画像构建多类弹性战略，满足服务各类弹性场景，有效地完成服务资源按需运用。当时Serverless已落地百度Feed事务线10w服务实例数规模，有效地降低了事务运转本钱。

接下来，Serverless将聚焦两个方向：热点事件的容量保证及使用机器学习提高流量画像猜测精确度，继续接入更大规模的服务为事务发明价值！

——END——

引荐阅读：

图片动画化使用中的动作分解办法

功能渠道数据提速之路

采编式AIGC视频生产流程编列实践

百度工程师漫谈视频了解

百度工程师带你了解Module Federation

巧用Golang泛型，简化代码编写