服務(wù)保護

我心中的服務(wù)保護

做服務(wù)保護已經(jīng)很長時間了憨栽，記得來公司大概1個月后浓领，就去服務(wù)保護這個團隊進行開發(fā)了反镇》赶罚可以說服務(wù)保護伴隨了我的成長送火，也可以說我陪著服務(wù)保護這個項目走完了他的開始到結(jié)束。

服務(wù)保護項目是什么

簡答來說服務(wù)保護項目就是為了保證服務(wù)的穩(wěn)定性而出生的一套保護方案先匪。包括降級种吸，限流，故障演練和預(yù)案等多重功能呀非。

為什么要做服務(wù)保護

簡單來說在線上環(huán)境任何依賴的中間系統(tǒng)我們都可以認為是不可靠的坚俗，例如數(shù)據(jù)庫有可能會down機镜盯。例如緩存有可能會down機，但是面對這些問題我們的系統(tǒng)需要有能力做到減少故障時長猖败，快速降級速缆。引用Hystrix框架

復(fù)雜分布式體系結(jié)構(gòu)中的應(yīng)用程序具有許多依賴關(guān)系，每個依賴關(guān)系在某些時候都不可避免地失敗恩闻。如果主機應(yīng)用程序不與這些外部故障隔離艺糜，則有可能被拆除。

例如幢尚，對于依賴30個服務(wù)的應(yīng)用程序破停，每個服務(wù)的正常運行時間為
99.99％，以下是您所期望的：

99.99 30 = 99.7％正常運行時間
10億次請求中的0.3％= 3,000,000次故障
即使所有依賴關(guān)系都具有出色的正常運行時間尉剩，每次宕機時間仍然為2小時> 以上真慢。

現(xiàn)實通常更糟糕。

即使所有依賴性都能很好地發(fā)揮作用边涕，如果您沒有設(shè)計整個系統(tǒng)的彈性，那么幾十項服務(wù)中每項服務(wù)的停機時間甚至達到0.01％的總體影響等同于每月停機時間可能達到的小時數(shù)褂微。

降級

面對非核心流程我們需要有能力快速的切換降級問題服務(wù)功蜓，例如緩存的tair有問題了，我們需要降級到redis宠蚂。例如某個下游非核心服務(wù)有問題了式撼，我們需要快速對其降級。

解決痛點：基于記錄求厕，并操作ZK進行配置變更著隆，流程長，降級速度較慢呀癣。

痛點

限流

為什么要做限流呢美浦？主要是因為針對非核心流程我們可以進行降級的操作，但是針對核心流程项栏，例如訂單創(chuàng)建這種寫入數(shù)據(jù)庫的流程或者交易相關(guān)記錄交易信息的流程浦辨，我們不可能進行降級操作。為了保證主流程的穩(wěn)定性沼沈，我們需要對其進行限流流酬，保證系統(tǒng)的吞吐量在我們系統(tǒng)可以支撐的范圍只能，防止超高流量把系統(tǒng)打垮列另。

解決痛點：瞬時高流量沖擊芽腾，瞬時超高流量對業(yè)務(wù)系統(tǒng)的沖擊太強，RPC請求下游放大页衙，造成系統(tǒng)雪崩摊滔。

痛點

故障演練

現(xiàn)在我們的開發(fā)同學(xué)基本上大部分時間都在討論需求，寫代碼，很少有時間去好好鍛煉自己線上排查問題的能力惭载，而針對一個大型的系統(tǒng)來說旱函，每次發(fā)生問題都可能是大問題，如果沒有處理線上問題的經(jīng)驗描滔，就無法果斷的切換降級開關(guān)棒妨，那么線上問題就會越來越麻煩。所以針對這個痛點我們開發(fā)了故障演練模塊含长，模擬線上的故障券腔，豐富開發(fā)同學(xué)處理線上問題的能力。

解決痛點：開發(fā)同學(xué)缺乏故障降級經(jīng)驗拘泞，線上重大故障較少纷纫，開發(fā)同學(xué)缺乏針對重大故障降級的經(jīng)驗。

痛點

降級預(yù)案

降級預(yù)案陪腌，顧名思義這個是一個降級功能的組合辱魁，為什么要有這個組合呢？這個主要是針對于某類故障的發(fā)生诗鸭，快速降級某類故障染簇，例如在不同的服務(wù)中，都會對某一個tair集群進行訪問强岸，那么如果這個Tair集群發(fā)生問題了锻弓，我們怎么辦呢？一個一個處理分布在不同服務(wù)中的開關(guān)蝌箍？然后在過程中還不知道要設(shè)置什么值青灼。這個時候如果在故障發(fā)生前總結(jié)好預(yù)案，就可以在問題發(fā)生之前快速的進行處理問題了妓盲。

解決痛點：針對某類功能進行降級的時候杂拨，一個一個操作ZK會浪費很多時間。

痛點