大型活动容量支撑速增10+倍，B站容量管理下的资源活化

发布时间：2025-11-04 23:35:19 来源：创站工坊 作者：IT科技类资讯

一、大型的资容量管理的活动化设计理念

1、为什么要做容量管理？容量

集群/资源池/Node容量水位缺乏可视化，稳定性难以保证

随着云原生和K8S普及，支撑站容若没有很好的速增容量管理，我们就无法感知整个集群、量管理下整个资源池以及Node容量的源活水位变化，也无法得知是大型的资否有必要采购资源，无法察觉整体的活动化资源风险。

有时我们在做一些发版或迭代时，容量会发现原本充足的支撑站容资源突然出现紧缺。此时，速增若要查探容量何时变化或追溯变化的量管理下根因，存在一定难度，源活也比较复杂。大型的资

B站有很多活动和突发流量，但由于HPA的覆盖率比较低，业务容量弹性往往难以保障。

由于将物理资源分散到各个部门，网站模板如直播业务有独立的直播物理资源池，电商有专属物理资源，碎片化程度极高，所以平台统一协调资源的能力难免存在欠缺。

降本增效遵循二八原则，即20%的业务可能占了80%的资源。我们需要快速如何找出20%的业务，并推动其进行治理，这部分业务得到治理后往往收益较大。

2、不同部门的关注点

3、容量管理面临的挑战

包括代码变更、配置变更、压测活动、多活切量、定时任务和缓存过期等，都可能导致容量模型发生改变。

B站活动比较多，运营也会进行不定时的推广，一些热门事件或话题都有可能导致容量的突增。

无论是东西向流量还是南北向流量，整个链路比较长，因此上游服务、下游服务和中间件都可能遇到瓶颈。

以上问题发生时，云南idc服务商如果依靠人工应急，上游扩容可能会将下游直接打垮，容易引发二次故障。

4、容量管理的整体思路

整个容量体系的设计，从下到上分为几大部分，包括基础容量、弹性资源、合池和配额管理。

首先是基础容量，它包含平台关注的集群容量、资源池容量、Node容量，以及应用画像的相关数据。虽然我们将服务本身发版涉及到应用资源的容量视作基础容量，同时业务也会关注。

在这些基础容量之上，我们构建了一些弹性资源，包括VPA和HPA，还有我们的合池和配额管理。同时我们构建了整个容量可视化的一些页面，用于帮助我们的业务和平台更好地将自己的资源数据可视化，做一些资源的管理。

二、容量管理之降本增效

1、降本增效通用手段

2、具体方案介绍

针对每一个服务，我们都有服务的软限和硬限，这是K8S的基本概念。应用CPU Used即应用的CPU的真实使用量。B站所有的硬限和软限都是通过我们的发布平台caster去指定，它们可能是业务基于经验设置的，设置的值不一定合理。随着业务和服务越来越多，这种不合理性就会越发明显，导致分配率非常高，但整体的使用率却不高。

如何解决这个问题？

我们认为，研发部门无需关注软限多少，只需关注需要多少资源。基于应用的真实CPU使用量和应用画像，评估它的服务等级、是否多活等指标，以此判断应动态分配多少软限。这种方法能提高整个服务的部署密度，提高整体资源池的使用率。

进行大型活动时，如果分配率已经很高，可以应用VPA的策略，把非核心服务（如 L2/L3的后台服务）用来降级，调低软限，给核心服务腾让资源。

我们通过VPA管理平台下发VPA策略，使其经过VPA-API组件。这个组件是一个中间代理，主要实现对K8S集群中VPA Generator对象的增删改查操作，负责汇总收集VPA相关的可观测数据。

VPA Generator主要负责拆解先前下发的具有相同画像的规则，如果下发一个L0等级的多活规则，它会拆解并创建很多对应VPA对象，最后通过VPA Recommender从监控系统中采集一些对应的应用资源指标，计算推荐值即合适的request值，并通过VPA Updater组件调整Pod的资源。

发布服务时也可能涉及到资源改变，VPA Webhook会监听类似事件，再动态调整Pod值。

包括VPA指标管理、模板管理和预估/对照组。

包括VPA的覆盖大盘、VPA执行记录和VPA策略分析。

整个服务的使用量一般会在活动时剧增，或某个服务上线了新功能，进行压测，都会导致整个容量数据变化。所以我们制作了黑名单机制，进行VPA策略避让，保证在非预期的情况下，不会对这些服务进行相关调整。

即使执行了VPA，通常也有可能出现不符合预期的情况，所以我们制作了失败率、覆盖率和冗余度的策略预警。如果本次调整有多处不符合预期，提前预警将递送给SRE和平台方，然后进行治理和排障。

我们的漫画业务、直播业务和OGV业务都是独立的物理资源池，如下图所示，番剧的CPU分配率很高，而漫画跟直播的分配率相比较低。如果番剧需要资源去完成一些事情，漫画和直播往往不能满足，所以需要采购独立的预算，或额外申请云上资源。

