一、容量管理的設計理念

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

1）容量風險未知

集群/資源池/Node容量水位缺乏可視化，穩定性難以保證

隨著云原生和K8S普及，若沒有很好的容量管理，我們就無法感知整個集群、整個資源池以及Node容量的水位變化，也無法得知是否有必要采購資源，無法察覺整體的資源風險。

• 容量變更根因難以追溯

有時我們在做一些發版或迭代時，會發現原本充足的資源突然出現緊缺。此時，若要查探容量何時變化或追溯變化的根因，存在一定難度，也比較復雜。

• HPA覆蓋率低，業務穩定性難以保障

B站有很多活動和突發流量，但由于HPA的覆蓋率比較低，業務容量彈性往往難以保障。

2）降本增效大背景

• 資源使用率低，迫切需要提高整體使用率

• 資源碎片化較為嚴重，資源無法得到充分利用

• 平臺缺乏統一的資源協調能力

由于將物理資源分散到各個部門，如直播業務有獨立的直播物理資源池，電商有專屬物理資源，碎片化程度極高，所以平臺統一協調資源的能力難免存在欠缺。

• 資源占用大頭難以快速發現，治理困難

降本增效遵循二八原則，即20%的業務可能占了80%的資源。我們需要快速如何找出20%的業務，并推動其進行治理，這部分業務得到治理后往往收益較大。

2、不同部門的關注點

• 研發/部門：要有資源去做資源的擴容發布、藍綠發布和回滾。希望部門的成本不能過高，避免資源浪費。

• SRE：服務的穩定性。在保證穩定性的情況下，聚焦服務資源的使用率，以達到降本增效的目的。

• 平臺：需要統籌資源buffer，控制資源的超賣率，保證底層容量的穩定，從而實現降本增效的目標。

• 成本部門：資源使用率，賬單、預算和成本。

3、容量管理面臨的挑戰

• 內部因素復雜，變動頻繁

包括代碼變更、配置變更、壓測活動、多活切量、定時任務和緩存過期等，都可能導致容量模型發生改變。

• 外部場景多樣，難以預知

B站活動比較多，運營也會進行不定時的推廣，一些熱門事件或話題都有可能導致容量的突增。

• 鏈路瓶頸點多，難以提前發現

無論是東西向流量還是南北向流量，整個鏈路比較長，因此上游服務、下游服務和中間件都可能遇到瓶頸。

• 應急依賴人工，恢復時間長

以上問題發生時，如果依靠人工應急，上游擴容可能會將下游直接打垮，容易引發二次故障。

4、容量管理的整體思路

整個容量體系的設計，從下到上分為幾大部分，包括基礎容量、彈性資源、合池和配額管理。

首先是基礎容量，它包含平臺關注的集群容量、資源池容量、Node容量，以及應用畫像的相關數據。雖然我們將服務本身發版涉及到應用資源的容量視作基礎容量，同時業務也會關注。

在這些基礎容量之上，我們構建了一些彈性資源，包括VPA和HPA，還有我們的合池和配額管理。同時我們構建了整個容量可視化的一些頁面，用于幫助我們的業務和平臺更好地將自己的資源數據可視化，做一些資源的管理。

二、容量管理之降本增效

1、降本增效通用手段

2、具體方案介紹

1）彈性伸縮-VPA(Vertical Pod Autoscaler)

針對每一個服務，我們都有服務的軟限和硬限，這是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的指標管理：基于不同的指標例如CPU的使用量max、P99等做一些調整。
• VPA的模板管理：基于我們的一些應用畫像，例如根據L0服務或L2服務等不同的服務畫像做一些不同的模板和管理。
• VPA的策略預估與對照：分清哪種指標或哪部分對我們更優，因此我們會對不同的策略進行策略預估和對照，以便擇優。

②數據運營

包括VPA的覆蓋大盤、VPA執行記錄和VPA策略分析。

• VPA覆蓋大盤：分析整個資源池的覆蓋率和執行記錄，記錄服務軟限的調整幅度。
• VPA策略分析：調整后，通過可視化界面觀察是否還存在問題。

③黑名單

整個服務的使用量一般會在活動時劇增，或某個服務上線了新功能，進行壓測，都會導致整個容量數據變化。所以我們制作了黑名單機制，進行VPA策略避讓，保證在非預期的情況下，不會對這些服務進行相關調整。

④預警

即使執行了VPA，通常也有可能出現不符合預期的情況，所以我們制作了失敗率、覆蓋率和冗余度的策略預警。如果本次調整有多處不符合預期，提前預警將遞送給SRE和平臺方，然后進行治理和排障。

2）PaaS合池

我們的漫畫業務、直播業務和OGV業務都是獨立的物理資源池，如下圖所示，番劇的CPU分配率很高，而漫畫跟直播的分配率相比較低。如果番劇需要資源去完成一些事情，漫畫和直播往往不能滿足，所以需要采購獨立的預算，或額外申請云上資源。

所以我們認為業務不應關注底層資源，從而完成了PaaS的合池。合池后，業務更關注邏輯的配額管理，即整個配額的使用率。如果使用率過高或出現問題，業務可以解決，底層資源則由平臺統一管控，進而平臺的統一管控能力提升。

