性能保障的那些事

初識(shí)大促保障，常會(huì)有這樣的疑問：保障保的到底是什么，確保沒有問題或者不出問題嗎？這似乎是個(gè)偽命題。而作為保障這件事本身，不僅要堅(jiān)信所為有意義，更要有所為，這就需要把不可能的偽命題轉(zhuǎn)化為可以不斷深入的可行任務(wù)。談及保障的根本，其實(shí)我們要面對(duì)的是對(duì)抗不確定性，這個(gè)不確定性來自四面八方。比如大地震，會(huì)導(dǎo)致整個(gè)機(jī)房中斷，如何應(yīng)對(duì)？比如負(fù)責(zé)核心系統(tǒng)的工程師離職了，如何應(yīng)對(duì)？再比如下游接口掛了，如何應(yīng)對(duì)？系統(tǒng)磁盤壞了，數(shù)據(jù)面臨丟失風(fēng)險(xiǎn)，如何應(yīng)對(duì)？我想關(guān)于上述問題的應(yīng)對(duì)方式，大家在工作中或多或少都有所了解，而這個(gè)不確定性的處理過程，就是容災(zāi)，其不同的‘災(zāi)難’，對(duì)應(yīng)不同的容災(zāi)級(jí)別。

為了對(duì)抗這些不同級(jí)別的不確定性，就要付出不同級(jí)別的成本，因此可用性也應(yīng)是有標(biāo)準(zhǔn)的。這標(biāo)準(zhǔn)就是大家常說的N個(gè)9。隨著N的增加，成本也相應(yīng)增加，那如何在達(dá)到業(yè)務(wù)需要的可用性的基礎(chǔ)上，盡量節(jié)省成本？這也是一個(gè)值得思考的話題。除此之外，100%減去這N個(gè)9就說所謂的平均故障時(shí)間（MTBF），很多人只關(guān)心那些9，而忽略了故障處理時(shí)間，這是不該的：你的故障處理速度越快，系統(tǒng)的可用性才有可能越高。

上面扯了一些可用性概念上的東西，下面嘗試使用‘事情’來分個(gè)類。這里的‘事’就是故障，分為：事前（故障發(fā)生以前）、事發(fā)（故障發(fā)生到系統(tǒng)或人感知到故障）、事中（故障發(fā)生到故障處理這段時(shí)間）、事后（故障結(jié)束之后）。

按照上述分類，不同的階段應(yīng)有著不同的技巧：

1. 事前：副本、隔離、配額、預(yù)案、探知

2. 事發(fā)：監(jiān)控、報(bào)警

3. 事中：降級(jí)、回滾、應(yīng)急預(yù)案

4. 事后：復(fù)盤、思考、技改

部分技術(shù)概念解釋如下：

副本：無狀態(tài)服務(wù)集群便是副本的一個(gè)應(yīng)用，因?yàn)闆]有狀態(tài)，便可水平伸縮，而這些無狀態(tài)服務(wù)器之間需要一層代理來統(tǒng)一調(diào)度管理，這便有了反向代理。當(dāng)代理通過心跳檢測(cè)機(jī)制檢測(cè)到有一臺(tái)機(jī)器出現(xiàn)問題時(shí)，就將其下線，其他‘副本’機(jī)器繼續(xù)提供服務(wù)；存儲(chǔ)領(lǐng)域也是經(jīng)常使用副本技術(shù)的，比如mysql主備切換，rabbitMQ的鏡像隊(duì)列，磁盤的RAID技術(shù)，各種nosql中的分區(qū)副本，等等數(shù)不勝數(shù)，幾乎所有保證高可用的系統(tǒng)都有冗余副本存在。

隔離：線程隔離、進(jìn)程隔離、集群隔離、機(jī)房隔離、讀寫隔離、動(dòng)靜隔離、爬蟲隔離、熱點(diǎn)隔離、硬件資源隔離。這些隔離其實(shí)就是一種，即資源隔離，無論線程、進(jìn)程、硬件、機(jī)房、集群都是一種資源；動(dòng)態(tài)資源和靜態(tài)資源也不過是資源的一種分類；熱點(diǎn)隔離也即是熱點(diǎn)資源和非熱點(diǎn)資源的隔離；讀寫隔離不過僅僅是資源的使用方式而已，相同的兩份資源，一份用來寫，一份用來讀。因此，隔離的本質(zhì)，其實(shí)就是對(duì)資源的獨(dú)立保護(hù)。因?yàn)槊總€(gè)資源都得到了獨(dú)立的保護(hù)，其中一個(gè)資源出了問題，不會(huì)影響到其他資源，這就提高了整體服務(wù)的可用性。