所以我们认为业务不应关注底层资源，从而完成了PaaS的合池。合池后，业务更关注逻辑的配额管理，即整个配额的使用率。如果使用率过高或出现问题，业务可以解决，底层资源则由平台统一管控，进而平台的统一管控能力提升。

合池具体如何落地？可分为以下几步：

基于历史原因，不同的资源池使用不同策略，甚至配置、内核版本也各不相同，所以涉及到标准化的操作。首先，去除特殊约束，有些服务可能绑定了特殊的物理机发布。其次，不能配置nolimit相关的服务，因为合池完毕后如果某个服务压力比较大，且配得不合理，往往会增加物理机的压力，影响其他业务。同时，我们还进行了去cpuset化、统一操作系统内核和日志规范化的操作。

由于合池完毕后资源也不能无限使用，所以要基于合池后的不同组织进行逻辑配额管理，再整个大资源池覆盖VPA。

合池涉及到不同的部门，这一方面最重要的是需要老板的支持。自上而下进行的合池较依赖协同合作。

容量平台提供了配额管理相关的策略下发能力，同时对接内部的CMDB业务树。基于组织业务的关系，可以设置不同的组织需要的资源数量。若使用超额，会联动发布平台，进而控制整体资源。如果资源不够，可能就无法发布或扩容。

降本增效的收益

三、容量管理之稳定性

1、在线业务的典型特征

2、弹性伸缩-HPA(Horizontal Pod Autoscaler)

HPA的设计理念与VPA相似，包括策略管理、弹性预检、可观测和预警。

因为HPA基于CPU使用率、内存使用率或QPS之类等指标进行管理，有些基于不同的应用画像进行管理。例如，针对L0和L1的服务，它们的CPU使用率若达到30%就应该扩容，至于非多活的服务，达到扩容标准的最小值则可能稍高。

配备HPA后也并非万无一失，因为HPA做弹性会涉及到下游及一些基础的技术组件，比如数据库会涉及到一些连接池，需要考虑它是否会满，是否会导致其他风险等。所以我们进行一些弹性预检的相关措施，包括临近值预检和容量风控等能力。

我们会观测异常记录和覆盖率，比如对L0服务的覆盖率如何，是否所有L0的服务都覆盖了HPA，HPA被触发时HPA的弹性质量如何等问题进行观测。

我们设计了扩缩容的失败预警和HPA失效的预警，如果触发一些HPA扩容或缩容的事件，研发部门会收到相关时间通知，告知因服务压力或流量导致HPA发生变化。

包括HPA 的批量开启和禁用。保障大型活动时，往往会希望容量是稳态的，再基于稳态的容量进行压测，此时需要先关闭HPA，在低峰谷区进行压测。在资源不变的情况下，压测稳态能够支撑的量的数值。后续可能分为几轮压测，最后一轮压测会开启全部HPA，观察我们最终能支持的量，基于这些量预估容估。除此之外，还可能涉及HPA的增删改查能力。

主要是HPA覆盖率，要确定整个HPA在不同区域和不同等级覆盖的应用数及覆盖率，对比指标数据和弹性实例。

弹性实例对比表明当前服务的实例数量，并展示一个关键数据。这个数据帮助我们基于HPA配置策略，确定弹性实例的最终数量。弹性实例受限于HPA的最大值控制。如果纯粹通过配置策略计算扩容的实例数，那么能够通过HPA扩至15个。但如果无最大限制，可能会直接扩至20个。因此，借助可视化能直接看出HPA的设置是否合理，了解整个HPA变化的实际趋势。

HPA受限于连接池或下游服务有限的承载能力，因此我们排查了整个过程需要使用消息队列、Tidb、泰山KV、缓存以及中间件等相关组件。整体排查后，发现MySQL风险较大 ，因为大多数组件基本是集中式的代理，例如Tidb和泰山KV都是集中式的proxy部署，无连接池相关风险。缓存使用的redis和mc往往具有较大支持连接数，所以风险相对可控。MySQL 则不同，因此我们在弹性预检这方面增加对MySQL和连接池的预检。如果整个扩容导致MySql水位变高，就会进行相关提示。服务进行HPA扩容时，可能会导致下游的服务压力、下游雪崩，导致一些底层的中间件出现一定的问题或压力。

解决这个问题的整体思路：

一是HPA预检，二是基于全链路的弹性，三是对超出预期的流量做一些组件的限流。

容量巡检的作用在于，如果某些服务有风险，能够实现相关数据可视化。

针对不同的场景和不同的角色，关注点也不同。

业务更关注整个业务维度，例如使用率如何、有无风险应用等应用维度，能尽快找到这些列表，进而快速完成治理。配额管理方面，则包括整个配额的使用率和配额可调度的实例数量，帮助快速判断配额风险。

