天天看點

微服務架構系列主題:高可用的本質及高可用架構的設計原則

本文轉自:公衆号 阿裡技術

目錄

一  高可用是一種控制風險的能力

二  為什麼要高可用

三  如何做高可用

1  風險相關概念

2  風險期望的公式

3  控制風險的4大因素(nPRT)

4  高可用架構設計的7大核心原則

少依賴原則:能不依賴的,盡可能不依賴,越少越好(n)

弱依賴原則:一定要依賴的,盡可能弱依賴,越弱越好(P)

分散原則:雞蛋不要放一個籃子,分散風險(R)

均衡原則:均勻分散風險,避免不均衡(R)

隔離原則:控制風險不擴散,不放大(R)

無單點原則:要有備援或其他版本,做到有路可退(T)

自我保護原則:少流血,犧牲一部分,保護另外一部分(P&R&T)

四  軟體風險在何方

1  軟體系統風險的來源

2  風險的數量:一生三,三生萬物

五  結束語

一  高可用是一種控制風險的能力

高可用是一種面向風險設計,使系統具備控制風險,提供更高的可用性的能力。

二  為什麼要高可用

對于一個公司而言,“為什麼要高可用”可以完整了解為“公司為什麼要(做系統)高可用”。以公司為對象,從内看包括:人,軟體(物),硬體(物);從外看包括:客戶,股東,社會;從自身看包括:公司。

微服務架構系列主題:高可用的本質及高可用架構的設計原則

高可用的大前提:所有事物都不是100%可靠的

  • 所有事物都是變化的(唯一不變的是變化)。
  • 所有變化的都不是100%可靠的。
  • 結論:所有事物都不是100%可靠。

内因:人、物都不是100%可靠的

  • 從人的層面:人都是有可能犯錯的。
  • 從軟體層面:軟體都是有可能有BUG的。
  • 從硬體層面:硬體都是有可能會壞的。

從機率學角度分析,凡是有可能會出錯的,隻要變化次數足夠多,最終出錯的機率會無限趨向于1。

外因:無高可用,對外影響面是很大的

  • 從客戶角度:無高可用,客戶服務可能會中斷。
  • 從股東層面:無高可用,股價可能會下跌。
  • 從社會角度:無高可用,社會秩序可能受影響。

根因(本質):控制風險

從公司自身角度:控制風險,保障公司價值,避免傷及根本。                                        

三  如何做高可用

如何做高可用,本質上就是:如何控制風險。   

1  風險相關概念

  • 風險:指未來會發生危害的一種可能性,但實際未發生,記為r。
  • 故障:指已發生或正在發生危害的一種事實,是風險變現實的結果。
  • 風險機率:指一個風險變故障的機率。用它來表示風險觸發為故障的難易程度,記為P(r)。
  • 故障影響範圍:指在機關時間内,一個故障造成的危害影響,記為R(r)。
  • 故障影響時長:指一個故障持續的時間,記為T(r)。
  • 故障影響面:指一個故障影響範圍乘以故障影響時長的總和。這裡用故障影響面來表示故障總的危害程度,記為F(r)。
  • 風險期望:指每個風險變故障的機率乘以每個風險變故障後的故障影響面的總和。這裡用風險期望來表示風險的潛在危害程度,記為E(r)。            

2  風險期望的公式

根據上節的定義,可以推導出風險期望的公式如下:

微服務架構系列主題:高可用的本質及高可用架構的設計原則

r代表風險,風險期望會随着風險的數量n和每個風險的P、R、T下降而下降,簡稱nPRT公式。

注:如果要引用該公式請注明出處。

3  控制風險的4大因素(nPRT)

減少風險數量,n

從源頭遠離風險,做到與風險載體無連接配接,無關系;那麼該風險機率就是0,也不關心該風險發生後的故障影響面是大是小,完全不關心。

  • 例如:重大節日活動,施行全站封網,變更的數量就會得到一個明顯的下降,就是典型的減少風險數量。
  • 例如:系統A完全不依賴Oracle,那系統A就不用關心Oracle的任何風險,哪怕美國總統突然緊急宣布Oracle立即立刻禁止在中國使用,系統A也無所謂。
  • 例如:最近新冠大流行,人傳人很可怕,如果你今天選擇不上班不出門,那你今天就不用擔心被外面的行人和同僚傳染。

降低風險變故障的機率(即:增加風險變故障的難度),P

