作者 | 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泛型，简化代码编写