平台方则更关注资源池的分配率，如可调度的实例数峰值、资源使用率、资源池是否为单节点，还会关注整个VPA的调整失败率和冗余度。基于平台方的关注事项，我们制作了风险的巡检大盘，用以确定哪些资源有风险、哪些资源比较空闲、哪些资源急需治理等情况。

即使有了这些保障，也无法保证万无一失。因为流量突发很常见，如佩洛西事件等热点事件导致B站的直播流量激增、超出预期，所以这方面需要依靠弹性资源。另一比较重要的手段则是依靠技术组件限流熔断和降解。

目前限流主要包括分布式的全局限流和基于http、grpc、qps的限流，同时因为每个业务方基本上都会健全账号，所以我们会对一些比较核心的业务做基于caller即调用方的限流，从而避免因某一个业务的流量突发而导致整个账号体系出现问题。

另一方面，我们基于BBR进行动态限流，基于cpu使用率、成功qps和响应rt等限流，同时联动移动端并进行流控。如果服务端超出承受极限，我们会给移动端下发策略，驱使移动端做流控的控制，避免用户重试导致雪崩。

包括通过滑动窗口计算成功失败率以及熔断后需要进行的操作。

基于多活进行跨可能区的降级，业务对这个操作无感，这也是我们做多活的一个好处。而对于Node SSR相关的降级，支持降级至静态页，业务也无感，但耗时相对长些。至于数据类的降级，假若AI方面的算法服务出了问题，我们可以进行兜底数据展示，但用户方的内容质量就有所下降。弱依赖降级时，部分服务会直接降级，不展示非核心数据。

四、容量管理之可视化运营

1、基础容量

我们更关注集群、资源池、Node和应用维度的数据，所以制作一些可视化图表，以便更快查看整个集群资源池和应用在这段时间内的变化趋势。

以资源池和Node为例，由于要控制超卖，所以要控制资源池和Node的容量水位和超卖率（Node也有部分热点）。

有些会触发二次调度，把上面的部分服务调用到非热点的服务中。应用则包括应用的资源使用量、使用率、实例数和单实例容器数，它的容器包括多少容器数，例如有一个Pod，它可能包含一个主容器和相关伴生容器，伴生有可能导致容量变化。我们基于这些数据制作趋势图，并在监控上保存应用的相关容量数据。与监控相比，因为数据点更加分散，所以保存期限更长，目前已保存了超过两年的容量数据。

2、业务组织容量

业务痛点

解决方案

根据以上痛点，我们设计了组织业务容量，基于内部的CMDB即组织业务数，通过聚合应用指标，从下往上逐渐递归，算出整个组织和业务的容量，呈现历史容量的变化趋势。例如，总容量是1万盒，1万盒属于整个直播业务，而直播的分支包含直播的房间、直播营收相关业务。

列出每一项所占的资源，就能清晰地感知哪些业务是资源占比的大头和占比总量。通过图片上的红线和红点，就能分析它的使用量与使用合理性。下图右方则呈现了整个容量的变化趋势，这样就能快速定位不合理的板块。同时，我们支持数据的一键下钻，作用同上。

3、容量事件

资源治理时，往往会遇到资源变少变空或不能发版的问题。以往查询这些问题根源，我们可能要翻遍各个平台。例如，查看是否有人在发布平台进行扩容或缩容操作，部分服务是否因压力过大触发HPA，或是否有人在管理平台中临时添加了机器导致容量变大。

由于平台数量多，业务SRE排查相当困难，所以我们做了容量事件相关的平台，以消费包括发布平台、HPA以及Node管理等整个变更平台的变更事件。通过变更事件，把数据消费到容量事件平台上，统筹观察这段时间业务的容量变更，因此容量事件是我们快速定位容量变化根因的重要途径。这样做的收益很显著，以往容量发生变化，业务必须联系SRE和平台。而现在无需这样操作，就能快速感知容量变化的根因，处理效率提升。

4、容量周报

容量周报分为部门周报和内部周报，业务部门更关注整体资源的用量以及资源使用率的变化。观察这些数据能更好地感知容量效果。除了降本增效以外，业务还关注稳定性，希望得知具体的风险应用有哪些，以及一周内哪些应用有怎样的容量变化。

对于内部来说，SRE和平台比较关注哪些部门的自营资源占量较大而使用率较低，这些部门对我们来说往往是能用于降本的组织，我们需要提前与他们沟通，所以就需要内部周报帮助完成。同时我们也列出了部门资源使用率的排名，排名越靠前说明治理得越好，反之亦然。

张鹤

哔哩哔哩 

基础架构部 资深SRE

2020年加入B站，先后负责社区/直播/OGV/推广搜相关的SRE工作，深度参与多活，活动保障，混沌工程，容量治理相关的建设，主导容量管理平台，混沌平台的架构设计和落地，负责B站S赛、跨年晚会、拜年祭等相关活动的基础架构保障工作，目前主要负责推广搜业务的稳定性建设。

相关文章