把風險當成一個對象看待,給它層層設卡,增加風險變故障的門檻和難度,不要再讓“不小心多了一個空格或字元,系統就挂了”這種慘案輕易出現。

  • 例如:人員B要對系統C進行變更,可以對人員B增加變更認證考試,對變更内容要求線下(或仿真)測試,對變更内容進行CR,系統C提供變更效果預覽能力(類似監控模式或試運作),萬一人員B想惡意變更搞破壞,還可以增加非同人複核,系統C可以增加防錯設計進行保護等等。
  • 例如:以新冠為例,帶口罩,勤洗手,多通風等就可以降低染上新冠的機率。

減小故障影響範圍,R

以大拆小,将一個整體拆分成N個小的個體,每個個體之間進行互相隔離,單個個體出問題僅影響單個個體,實作小而美。

  • 例如:分布式架構就是這個的典範,集中式一損俱損,分布式一損即N分之一損。
  • 例如:以新冠為例,網格化管理,各省或市間的流動進行限制,跨省必須核酸+隔離14天,有效控制新冠的傳播範圍。

縮短故障影響時長,T

故障影響時長由故障發現時間和故障止血時間決定,是以要早發現早止血。

發現方式分為:事前的預警,事後的告警。盡可能朝事前預警去做,給止血争取時間甚至将風險扼殺在搖籃中。

止血方式分為:切換,復原,擴容,降級 or 限流,BUG修複等。故障出現時第一優先原則為快速止血(如切換、復原、擴容),嚴禁去定位根因;當無法快速止血時以少流血為第二優先原則,如降級、限流。

止血效率:自動 vs 人工 ;一鍵化 vs 多步操作。盡可能用自動化去代替人工操作,若人工操作時盡量實作一鍵化,提升止血速度。

  • 例如:對于容量水位,可以在警戒線之前劃一條預警線,提前預警,從容應對。
  • 例如:分布式應用叢集,任何一台應用伺服器有問題時,負載均衡會通過心跳檢查自動把有問題的應用伺服器剔除,将請求轉發給其他(熱)備份備援的伺服器上。
  • 例如:以新冠為例,但由于每個生命都是獨一無二的,沒有辦法切換,也沒有辦法復原,也不能降級(涉及人道主義),隻能對症下藥慢慢治療。

4  高可用架構設計的7大核心原則

根據nPRT公式,在高可用架構設計時有以下7個核心原則:

少依賴原則:能不依賴的,盡可能不依賴,越少越好(n)

由于所有事物都不是100%可靠的,當2個事物之間有了關系,那麼就會互相影響,就互為對方的一個風險,一個出問題可能會影響另外一個。我們統一用依賴來泛指這裡的“關系”。

  • 例如:一個系統同時依賴Oracle,Mysql,OB三種關系型資料庫,少依賴原則是改成僅依賴最成熟穩定的OB,不依賴Oracle和Mysql。

什麼場景适合多依賴?

當引入依賴(n變大)可以減小PRT中的一個或多個,且使E(r)整體下降時。

  • 例如:為解決DB風險,引入分布式緩存,隻要2者不同時挂的時候依然可用。

弱依賴原則:一定要依賴的,盡可能弱依賴,越弱越好(P)

事物a強依賴事物b,一旦b出問題時,那麼a也會出問題,一損俱損。

是以任何強依賴都要盡可能的轉化成弱依賴,可以直接降低出問題的機率。

  • 例如:交易核心鍊路在交易成功後要要給使用者發放積分權益;交易核心系統需要依賴積分權益系統,好的方式是采用弱依賴,使用異步化的方式,這樣積分權益系統不可用時,大機率不會影響交易核心鍊路。

分散原則:雞蛋不要放一個籃子,分散風險(R)

微服務架構系列主題:高可用的本質及高可用架構的設計原則

打散拆分成N份;避免全局隻有1份,否則一有問題影響範圍就是100%。

  • 例如:所有交易資料都放在同一個庫同一張表裡面,萬一這個庫挂了,此時影響所有交易。
  • 例如:将自己所有的錢買了同一隻股票,萬一這隻股票是樂視就慘了。

均衡原則:均勻分散風險,避免不均衡(R)

微服務架構系列主題:高可用的本質及高可用架構的設計原則

最好N份中的每份都是均衡的;避免某個份額過大,否則過大的那份一有問題就影響範圍過大了。

  • 例如:xx應用叢集有1000台,但由于引流元件BUG,導緻所有流量引到了其中100台上面,導緻負載嚴重不均衡,最後因負載無法扛着全面崩潰。類似重大故障已經發生了多次。
  • 例如:将自己所有的錢買了10隻股票,其中一隻占比99%,萬一這隻股票是樂視就慘了。