配額：配額技術(shù)通過限制資源供給來保護(hù)系統(tǒng)，從而提高整體可用性。限流是配額技術(shù)的一種，它通過調(diào)節(jié)入口流量水位上線，來避免供給不足所導(dǎo)致的服務(wù)宕機(jī)。限流分為集群限流和單機(jī)限流，集群限流需要分布式基礎(chǔ)設(shè)施配合，單機(jī)限流則不需要。除此之外，限流這里我們還需要考慮幾點(diǎn)：

1. 如何設(shè)置合理的限流值？限流值的設(shè)定是需要經(jīng)過全鏈路壓測(cè)、妥善評(píng)估CPU容量、磁盤、內(nèi)存、IO等指標(biāo)與流量之間的變化關(guān)系（不一定線性關(guān)系）、結(jié)合業(yè)務(wù)預(yù)估和運(yùn)維經(jīng)驗(yàn)后，才能確定。

2. 對(duì)于被限流的流量如何處理？有幾種處理方式，其一直接丟棄，用溫和的文案提醒用戶；其二，靜默，俗稱的無損降級(jí)，用緩存內(nèi)容刷新頁面；其三，蓄洪，異步回血，這一般用于事務(wù)型場(chǎng)景。

3.  會(huì)不會(huì)導(dǎo)致誤殺？單機(jī)限流會(huì)導(dǎo)致誤殺，尤其當(dāng)負(fù)載不均衡的情況下，很容易出現(xiàn)誤殺；單機(jī)限流值設(shè)定過小也容易出現(xiàn)誤殺的情況。 

預(yù)案：一般分為提前預(yù)案（事前）和應(yīng)急預(yù)案（事中）。提前預(yù)案提前執(zhí)行，比如將系統(tǒng)臨時(shí)從高峰模式切換成節(jié)能模式；應(yīng)急預(yù)案關(guān)鍵時(shí)刻才執(zhí)行，主要用于止血，比如一鍵容災(zāi)切換等。預(yù)案技術(shù)一般要配合開關(guān)使用，推預(yù)案一般也就是推開關(guān)了。除此之外，預(yù)案也可和限流、回滾、降級(jí)等相結(jié)合，預(yù)案的制定也可通過對(duì)歷史故障的分析尋找思路。

探知：探知當(dāng)前系統(tǒng)的可用性能力，其實(shí)無法提高系統(tǒng)可用性，做不好甚至還會(huì)降低系統(tǒng)可用性。壓測(cè)和演練是最常見的探知技術(shù) 。壓測(cè)分為全鏈路壓測(cè)和單鏈路壓測(cè)，全鏈路壓測(cè)用于像雙十一大促活動(dòng)等，需要各上下游系統(tǒng)整體配合，單鏈路壓測(cè)一般驗(yàn)證功能或做簡(jiǎn)單的場(chǎng)景壓測(cè)提取性能指標(biāo)。全鏈路壓測(cè)的一般過程是：壓測(cè)目標(biāo)設(shè)定和評(píng)估，壓測(cè)構(gòu)造，壓測(cè)腳本編寫部署，壓測(cè)數(shù)據(jù)準(zhǔn)備，小流量鏈路驗(yàn)證，通知上下游系統(tǒng)owner，壓測(cè)預(yù)熱，壓測(cè)，壓測(cè)結(jié)果評(píng)估報(bào)告，性能優(yōu)化。以上過程反復(fù)迭代，直到達(dá)到壓測(cè)目標(biāo)為止；演練一般按規(guī)模劃分：比如城市級(jí)別的容災(zāi)演練，機(jī)房級(jí)別的容災(zāi)演練，集群規(guī)模的容災(zāi)演練（DB集群，緩存集群，應(yīng)用集群等），單機(jī)級(jí)別的故障注入，預(yù)案演練等。

