B站高可用用架構(gòu)實踐

流量洪峰下做好高服務(wù)質(zhì)量的架構(gòu)是件具備挑戰(zhàn)的事情，本文詳細(xì)闡述了從Google SRE的系統(tǒng)方法論以及實際業(yè)務(wù)的應(yīng)對過程中出發(fā)，一些體系化的可用性設(shè)計。對我們了解系統(tǒng)的全貌、上下游的聯(lián)防有更進(jìn)一步的幫助。
一、負(fù)載均衡
負(fù)載均衡具體分成兩個方向，一個是前端負(fù)載均衡，另一個是數(shù)據(jù)中心內(nèi)部的負(fù)載均衡。

前端負(fù)載均衡方面，一般而言用戶流量訪問層面主要依據(jù)DNS，希望做到最小化用戶請求延遲。將用戶流量最優(yōu)地分布在多個網(wǎng)絡(luò)鏈路上、多個數(shù)據(jù)中心、多臺服務(wù)器上，通過動態(tài)CDN的方案達(dá)到最小延遲。

用戶流量會先流入BFE的前端接入層，第一層的BFE實際上起到一個路由的作用，盡可能選擇跟接入節(jié)點比較近的一個機(jī)房，用來加速用戶請求。然后通過API網(wǎng)關(guān)轉(zhuǎn)發(fā)到下游的服務(wù)層，可能是內(nèi)部的一些微服務(wù)或者業(yè)務(wù)的聚合層等，最終構(gòu)成一個完整的流量模式。
基于此，前端服務(wù)器的負(fù)載均衡主要考慮幾個邏輯：

第一，盡量選擇最近節(jié)點；
第二，基于帶寬策略調(diào)度選擇API進(jìn)入機(jī)房；
第三，基于可用服務(wù)容量平衡流量。

數(shù)據(jù)中心內(nèi)部的負(fù)載均衡方面，理想情況下最忙和最不忙的節(jié)點所消耗的CPU相差幅度較小。但如果負(fù)載均衡沒做好，情況可能相差甚遠(yuǎn)。由此可能導(dǎo)致資源調(diào)度、編排的困難，無法合理分配容器資源。

因此，數(shù)據(jù)中心內(nèi)部負(fù)載均衡主要考慮：

均衡流量分發(fā)；
可靠識別異常節(jié)點；
scale-out，增加同質(zhì)節(jié)點以擴(kuò)容；
減少錯誤，提高可用性。

我們此前通過同質(zhì)節(jié)點來擴(kuò)容就發(fā)現(xiàn)，內(nèi)網(wǎng)服務(wù)出現(xiàn)CPU占用率過高的異常，通過排查發(fā)現(xiàn)背后RPC點到點通信間的 health check 成本過高，產(chǎn)生了一些問題。另外一方面，底層的服務(wù)如果只有單套集群，當(dāng)出現(xiàn)抖動的時候故障面會比較大，因此需要引入多集群來解決問題。

通過實現(xiàn) client 到 backend 的子集連接，我們做到了將后端平均分配給客戶端，同時可以處理節(jié)點變更，持續(xù)不斷均衡連接，避免大幅變動。多集群下，則需要考慮集群遷移的運維成本，同時集群之間業(yè)務(wù)的數(shù)據(jù)存在較小的交集。

回到CPU忙時、閑時占用率過大的問題，我們會發(fā)現(xiàn)這背后跟負(fù)載均衡算法有關(guān)。

第一個問題，對于每一個qps，實際上就是每一個query、查詢、API請求，它們的成本是不同的。節(jié)點與節(jié)點之間差異非常大，即便你做了均衡的流量分發(fā)，但是從負(fù)載的角度來看，實際上還是不均勻的。

第二個問題，存在物理機(jī)環(huán)境上的差異。因為我們通常都是分年采購服務(wù)器，新買的服務(wù)器通常主頻CPU會更強一些，所以服務(wù)器本質(zhì)上很難做到強同質(zhì)。

基于此，參考JSQ（最閑輪訓(xùn)）負(fù)載均衡算法帶來的問題，發(fā)現(xiàn)缺乏的是服務(wù)端全局視圖，因此我們的目標(biāo)需要綜合考慮負(fù)載和可用性。我們參考了《The power of two choices in randomized load balancing》的思路，使用the choice-of-2算法，隨機(jī)選取的兩個節(jié)點進(jìn)行打分，選擇更優(yōu)的節(jié)點：

選擇backend：CPU，client：health、inflight、latency作為指標(biāo)，使用一個簡單的線性方程進(jìn)行打分；
對新啟動的節(jié)點使用常量懲罰值（penalty），以及使用探針方式最小化放量，進(jìn)行預(yù)熱；
打分比較低的節(jié)點，避免進(jìn)入“永久黑名單”而無法恢復(fù)，使用統(tǒng)計衰減的方式，讓節(jié)點指標(biāo)逐漸恢復(fù)到初始狀態(tài)（即默認(rèn)值）。
通過優(yōu)化負(fù)載均衡算法以后，我們做到了比較好的收益。

二、限流
避免過載，是負(fù)載均衡的一個重要目標(biāo)。隨著壓力增加，無論負(fù)載均衡策略如何高效，系統(tǒng)某個部分總會過載。我們優(yōu)先考慮優(yōu)雅降級，返回低質(zhì)量的結(jié)果，提供有損服務(wù)。在最差的情況，妥善的限流來保證服務(wù)本身穩(wěn)定。

限流這塊，我們認(rèn)為主要關(guān)注以下幾點：

一是針對qps的限制，帶來請求成本不同、靜態(tài)閾值難以配置的問題；
二是根據(jù)API的重要性，按照優(yōu)先級丟棄；
三是給每個用戶設(shè)置限制，全局過載發(fā)生時候，針對某些“異常”進(jìn)行控制非常關(guān)鍵；
四是拒絕請求也需要成本；
五是每個服務(wù)都配置限流帶來的運維成本。