隔離原則:控制風險不擴散,不放大(R)

微服務架構系列主題:高可用的本質及高可用架構的設計原則

每份之間是互相隔離的;避免一份有問題影響其他的也有問題,傳播擴散了影響範圍。

  • 例如:交易資料拆分成10庫100表,但是部署在同一台實體機上;萬一某張表有一條大SQL把網卡打滿了,那10庫100表都會受影響。
  • 例如:将自己所有的錢均分買了10隻股票,每隻都占10%,但10隻都是樂視系的。
  • 例如:古代赤壁之戰就是一個典型的反面例子,鐵鎖連船導緻隔離性被破壞,一把大火燒了80w大軍。

隔離是有級别的,隔離級别越高,風險傳播擴散的難度就越大,容災能力越強。

  • 例如:一個應用叢集由N台伺服器組成,部署在同一台實體機上,或同一個機房的不同實體機上,或同一個城市的不同機房裡,或不同城市裡,不同的部署代表不同的容災能力。
  • 例如:人類由無數人組成,生活在同一個地球的不同洲上,這意味着人類不具備星球級别的隔離能力,當地球出現毀滅性影響時,人類是不具備容災的。

隔離原則是一個極其重要的原則,它是前面4個原則的前提。沒有做好隔離,前面4個原則都是脆弱的,風險很容易傳播擴散開,破壞前面4個原則的效果。大量真實系統故障是因為隔離性做得不好導緻的,如:線下影響線上,離線影響線上,預發影響生産,一條爛SQL影響整個庫(或整個叢集)等等。

分散,均衡,隔離是控制風險影響範圍的3個核心原則。打散拆分成N份,每一份都是均衡的,且互相隔離,一份有問題,影響範圍為1/N。

無單點原則:要有備援或其他版本,做到有路可退(T)

快速止血的方式是切換,復原,擴容等;復原和擴容屬于特殊的切換,復原指的是切換到某個版本,擴容指的是将流量切換到新擴容的機器上。

切換得有地方可切才行,是以不能有單點(這裡特指強依賴的單點,弱依賴的可以降級),要有備援備份或其他版本;單點會限制整體的可靠性。

假設單點的可靠性假設是99.99%,它要提升到99.999%是非常困難的,但是如果無單點而是依賴2個(1個挂掉沒有關系,隻要不同時挂就行),那整體可靠性就是99.999999% 會有質的提升。

單點故障會導緻無法快速止血,拉長整個止血時間,去單點至關重要。這裡的單點不僅僅指的是系統節點,也包含人員,如訂閱告警的人,應急的人等等。

對于(重要)資料節點,必須滿足無單點原則,否則極端情況下可能造成資料永久丢失,永遠無法恢複;(重要)資料節點滿足無單點原則後,保障資料一緻性比可用性要求更重要。

  • 例如:一個商戶僅支援一個支付管道,就是典型的單點,萬一這個支付管道挂了就不能支付了。
  • 例如:一個家庭的所有收入僅依賴父親一個的薪資收入,萬一這個父親病了,就沒有收入了。

無單點原則和分散原則的差別:

  • 當節點無狀态的情況下,打散拆分成N份,每份都是相同的功能,互為備援,即:節點無狀态情況下,分散原則和無單點原則等價,滿足一個即可。
  • 當節點有狀态的情況下,打散拆分成N份,每份都是不相同的,每份都沒有備援,需要針對每份再做備援,即:節點有狀态情況下,既要滿足分散原則又要滿足單點原則。

自我保護原則:少流血,犧牲一部分,保護另外一部分(P&R&T)

外部的輸入都不是100%可靠的,有時候是無意的錯誤,有時候甚至是惡意的破壞,是以針對外部輸入要有防錯設計,給自己多一些保護。

極端情況下可能無法(快速)止血,可以考慮少流血,犧牲一部分保護另外一部分。例如:限流,降級等。

  • 例如:大促峰值期間,一般會提前降級掉很多功能,同時限流,主要是為了保護峰值絕大部分人的交易支付體驗。
  • 例如:人體在失血過多或疼痛過度時就會觸發休克現象,這也是一種典型的自我保護機制。

四  軟體風險在何方

前面介紹了控制風險的方法,回到軟體系統這個領域,它的風險又在哪裡?