監(jiān)控和報(bào)警：一般出現(xiàn)故障的時(shí)候，老板大多會(huì)有三問：為什么才發(fā)現(xiàn)？為什么才解決？影響有多大？即使故障影響面較大，如果能迅速止血，在做復(fù)盤的時(shí)候多少能挽回一些面子，相反如果處理不及時(shí)，即使小小的故障，都可能讓你丟了飯碗。越早識(shí)別故障，就能越早解決問題，而這眼睛便是監(jiān)控和報(bào)警了。

降級(jí)：降級(jí)的內(nèi)涵豐富，我們只從鏈路角度去思考。降級(jí)的本質(zhì)是棄車保帥，通過臨時(shí)舍棄部分功能，保證系統(tǒng)整體可用性。降級(jí)雖然從整體上看系統(tǒng)仍然可用，但由于取舍的關(guān)系，那么可知所有的降級(jí)一定是有損的。不可能有真正的無損降級(jí)，而常說的無損降級(jí)指的是用戶體驗(yàn)無損。降級(jí)一定發(fā)生在層與層之間（上下游），要么a層臨時(shí)性不調(diào)用b層，這叫做熔斷，要么a層臨時(shí)調(diào)用c層（c層合理性一定<b層），這叫備用鏈路。無論是哪一種方式，都會(huì)面臨一個(gè)問題：如何確定什么時(shí)候降級(jí)，什么時(shí)候恢復(fù)？一般有兩種方式，其一是人工確認(rèn)，通過監(jiān)控報(bào)警等反饋機(jī)制，人工識(shí)別故障，推送降級(jí)，待故障恢復(fù)后在手動(dòng)回滾；其二是自適應(yīng)識(shí)別，最常用的指標(biāo)有超時(shí)時(shí)間、錯(cuò)誤次數(shù)、限值流等等，當(dāng)達(dá)到閾值時(shí)自動(dòng)執(zhí)行降級(jí)，恢復(fù)時(shí)自動(dòng)回滾。這兩種方式無需對(duì)比，它們都是經(jīng)常采用的高可用技巧。除此之外，我們還要注意降級(jí)和強(qiáng)弱依賴的關(guān)系。強(qiáng)弱依賴表示的是鏈路上下游之間的依賴關(guān)系，是’是否可降級(jí)‘的一種專業(yè)表述。一些降級(jí)的例子：

• 讀寫降級(jí)，實(shí)際上是存儲(chǔ)層和應(yīng)用層之間的降級(jí)，采用備用鏈路切換方式，損失了一致性；

• 功能降級(jí)，將部分功能關(guān)閉，實(shí)際上是應(yīng)用層和功能模塊層之間的降級(jí)，采用熔斷方式，損失了部分功能。

• 爬蟲降級(jí)，實(shí)際上是搜索引擎爬蟲和應(yīng)用系統(tǒng)之間的降級(jí)，采用備用鏈路切換方式，將爬蟲引導(dǎo)到靜態(tài)頁面，損失是引擎索引的建立和頁面收錄。

回滾：當(dāng)執(zhí)行某種變更出現(xiàn)故障時(shí)，最為穩(wěn)妥和有效的辦法就是回滾。雖然回滾行之有效，但并不簡(jiǎn)單，因?yàn)榛貪L有一個(gè)大前提：變更必須具有可回滾性。而讓某一種變更具有可回滾的特性，是要耗費(fèi)很大力氣的。索性的是，大部分基礎(chǔ)服務(wù)已經(jīng)幫我們封裝好了這一特性，比如DB的事務(wù)回滾（DB事務(wù)機(jī)制），代碼庫回滾（GIT的文件版本控制），發(fā)布回滾（發(fā)布系統(tǒng)支持）等等。我們?cè)谌粘Ｗ兏僮鞯臅r(shí)候，必須要確定你的操作是否可回滾，并盡力保證所有變更均可回滾。如果不能回滾，是否可以進(jìn)行熱更新（比如發(fā)布應(yīng)用到app store）或最終一致性補(bǔ)償?shù)阮~外手段保證系統(tǒng)高可用。