《RPC實戰與核心原理》學習筆記Day12

15 | 熔斷限流:業務如何實現自我保護?

爲什麼我們的服務需要自我保護?

RPC是解決分佈式系統通信問題的一大利器,它會面臨高併發的場景,這意味着我們提供服務的每個服務節點都有可能由於訪問量過大而引起一系列的問題,例如業務處理耗時過長、CPU利用率過高、頻繁Full GC以及服務進程直接宕機等,在生產環境中,我們要保證服務的穩定性和高可用性,這就需要業務進行自我保護,從而在高訪問量、高併發的場景下,應用系統依然穩定,服務依然高可用。

使用RPC時,業務如何實現自我保護?

可以在服務提供方做限流操作,在服務調用方做熔斷操作。

熔斷是調用方爲了避免在調用過程中,服務提供方出現問題的時候,自身資源被耗盡的一種保護行爲,而限流則是服務提供方爲防止自己被突發流量打垮的一種保護行爲。

熔斷和限流有什麼區別?

熔斷主要在服務調用方進行設置,限流主要在服務提供方進行設置。

服務端如何實現限流邏輯?

方式有很多,包括計數器、滑動窗口、漏斗算法和令牌桶算法等,其中令牌桶算法最常用。

我們發佈服務後,提供給多個應用的調用方去調用,這時有一個應用的調用方發送過來的請求流量要比其他的應用大很多,這時我們就應該對這個應用下的調用端發送過來的請求流量進行限流。所以我們在限流時,需要考慮應用級別的維度,甚至是IP級別的維度,這樣做不僅可以讓我們對一個應用下的調用端發送過來的請求流量做限流,還可以對一個IP發送過來的請求流量做限流。

在服務端實現限流,配置的限流閾值是作用在每個服務節點上的。

我們還可以提供一個專門的限流服務,讓每個節點都依賴一個限流服務,當請求流量打過來時,服務節點觸發限流邏輯,調用這個限流服務來判斷是否到達了限流閾值。我們甚至可以將限流邏輯放在調用端,調用端在發出請求時先觸發限流邏輯,調用限流服務,如果請求量已經到達了限流閾值,請求都不需要發出去,直接返回給動態代理一個限流異常即可。

在一個服務作爲調用端去調用另外一個服務時,爲了防止被調用的服務出現問題而影響到座位調用端的這個服務,那麼服務調用端也需要進行自我保護,而最有效的自我保護方式就是熔斷

熔斷器的工作原理是怎樣的?

熔斷器的工作機制主要是關閉、打開和半打開這三個狀態之間的切換。在正常情況下,熔斷器是關閉的,當調用端調用下游服務出現異常時,熔斷器會收集異常指標信息進行計算,當達到熔斷條件時熔斷器打開,這時調用端再發起請求是會直接被熔斷器攔截,並快速地執行失敗邏輯,當熔斷器打開一段時間後,會轉爲半打開狀態,這時熔斷器允許調用端發送一個請求給服務端,如果這次請求能夠正常地得到服務端的響應,則將狀態置爲關閉狀態,否則設置爲打開。

熔斷器放在哪裏比較合適?

建議放在調用方的動態代理模塊,因爲這時RPC調用的第一個關口,在發出請求時先經過熔斷器,如果狀態是閉合則正常發出請求,如果狀態是打開則執行熔斷器的失敗策略。

16 | 業務分組:如何隔離流量?

關於爲什麼要對請求流量進行分組,作者舉了一個非常合適的例子:

在沒有汽車的年代,我們的道路很簡單,就一條,行人、洋車都在上邊走。隨着汽車的普及以及猛增,我們的道路越來越寬,慢慢地有了高速、輔路、人行道等。很顯然,交通網的建設和完善不僅提高了我們的出行效率,而且還更好的保障了我們行人的安全。

對服務進行分組,並沒有一個明確的可衡量的標準,但是一般建議非核心應用不要跟核心應用分在同一個組,核心應用之間應該做好隔離,一個重要的原則就是保障核心應用不受影響。

通過分組的方式隔離調用方的流量,從而避免因爲一個調用方出現流量激增而影響其他調用方的可用率。

服務分組隔離後,單個調用方在發RPC請求時可以選擇的服務節點數相比之前是減少了,那麼對於單個調用方來說,出錯的概率就增加了。

要解決這個問題,我們還需要把配置的分組區分主次分組,只有在主分組上的節點都不可用的情況下才去選擇次分組節點,只要主分組裏面的節點恢復正常,我們就必須把流量都切換到主節點上。整個切換過程對於應用層完全透明,從而在一定程度上保證了服務調用方應用高可用。

我們不僅可以通過分組把服務提供方劃分成不同規模的小集羣,我們還可以利用分組完成一個接口多種實現的功能。正常情況下,爲了方便我們自己管理服務,一般會建議每個接口完成的功能儘量保證唯一。但在有些特殊場景下,兩個接口也會完全一樣,只是具體實現上有所差別,那麼我們就可以在服務提供方應用裏面同時暴露兩個相同接口,但是接口分組不一樣。

在實際工作中,測試人員和開發人員的工作一般都是並行的,這就導致一個問題經常出現:開發人員在開發過程中可能需要啓動自身的應用,而測試人員爲了能驗證功能,會在測試環境中部署同樣的應用。如果開發人員和測試人員用的接口分組名剛好一樣,在這種情況下,就可能會干擾其它正在聯調的調用方進行功能驗證,進而影響整體的工作效率。有什麼解決辦法?

解決這個問題,有幾種思路:

  1. 不同團隊使用不同的服務註冊中心來管理服務節點。
  2. 可以採取類似於K8S中的命名空間的方法來隔離服務節點。
  3. 可以嘗試流量染色,具體可以參考有關於流量染色的一些實踐
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章