合池具體如何落地？可分為以下幾步：

• 標準化治理

基于歷史原因，不同的資源池使用不同策略，甚至配置、內核版本也各不相同，所以涉及到標準化的操作。首先，去除特殊約束，有些服務可能綁定了特殊的物理機發布。其次，不能配置nolimit相關的服務，因為合池完畢后如果某個服務壓力比較大，且配得不合理，往往會增加物理機的壓力，影響其他業務。同時，我們還進行了去cpuset化、統一操作系統內核和日志規范化的操作。

• 平臺支撐

由于合池完畢后資源也不能無限使用，所以要基于合池后的不同組織進行邏輯配額管理，再整個大資源池覆蓋VPA。

• 老板的支持

合池涉及到不同的部門，這一方面最重要的是需要老板的支持。自上而下進行的合池較依賴協同合作。

3）配額管理

容量平臺提供了配額管理相關的策略下發能力，同時對接內部的CMDB業務樹。基于組織業務的關系，可以設置不同的組織需要的資源數量。若使用超額，會聯動發布平臺，進而控制整體資源。如果資源不夠，可能就無法發布或擴容。

降本增效的收益

• 成本：通過這些手段，我們實現了22年H1在線業務PaaS物理機的0新增，同時整個S12的活動保障實現了0采購。

• 平臺：統一管控能力極大提升同時，快速支撐大型活動方面，活動數量攀升了不止10倍。以往進行大型活動支撐時，直播資源不足往往需要采購預算，周期漫長。目前我們可以通過協調資源和統籌調度盡快交付資源，時間也從原來的一個半月縮短到現在的一個小時或兩個小時。PaaS的整體使用率獲得較大提升。

• 業務：首先，對于小業務而言，由于本身資源池的資源較少，物理機不多，所以宕機對它的影響較大。合池后資源池的規模較大，服務相對分散，所以無論掛一臺機器還是兩臺機器，對小業務的影響會大大降低。第二，業務整體的容量需求得到快速滿足。資源緊張時，它也可以進行臨時的藍綠發布或者HPA超賣。

三、容量管理之穩定性

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發生變化。

1）HPA可視化

①HPA管控

包括HPA 的批量開啟和禁用。保障大型活動時，往往會希望容量是穩態的，再基于穩態的容量進行壓測，此時需要先關閉HPA，在低峰谷區進行壓測。在資源不變的情況下，壓測穩態能夠支撐的量的數值。后續可能分為幾輪壓測，最后一輪壓測會開啟全部HPA，觀察我們最終能支持的量，基于這些量預估容估。除此之外，還可能涉及HPA的增刪改查能力。

②可視化

主要是HPA覆蓋率，要確定整個HPA在不同區域和不同等級覆蓋的應用數及覆蓋率，對比指標數據和彈性實例。

彈性實例對比表明當前服務的實例數量，并展示一個關鍵數據。這個數據幫助我們基于HPA配置策略，確定彈性實例的最終數量。彈性實例受限于HPA的最大值控制。如果純粹通過配置策略計算擴容的實例數，那么能夠通過HPA擴至15個。但如果無最大限制，可能會直接擴至20個。因此，借助可視化能直接看出HPA的設置是否合理，了解整個HPA變化的實際趨勢。

2）HPA并非可以無限擴容

HPA受限于連接池或下游服務有限的承載能力，因此我們排查了整個過程需要使用消息隊列、Tidb、泰山KV、緩存以及中間件等相關組件。整體排查后，發現MySQL風險較大 ，因為大多數組件基本是集中式的代理，例如Tidb和泰山KV都是集中式的proxy部署，無連接池相關風險。緩存使用的redis和mc往往具有較大支持連接數，所以風險相對可控。MySQL 則不同，因此我們在彈性預檢這方面增加對MySQL和連接池的預檢。如果整個擴容導致MySql水位變高，就會進行相關提示。服務進行HPA擴容時，可能會導致下游的服務壓力、下游雪崩，導致一些底層的中間件出現一定的問題或壓力。

解決這個問題的整體思路：

一是HPA預檢，二是基于全鏈路的彈性，三是對超出預期的流量做一些組件的限流。

3）容量巡檢

容量巡檢的作用在于，如果某些服務有風險，能夠實現相關數據可視化。

針對不同的場景和不同的角色，關注點也不同。

業務更關注整個業務維度，例如使用率如何、有無風險應用等應用維度，能盡快找到這些列表，進而快速完成治理。配額管理方面，則包括整個配額的使用率和配額可調度的實例數量，幫助快速判斷配額風險。

平臺方則更關注資源池的分配率，如可調度的實例數峰值、資源使用率、資源池是否為單節點，還會關注整個VPA的調整失敗率和冗余度。基于平臺方的關注事項，我們制作了風險的巡檢大盤，用以確定哪些資源有風險、哪些資源比較空閑、哪些資源急需治理等情況。

4）超載保護

即使有了這些保障，也無法保證萬無一失。因為流量突發很常見，如佩洛西事件等熱點事件導致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賽、跨年晚會、拜年祭等相關活動的基礎架構保障工作，目前主要負責推廣搜業務的穩定性建設。