RM新时代网站-首页

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

B站高可用用架構實踐

佳佳 ? 來源:jf_36786605 ? 作者:jf_36786605 ? 2024-06-06 10:37 ? 次閱讀

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

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

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

第一,盡量選擇最近節(jié)點;
第二,基于帶寬策略調度選擇API進入機房;
第三,基于可用服務容量平衡流量。

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

因此,數據中心內部負載均衡主要考慮:

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

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

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


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

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

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


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

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

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


限流這塊,我們認為主要關注以下幾點:

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

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

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


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

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


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

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


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

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

三、重試

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

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

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

四、超時

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

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

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

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


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

審核編輯 黃宇

聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • RPC
    RPC
    +關注

    關注

    0

    文章

    111

    瀏覽量

    11529
  • 架構
    +關注

    關注

    1

    文章

    513

    瀏覽量

    25468
收藏 人收藏

    評論

    相關推薦

    確保網站無縫運行:Keepalived可用與Nginx集成實戰(zhàn)

    目錄 keepalived可用(nginx) keepalived簡介 keepalived的重要功能 keepalived可用架構
    的頭像 發(fā)表于 11-27 09:08 ?245次閱讀
    確保網站無縫運行:Keepalived<b class='flag-5'>高</b><b class='flag-5'>可用</b>與Nginx集成實戰(zhàn)

    邊緣計算架構設計最佳實踐

    邊緣計算架構設計最佳實踐涉及多個方面,以下是一些關鍵要素和最佳實踐建議: 一、核心組件與架構設計 邊緣設備與網關 邊緣設備 :包括各種嵌入式設備、傳感器、智能手機、智能攝像頭等,負責采
    的頭像 發(fā)表于 10-24 14:17 ?411次閱讀

    AUTOSAR架構下,持續(xù)集成CI的最佳實踐

    集成(CI)流程。今天,我們就來探討一下基于AUTOSAR架構的CI流程實踐,并通過對流程的詳細講解,展示其在實際開發(fā)中的重要性和優(yōu)勢。什么是AUTOSAR架構?首
    的頭像 發(fā)表于 10-24 08:06 ?461次閱讀
    AUTOSAR<b class='flag-5'>架構</b>下,持續(xù)集成CI的最佳<b class='flag-5'>實踐</b>

    架構與設計 常見微服務分層架構的區(qū)別和落地實踐

    前言 從強調內外隔離的六邊形架構,逐漸發(fā)展衍生出的層層遞進、注重領域模型的洋蔥架構,再到和DDD完美契合的整潔架構。架構風格的不斷演進,其實就是為了適應軟件需求越來越復雜的特點。 可以
    的頭像 發(fā)表于 10-22 15:34 ?213次閱讀
    <b class='flag-5'>架構</b>與設計 常見微服務分層<b class='flag-5'>架構</b>的區(qū)別和落地<b class='flag-5'>實踐</b>

    使用bq769x0對可用性系統(tǒng)進行故障監(jiān)控

    電子發(fā)燒友網站提供《使用bq769x0對可用性系統(tǒng)進行故障監(jiān)控.pdf》資料免費下載
    發(fā)表于 10-15 10:13 ?0次下載
    使用bq769x0對<b class='flag-5'>高</b><b class='flag-5'>可用</b>性系統(tǒng)進行故障監(jiān)控

    智慧的概念與優(yōu)勢

    1. 概念介紹 智慧是指利用先進的信息技術和智能化手段,對的運營管理、服務功能、安全保障等方面進行全面升級和優(yōu)化的現(xiàn)代化交通樞紐。通過數字化、網絡化和智能化技術的應用,實現(xiàn)
    的頭像 發(fā)表于 10-12 14:31 ?261次閱讀

    OBOO鷗柏信發(fā)系統(tǒng)BS網絡架構安全傳輸和訪問控制的解決方案

    通信的網絡應用方式,這種應用通常采用用戶名和口令的機制進行簡單的身份認證,中間傳輸的數據均是明文數據。目前這種B/S架構的網絡應用系統(tǒng)缺乏一定的安全性,在建立的PK
    發(fā)表于 08-02 16:54 ?0次下載

    建造智慧的作用是什么

    藍策電子打造智慧?通過重新劃分設施、?功能區(qū),?提升效率、?節(jié)約成本,?以及對車站運營管理各要素進行綜合打分,?將體驗指標量化,?督促車站管理服務水平的提升,?從而實現(xiàn)打造人性化車站的目標
    的頭像 發(fā)表于 07-30 09:32 ?348次閱讀
    建造智慧<b class='flag-5'>高</b>鐵<b class='flag-5'>站</b>的作用是什么

    美國群vps云服務器的應用場景和使用方法

    美國群VPS云服務器在多站點托管、SEO優(yōu)化、可用性與穩(wěn)定性、成本效益、安全性以及特定行業(yè)應用等方面具有廣泛的應用場景。美國群VPS云服務器是一種高性能、
    的頭像 發(fā)表于 07-26 15:56 ?443次閱讀

    客運樞紐IPTV電視系統(tǒng)-鹽城西廣場IP電視系統(tǒng)應用淺析

    客運樞紐IP電視系統(tǒng)設計,為海特偉業(yè)在“互聯(lián)網+”成為國家戰(zhàn)略背景下,充分考慮了我國客運樞紐電視系統(tǒng)的現(xiàn)狀與發(fā)展方向,以不同客運樞紐對電視系統(tǒng)功能和使用的新需求為導向,以“互聯(lián)網+”在電視中
    的頭像 發(fā)表于 07-09 10:55 ?250次閱讀
    <b class='flag-5'>高</b>鐵<b class='flag-5'>站</b>客運樞紐IPTV電視系統(tǒng)-鹽城<b class='flag-5'>高</b>鐵<b class='flag-5'>站</b>西廣場IP電視系統(tǒng)應用淺析

    EMC與EMI一式解決方案:理論到實踐的跨越

    深圳比創(chuàng)達電子EMC|EMC與EMI一式解決方案:理論到實踐的跨越
    的頭像 發(fā)表于 05-24 09:44 ?493次閱讀
    EMC與EMI一<b class='flag-5'>站</b>式解決方案:理論到<b class='flag-5'>實踐</b>的跨越

    華為云 FunctionGraph 構建可用系統(tǒng)的實踐

    每年,網上都會報道 XXX 系統(tǒng)異常不可用,給客戶帶來巨大的經濟損失。云服務的客戶基數更大,一旦出現(xiàn)問題,都將給客戶和服務自身帶來極大影響。本文將基于華為云 FunctionGraph 自身的實踐
    的頭像 發(fā)表于 05-09 23:14 ?462次閱讀
    華為云 FunctionGraph 構建<b class='flag-5'>高</b><b class='flag-5'>可用</b>系統(tǒng)的<b class='flag-5'>實踐</b>

    B完成鴻蒙原生應用Beta版研發(fā)

    此外,用戶還可在該平臺上即時參與一鍵三連、發(fā)表彈幕和評論等多元化的社區(qū)活動。B官方承諾,接下來會進一步優(yōu)化視頻消費及社交互動功能,并在鴻蒙系統(tǒng)自帶的智能、安全和連接功能基礎上,帶給大家更多創(chuàng)新體驗,如內容智能流轉、版面智能布置等特色功能。
    的頭像 發(fā)表于 03-29 16:20 ?712次閱讀

    華為云網站可用解決方案引爆華為云開年采購季:助力多場景下業(yè)務可用、數據可靠

    隨著數字化轉型進程不斷深入,企業(yè)核心系統(tǒng)的穩(wěn)定性、云上業(yè)務的連續(xù)性逐漸成為影響企業(yè)持續(xù)運營的關鍵因素。為了讓中小企業(yè)上云之旅走得更加穩(wěn)健,華為云開年采購季重點向企業(yè)客戶推薦網站可用解決方案,面向
    的頭像 發(fā)表于 03-17 12:30 ?281次閱讀

    工業(yè)RTU串口網關有哪些使用用途和使用場景

    工業(yè)RTU串口網關主要以串口形式實現(xiàn)對設備的鏈接和數據采集、傳輸,具有設備對接方便、設備對接數量多、系統(tǒng)整體穩(wěn)定性、部署快捷等優(yōu)勢,可以廣泛應用于各種工業(yè)領域。本篇就為大家簡單介紹一下工業(yè)串口網關的使用用途和使用場景:
    的頭像 發(fā)表于 01-23 17:40 ?962次閱讀
    工業(yè)RTU串口網關有哪些使<b class='flag-5'>用用</b>途和使用場景
    RM新时代网站-首页