以軟體系統為對象,從内看包括:計算系統和存儲系統;從外看包括:人員,硬體,上遊系統,下遊系統;以及(隐含的)時間。

微服務架構系列主題:高可用的本質及高可用架構的設計原則

由于每個對象都是由其他對象組成的,是以每個對象還可以繼續往細分解(理論上可以無限分解下去),上面的分解方式主要是為了簡化了解。

1  軟體系統風險的來源

風險源于(有危害的)變化,一個對象的風險來源于所有跟它有關系的對象的(有危害的)變化。是以,軟體系統風險的來源,分為以下7大類:

計算系統變化:運作變慢,運作錯誤

系統運作所依賴的伺服器資源(如CPU,MEM,IO等),應用資源(RPC線程數,DB連接配接數等),業務資源(業務ID滿了,餘額不足,業務額度不夠等)的負載等都會影響系統運作的風險期望。

存儲系統變化:運作變慢,運作錯誤,資料錯誤

系統運作所依賴的伺服器資源(如CPU,MEM,IO等),存儲資源(并發數等),資料資源(單庫容量,單表容量等)的負載和資料一緻性等都會影響存儲系統運作的風險期望。

人的變化:變更出錯

變更人員的數量,安全生産意識,熟練程度,變更的數量,變更的方式等都會影響變更的風險期望。

由于變更的人多,變更的次數也多,導緻變更成為螞蟻所有故障來源裡的TOP1,這也是為什麼“變更三闆斧”這麼出名的原因。

“變更三闆斧”正确的排序應該是“可灰階,可監控,可應急”;可灰階代表的是R,可監控和可應急代表的是T。

思考:如果變更三闆斧讓你再加一闆斧,你覺得應該是什麼?

硬體變化:損壞

硬體的數量,品質,使用年限,保養等都會影響硬體的風險期望,硬體損壞會影響上層軟體系統不可用。

上遊變化:請求變大

請求分為3個次元:(由無數API彙集而成的)網絡流量,(由無數KEY請求組成的)API,KEY。

  • 網絡流量過大會造成網絡堵塞,影響網絡通道中的所有網絡流量請求。
  • API請求過大會造成對應服務叢集過載,影響整個服務機器上的所有API請求,甚至往外傳播。
  • KEY請求過大(俗稱“熱點KEY”)會造成單機過載,影響單機上所有KEY請求,甚至往外傳播。

是以大促保障的時候,不僅僅是關注核心API的容量保障,還需要考慮網絡流量和熱點KEY。

下遊變化:響應變慢,響應錯誤

下遊服務的數量,服務等級,服務可用率等影響下遊服務的風險期望。下遊響應變慢可能會拖慢上遊,下遊響應錯誤可能會影響上遊運作結果。

時間變化:時間到期

時間到期往往被人忽視,但它往往具有突然性和全局破壞性,一旦時間到期觸發故障會導緻非常被動,是以要提前識别,盡早預警,如:秘鑰到期,證書到期,費用到期,跨時區,跨年,跨月,跨日等。

  • 例如:2019年日本營運商軟銀因證書到期引發3000w使用者長達4小時通信中斷。
以上每一大類風險都可以基于nPRT公式進行逐一分析處理。

2  風險的數量:一生三,三生萬物

任何一個事物既是由其他事物組成的又是其他事物的組成部分,無限循環下去;一生三,三生萬物,風險的數量是無窮無盡的。

向内看,内含内,可以無限小下去;當原子粒度的問題傳播開時,也可能影響軟體系統的可用性,就像100納米的新冠病毒就可以影響人體的可用性一樣。

向外看,外有外,可以無限大下去;當太陽系毀滅,軟體系統的可用性自然就不複存在。

雖然風險無窮無盡,但是隻要我們對風險多一些了解,根據控制風險的一些理念和原則,還是可以更好的降低風險期望。

談一談敬畏之心:

  • 我們對世界的認知是有限的,這也讓我們少了許多恐懼,同時也讓我們少了一些敬畏之心。
  • 我們真正要敬畏的不是處罰條例,而是我們不知道的,以及我們不知道我們不知道。

五  結束語

  • 所有事物都是變化的。
  • 所有事物都不是100%可靠的。
  • 是以才有了風險,風險是不可見的,可見的是故障。
  • 風險是不能消滅光的,但是可以遠離,可以減少。
  • 故障是不可避免的,但是可以推遲,可以縮小影響範圍,縮短影響時間。

nPRT公式不僅僅适用于軟體系統風險,也适用于其他風險領域,希望對大家有用。

繼續閱讀