在限流策略上，我們首先采用的是分布式限流。我們通過實現(xiàn)一個quota-server，用于給backend針對每個client進(jìn)行控制，即backend需要請求quota-server獲取quota。

這樣做的好處是減少請求Server的頻次，獲取完以后直接本地消費。算法層面使用最大最小公平算法，解決某個大消耗者導(dǎo)致的饑餓。

在客戶端側(cè)，當(dāng)出現(xiàn)某個用戶超過資源配額時，后端任務(wù)會快速拒絕請求，返回“配額不足”的錯誤，有可能后端忙著不停發(fā)送拒絕請求，導(dǎo)致過載和依賴的資源出現(xiàn)大量錯誤，處于對下游的保護(hù)兩種狀況，我們選擇在client側(cè)直接進(jìn)行流量，而不發(fā)送到網(wǎng)絡(luò)層。

我們在Google SRE里學(xué)到了一個有意思的公式，max(0, (requests- K*accepts) / (requests + 1))。通過這種公式，我們可以讓client直接發(fā)送請求，一旦超過限制，按照概率進(jìn)行截流。

在過載保護(hù)方面，核心思路就是在服務(wù)過載時，丟棄一定的流量，保證系統(tǒng)臨近過載時的峰值流量，以求自保護(hù)。常見的做法有基于CPU、內(nèi)存使用量來進(jìn)行流量丟棄；使用隊列進(jìn)行管理；可控延遲算法：CoDel 等。

簡單來說，當(dāng)我們的CPU達(dá)到80%的時候，這個時候可以認(rèn)為它接近過載，如果這個時候的吞吐達(dá)到100，瞬時值的請求是110，我就可以丟掉這10個流量，這種情況下服務(wù)就可以進(jìn)行自保護(hù)，我們基于這樣的思路最終實現(xiàn)了一個過載保護(hù)的算法。

我們使用CPU的滑動均值（CPU > 800 ）作為啟發(fā)閾值，一旦觸發(fā)就進(jìn)入到過載保護(hù)階段。算法為：(MaxPass * AvgRT) < InFlight。其中MaxPass、AvgRT都為觸發(fā)前的滑動時間窗口的統(tǒng)計值。

限流效果生效后，CPU會在臨界值（800）附近抖動，如果不使用冷卻時間，那么一個短時間的CPU下降就可能導(dǎo)致大量請求被放行，嚴(yán)重時會打滿CPU。在冷卻時間后，重新判斷閾值（CPU > 800 ），是否持續(xù)進(jìn)入過載保護(hù)。

三、重試

流量的走向，一般會從BFE到SLB然后經(jīng)過API網(wǎng)關(guān)再到BFF、微服務(wù)最后到數(shù)據(jù)庫，這個過程要經(jīng)過非常多層。在我們的日常工作中，當(dāng)請求返回錯誤，對于backend部分節(jié)點過載的情況下，我們應(yīng)該怎么做？

首先我們需要限制重試的次數(shù)，以及基于重試分布的策略；
其次，我們只應(yīng)該在失敗層進(jìn)行重試，當(dāng)重試仍然失敗時，我們需要全局約定錯誤碼，避免級聯(lián)重試；
此外，我們需要使用隨機(jī)化、指數(shù)型遞增的充實周期，這里可以參考Exponential Backoff和Jitter；
最后，我們需要設(shè)定重試速率指標(biāo)，用于診斷故障。

而在客戶端側(cè)，則需要做限速。因為用戶總是會頻繁嘗試去訪問一個不可達(dá)的服務(wù)，因此客戶端需要限制請求頻次，可以通過接口級別的error_details，掛載到每個API返回的響應(yīng)里。

四、超時

我們之前講過，大部分的故障都是因為超時控制不合理導(dǎo)致的。首當(dāng)其沖的是高并發(fā)下的高延遲服務(wù)，導(dǎo)致client堆積，引發(fā)線程阻塞，此時上游流量不斷涌入，最終引發(fā)故障。所以，從本質(zhì)上理解超時它實際就是一種Fail Fast的策略，就是讓我們的請求盡可能消耗，類似這種堆積的請求基本上就是丟棄掉或者消耗掉。

另一個方面，當(dāng)上游超時已經(jīng)返回給用戶后，下游可能還在執(zhí)行，這就會引發(fā)資源浪費的問題。

再一個問題，當(dāng)我們對下游服務(wù)進(jìn)行調(diào)優(yōu)時，到底如何配置超時，默認(rèn)值策略應(yīng)該如何設(shè)定？生產(chǎn)環(huán)境下經(jīng)常會遇到手抖或者錯誤配置導(dǎo)致配置失敗、出現(xiàn)故障的問題。所以我們最好是在框架層面做一些防御性的編程，讓它盡可能讓取在一個合理的區(qū)間內(nèi)。

進(jìn)程內(nèi)的超時控制，關(guān)鍵要看一個請求在每個階段（網(wǎng)絡(luò)請求）開始前，檢查是否還有足夠的剩余來處理請求。另外，在進(jìn)程內(nèi)可能會有一些邏輯計算，我們通常認(rèn)為這種時間比較少，所以一般不做控制。

現(xiàn)在很多RPC框架都在做跨進(jìn)程超時控制，為什么要做這個？跨進(jìn)程超時控制同樣可以參考進(jìn)程內(nèi)的超時控制思路，通過RPC的源數(shù)據(jù)傳遞，把它帶到下游服務(wù)，然后利用配額繼續(xù)傳遞，最終使得上下游鏈路不超過一秒。

審核編輯 黃宇