服務降級的設計與實踐

服務降級設計與實踐

服務降級定義

當服務總體負載超出預設的上限閾值或即將到來的流量頂,即將會超過預設閾值時,爲了保證重要或基本的服務能正常運行,拒絕部分請求或者將一些不重要,[斷句]不緊急的服務或任務,[斷句]進行服務的延遲使用或暫停使用;

--理解了好長時間才,發現是斷句的--

 

服務降級的目的

當流量高峯期時,在短期請求量逐漸增大,由於服務的能力有限,致使性能降低,最終出現服務的宕機或者雪崩,因此須要服務降級

--就是要對一些請求拒絕--

 

服務降級案例

在案例中能夠看到,應該是在相似雙十一,618等節日,網絡流量瞬間上漲,超越預設的閾值,爲了保證支付服務等其餘重要服務,一些其餘不是很重要的服務就都出現了降級,提示擁擠,人多請重試,這就是服務降級,固然不建議提示網絡很差用,會被投訴的[捂臉]

 

服務降級目標

保證核心服務可用;非核心服務弱可用,甚至不可用

• 核心服務:直接和錢沾邊,或者間接和錢沾邊

• 好比搜索列表,在去支付的路上
• 加入購物車,表明要買了
• 支付,已經準備掏錢了

• 非核心服務:和錢不沾邊,或者影響支付

• 個人訂單:已經下完單了,不用看
• 退貨服務:取消是不可能的

服務降級手段

• 拒絕部分請求

• 拒絕部分老請求

• 減輕微服務請求處理數量
• 確保"新"請求正常響應
• RPC隊列方式(請求入隊,出隊時間處理請求時,檢查請求在隊列請求時間超過必定時間[好比1秒],直接丟棄)
• --感受就是消息隊列,在隊列中超過1秒,還沒被消費,直接丟棄--

• 優先級請求方式

• 非核心請求直接丟棄
• 業務緊密

• 隨機拒絕方式

• 隨機丟棄必定比例的請求
• 網站一會可用,一會不可用

• 關閉部分業務(業務相關)

第一種拒絕部分老的請求是開啓機制,第二種優先級是丟棄策略,能夠如今網關直接丟棄不是核心請求的請求,而後經過隊列記錄寫入和處理時間獲取,在隊列中停留的時間,判斷是否超出設置的閾值,若是超出直接丟棄

 

服務層降級架構層次

• 集中式

• 網關層

• 自治式

• 網關層
• 業務邏輯層
• 數據訪問層

水平分層架構

由於不一樣的層次的一樣設備的處理能力是不同的,假設網關層能處理200請求,業務邏輯層只能處理100請求,數據訪問層,只能處理50請求

集中式:

直接在網關層砍掉150請求才能符合數據訪問層的請求能力,而且是中間隔着業務邏輯層的,並很差知道

自治式:

層層降級,最終砍到數據訪問層能處理的請求數量,由於每層都是挨着的因此,容易一些

 

數據層降級

• 更新請求

• 持久到消息隊列
• 只更新緩存

• 讀請求

• 讀緩存

• 數據補齊

• 消息隊列->數據庫

新浪微博,在數據流量的高峯期,好比網紅髮段子,或者一些事件,那麼更新的消息數據會寫到隊列中並寫入緩存,其餘人拉取的時候,都是讀取的緩存,等到流量陷入低峯期時,讀取消息隊列,並寫入到數據庫,實現數據補齊

**通常不是用**

 

服務降級可用策略

自動打開:不依賴人工

演練:保證線上生效

 

睡覺覺了...