1 引言

一切的一切，始于一場(chǎng)戰(zhàn)爭(zhēng)奴璃。

1.1 夜王之死悉默，論高可用的重要性

? ? 《權(quán)利的游戲》第八季今年(捂臉，這文章拖得時(shí)間太久了苟穆，這都2020年了…)終于開(kāi)播抄课，讓眾多權(quán)游迷大跌眼鏡的是，從第一季辛辛苦苦走了八季來(lái)到我們面前的夜王雳旅，剛出場(chǎng)一集就被二丫殺死跟磨，成功獲得年度最悲催男人的封號(hào)。

? ? ? ? 夜王雖然死了攒盈，我們可愛(ài)的抵拘、看熱鬧不怕事大的程序猿卻進(jìn)行了積極的思考，一篇《夜王一死型豁，異鬼咋就團(tuán)滅僵蛛？這是個(gè)嚴(yán)肅的科學(xué)問(wèn)題》的文章瞬間在工程師中間開(kāi)始流傳尚蝌。文章中深入淺出的分析了夜王與其所控制的異鬼與冰龍之間的關(guān)系，并與人類軍隊(duì)進(jìn)行了對(duì)比充尉，最終得出了一個(gè)重要的結(jié)論：臨冬城之戰(zhàn)飘言，實(shí)際上是一場(chǎng)“中心化系統(tǒng)”和“非中心化系統(tǒng)”之間的戰(zhàn)斗。

? ? ? ? 夜王與其控制的異鬼軍團(tuán)驼侠，是一個(gè)“中心化系統(tǒng)”姿鸿，“中心化系統(tǒng)”盡管非常強(qiáng)大，但是它只要失敗一次倒源，就永遠(yuǎn)玩完苛预；“去中心化系統(tǒng)”可以屢敗屢戰(zhàn)，星火不滅總可燎原笋熬。

? ? ? ? 如果這次夜王不死碟渺，他應(yīng)該將自己升級(jí)為一個(gè)高可用系統(tǒng)，再來(lái)統(tǒng)一整個(gè)維斯特洛大陸突诬。

1.2 挖掘機(jī)苫拍，高可用殺手

? ? ? ? 夜王剛死不久，挖掘機(jī)再次閃亮登場(chǎng)旺隙。2019年6月2日凌晨绒极，某云數(shù)據(jù)中心光纜被挖斷，托管在其上的眾多應(yīng)用無(wú)法提供服務(wù)蔬捷，其中大家喜聞樂(lè)見(jiàn)某英語(yǔ)學(xué)習(xí)APP也無(wú)法正常使用垄提，為我們辛苦的中國(guó)小朋友獻(xiàn)上兒童節(jié)賀禮：終于可以休息休息，不用再上課周拐。

1.3 做了異地多活铡俐，系統(tǒng)就可用了嗎？

? ? ? 生命誠(chéng)可貴妥粟，系統(tǒng)價(jià)更高审丘。歷經(jīng)無(wú)數(shù)次開(kāi)發(fā)變更、再開(kāi)發(fā)再變更勾给，經(jīng)歷九九八十一難建設(shè)好的系統(tǒng)滩报，難道真的就對(duì)一個(gè)挖掘機(jī)束手無(wú)策嗎？

? ? ? 非也播急、非也脓钾！方案總比問(wèn)題多，使用在金融行業(yè)多年的兩地三中心桩警、流行于互聯(lián)網(wǎng)的異地多活方案可训，為我們指明了方向。

1.3.1 異地多活架構(gòu)

? ? ? 下圖是螞蟻金服2019年在互聯(lián)網(wǎng)大會(huì)上分享的三地五中心架構(gòu)，它已經(jīng)不是一個(gè)多中心之間互相做災(zāi)備的架構(gòu)握截，而是一個(gè)多地多中心多活的架構(gòu)飞崖。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? （圖片來(lái)源于網(wǎng)絡(luò)）

? ? ? ? 在多活架構(gòu)情況下，實(shí)際上可以做到在不同的中心之間任意的去劃撥用戶的流量川蒙。 在2018年的云棲大會(huì)上螞蟻金服副CTO胡喜在ATEC主論壇現(xiàn)場(chǎng)模擬挖斷支付寶近一半服務(wù)器的光纜蚜厉。結(jié)果只用了26秒长已，模擬環(huán)境中的支付寶就完全恢復(fù)了正常畜眨。--《螞蟻金服資深總監(jiān)韓鴻源：像使用集中式數(shù)據(jù)庫(kù)一樣使用OceanBase分布式數(shù)據(jù)庫(kù)》

1.3.2 架構(gòu)是萬(wàn)能的嗎？

? ? 那么术瓮，采用了先進(jìn)的異地多活架構(gòu)康聂、在部署層面做了各種高可用，我們的系統(tǒng)就可以高枕無(wú)憂胞四、做到7*24小時(shí)無(wú)間斷運(yùn)行嗎恬汁？

? ? 理想與現(xiàn)實(shí)總是有差距：沒(méi)有架構(gòu)是不行的，但架構(gòu)也不是萬(wàn)能的辜伟。

? ? 以下是一個(gè)真實(shí)的案例：

? ? ? 現(xiàn)象：某網(wǎng)站的前置網(wǎng)關(guān)應(yīng)用突然故障氓侧，處理請(qǐng)求的線程池用滿，無(wú)法再接收新的服務(wù)請(qǐng)求导狡；網(wǎng)關(guān)應(yīng)用其他指標(biāo)均正常约巷；

? ? 原因：該網(wǎng)關(guān)應(yīng)用負(fù)責(zé)代理后臺(tái)微服務(wù)應(yīng)用請(qǐng)求，新上線的一個(gè)后臺(tái)服務(wù)存在響應(yīng)緩慢故障旱捧；網(wǎng)關(guān)線程池逐漸都被該故障服務(wù)請(qǐng)求轉(zhuǎn)發(fā)占滿独郎，導(dǎo)致無(wú)法響應(yīng)用戶請(qǐng)求；

? ? 緊急處理方式：停止對(duì)故障應(yīng)用的請(qǐng)求轉(zhuǎn)發(fā)枚赡，重啟網(wǎng)關(guān)應(yīng)用集群氓癌，恢復(fù)服務(wù)。?

? ? ? 其實(shí)贫橙，在微服務(wù)體系下贪婉，如果實(shí)現(xiàn)引入了服務(wù)熔斷機(jī)制，就會(huì)更加優(yōu)雅和有效避免在外調(diào)失敗時(shí)卢肃，對(duì)自己的系統(tǒng)造成不良影響谓松，避免級(jí)聯(lián)失敗。

2 方法論

2.1 高可用定義

? ? ? ? 首先先看一下維基百科對(duì)高可用性的定義：

? ? ? ? 高可用性（英語(yǔ)：high? availability践剂，縮寫(xiě)為 HA）鬼譬，IT術(shù)語(yǔ)，指系統(tǒng)無(wú)中斷地執(zhí)行其功能的能力逊脯，代表系統(tǒng)的可用性程度优质。是進(jìn)行系統(tǒng)設(shè)計(jì)時(shí)的準(zhǔn)則之一。高可用性系統(tǒng)與構(gòu)成該系統(tǒng)的各個(gè)組件相比可以更長(zhǎng)時(shí)間運(yùn)行。

? ? ? ? 我們經(jīng)常用幾個(gè)9來(lái)評(píng)判一個(gè)系統(tǒng)的可用性是否足夠高巩螃，下表是可用性與系統(tǒng)一年中不可用時(shí)間的對(duì)應(yīng)關(guān)系演怎。

2.2 高可用系統(tǒng)PDCA環(huán)

? ? ? ? ? ? 那么，有沒(méi)有一種行之有效的方法避乏，能幫我們打造一個(gè)高可用的分布式系統(tǒng)呢爷耀？

? ? ? ? ? ? 筆者通過(guò)對(duì)行業(yè)領(lǐng)先者先進(jìn)實(shí)踐的研究，得出如下切實(shí)可行的方法拍皮，稱之為“高可用系統(tǒng)PDCA環(huán)”歹叮。“PDCA”戴明環(huán)在包括項(xiàng)目管理等多個(gè)領(lǐng)域有著廣泛的應(yīng)用铆帽，同樣可以指導(dǎo)我們打造高可用分布式系統(tǒng)咆耿。

? ? ? 整個(gè)“高可用系統(tǒng)PDCA環(huán)”包括如下四部分：

? ? ? ? Plan：對(duì)分布式系統(tǒng)進(jìn)行高可用設(shè)計(jì)，參考業(yè)內(nèi)成熟的設(shè)計(jì)模式爹橱、先進(jìn)實(shí)踐進(jìn)行高可用設(shè)計(jì)萨螺；

? ? ? ? Do：對(duì)設(shè)計(jì)進(jìn)行落地，開(kāi)發(fā)出可運(yùn)行的分布式系統(tǒng)愧驱；：

? ? ? ? Check：對(duì)系統(tǒng)進(jìn)行測(cè)試驗(yàn)證慰技，檢驗(yàn)系統(tǒng)的可用性。目前業(yè)內(nèi)也有了驗(yàn)證系統(tǒng)可用性的一套方法和工程實(shí)踐（混沌工程）组砚，可以借鑒采用吻商；

? ? ? ? Action：對(duì)測(cè)試驗(yàn)證中發(fā)現(xiàn)的缺陷進(jìn)行跟蹤處理，再次觸發(fā)高可用設(shè)計(jì)惫确，循環(huán)迭代提升系統(tǒng)的可用性手报。

? ? 本文后續(xù)部分將重點(diǎn)針對(duì)分布式系統(tǒng)的高可用設(shè)計(jì)和驗(yàn)證展開(kāi)闡述。

3 設(shè)計(jì)一個(gè)高可用分布式系統(tǒng)

3.1? 互聯(lián)網(wǎng)場(chǎng)景下高可用面臨的挑戰(zhàn)

? ? ? ? 互聯(lián)網(wǎng)場(chǎng)景往往面對(duì)海量用戶改化，從而帶來(lái)了兩個(gè)海量問(wèn)題：海量數(shù)據(jù)掩蛤、海量并發(fā)。

? ? ? ? ? 海量數(shù)據(jù)：海量用戶帶來(lái)了海量的數(shù)據(jù)陈肛，數(shù)據(jù)的存儲(chǔ)與訪問(wèn)都面臨著巨大的壓力揍鸟。對(duì)于傳統(tǒng)的單一數(shù)據(jù)庫(kù)或者單一數(shù)據(jù)庫(kù)集群（數(shù)據(jù)庫(kù)主從部署，支持讀寫(xiě)分離等）句旱，都面臨著達(dá)到硬件處理能力瓶頸阳藻，數(shù)據(jù)訪問(wèn)緩慢甚至不可用，導(dǎo)致整個(gè)系統(tǒng)可用性出現(xiàn)問(wèn)題谈撒；

? ? ? ? ? 海量并發(fā)：高并發(fā)帶來(lái)對(duì)系統(tǒng)處理性能的更高要求腥泥，能夠在并發(fā)壓力的不斷增加下保持穩(wěn)定的響應(yīng)時(shí)間，對(duì)于高可用至關(guān)重要啃匿；沒(méi)有經(jīng)過(guò)精心設(shè)計(jì)的系統(tǒng)蛔外，響應(yīng)時(shí)間會(huì)隨著并發(fā)的增大急劇變長(zhǎng)蛆楞，從而導(dǎo)致系統(tǒng)處理能力急劇下降，影響系統(tǒng)的高可用夹厌。

3.2? 彈性系統(tǒng)提供無(wú)線擴(kuò)容能力

3.2.1? 基于應(yīng)用和數(shù)據(jù)分布式提供系統(tǒng)彈性能力

? ? 我們談一個(gè)系統(tǒng)的高可用性豹爹，往往會(huì)談到系統(tǒng)的彈性伸縮，《The art of scalability》一書(shū)中矛纹，提出了一個(gè)系統(tǒng)擴(kuò)展模型（scale cube）臂聋，描述了分布式系統(tǒng)彈性擴(kuò)展的三個(gè)維度：

? ? X軸：代表運(yùn)行多個(gè)負(fù)載均衡器之后運(yùn)行的實(shí)例，即通過(guò)應(yīng)用服務(wù)器集群提供系統(tǒng)的處理能力和可用性或南，但數(shù)據(jù)庫(kù)層面不支持水平擴(kuò)展孩等；

? ? Y軸：應(yīng)用功能分解，將應(yīng)用層和數(shù)據(jù)模型層的垂直切分迎献，實(shí)現(xiàn)微服務(wù)架構(gòu)瞎访。各應(yīng)用可以獨(dú)立的進(jìn)行水平擴(kuò)展腻贰，單一應(yīng)用內(nèi)部數(shù)據(jù)庫(kù)層面仍然無(wú)法實(shí)現(xiàn)水平擴(kuò)展吁恍；

? ? Z軸：數(shù)據(jù)分片，對(duì)應(yīng)用內(nèi)的數(shù)據(jù)進(jìn)行分庫(kù)分表播演，實(shí)現(xiàn)數(shù)據(jù)庫(kù)層面的水平擴(kuò)展冀瓦。

? ? 這三個(gè)維度的劃分，在一定意義上也代表了一個(gè)單體系統(tǒng)向分布式系統(tǒng)演進(jìn)的一個(gè)路徑：

? ? 第一階段：?jiǎn)误w應(yīng)用写烤，通過(guò)應(yīng)用服務(wù)器集群來(lái)提高系統(tǒng)的可用性翼闽，支持應(yīng)用層級(jí)的彈性擴(kuò)展。但是洲炊，隨著數(shù)據(jù)量的不斷增大感局，開(kāi)發(fā)人員已經(jīng)使用了緩存、讀寫(xiě)分離等策略暂衡，仍然會(huì)達(dá)到單一數(shù)據(jù)庫(kù)集群處理能力瓶頸询微，無(wú)論再怎么增加應(yīng)用服務(wù)器都無(wú)法提高系統(tǒng)的處理能力，這是系統(tǒng)往往會(huì)演進(jìn)到第二階段狂巢；

? ? 第二階段：微服務(wù)應(yīng)用撑毛，應(yīng)用和數(shù)據(jù)庫(kù)按照業(yè)務(wù)領(lǐng)域獨(dú)立部署，形成多個(gè)微服務(wù)應(yīng)用集群唧领。該階段一定程度上緩解了系統(tǒng)壓力藻雌，能夠提供更好的性能；同時(shí)斩个，各微服務(wù)應(yīng)用之間相互獨(dú)立部署胯杭，在交付周期和故障隔離方面能夠提供更高的靈活性。但是受啥，每個(gè)微服務(wù)應(yīng)用由于還是使用單一數(shù)據(jù)集群做个，在系統(tǒng)的容量、高并發(fā)等方面，存在著無(wú)法逾越的瓶頸叁温；

? ? 第三階段：數(shù)據(jù)分布式再悼，領(lǐng)域數(shù)據(jù)庫(kù)進(jìn)行分庫(kù)分表或者讀寫(xiě)分離，在數(shù)據(jù)庫(kù)層面提供水平擴(kuò)展能力膝但〕寰牛基于數(shù)據(jù)的分布式，可以有效的解決數(shù)據(jù)庫(kù)瓶頸問(wèn)題跟束，讓系統(tǒng)處理能力形成進(jìn)一步的提升莺奸；但是，面對(duì)數(shù)據(jù)庫(kù)連接數(shù)限制的問(wèn)題冀宴，在擴(kuò)展到一定規(guī)模之后灭贷，單純的分庫(kù)分表或讀寫(xiě)分離也會(huì)遇到擴(kuò)容瓶頸，這時(shí)候就需要邏輯數(shù)據(jù)中心（LDC）閃亮登場(chǎng)了略贮。

3.2.2 基于邏輯數(shù)據(jù)中心（LDC）實(shí)現(xiàn)數(shù)據(jù)庫(kù)無(wú)限擴(kuò)展

? ? 通過(guò)采用邏輯數(shù)據(jù)中心架構(gòu)甚疟，可以實(shí)現(xiàn)分布式系統(tǒng)容量的無(wú)線擴(kuò)容，同時(shí)保持恒定的交易響應(yīng)時(shí)間逃延。

? ? 邏輯數(shù)據(jù)中心的含義是：對(duì)物理數(shù)據(jù)中心進(jìn)行邏輯上的劃分览妖，每個(gè)邏輯數(shù)據(jù)中心相互獨(dú)立；每個(gè)邏輯數(shù)據(jù)中心部署相同的應(yīng)用揽祥，但應(yīng)用數(shù)據(jù)庫(kù)通過(guò)分庫(kù)分表之后均勻分布在每個(gè)邏輯數(shù)據(jù)中心中讽膏；每個(gè)客戶交易請(qǐng)求只會(huì)在一個(gè)邏輯數(shù)據(jù)中心內(nèi)處理。由于每個(gè)邏輯數(shù)據(jù)中心里可以穩(wěn)定支撐固定數(shù)量的客戶交易請(qǐng)求拄丰，當(dāng)系統(tǒng)容量達(dá)到上限時(shí)府树，可以通過(guò)增加新的邏輯分區(qū)實(shí)現(xiàn)系統(tǒng)容量的提升，滿足更大的數(shù)據(jù)量料按、更高的并發(fā)量奄侠。

? ? 以同城兩個(gè)數(shù)據(jù)中心為例，每個(gè)數(shù)據(jù)中心再在邏輯上劃分為兩個(gè)數(shù)據(jù)中心站绪，這樣我們就有4個(gè)邏輯數(shù)據(jù)中心遭铺，這樣我們就得到一個(gè)典型的基于邏輯數(shù)據(jù)中心的同城雙活架構(gòu)圖：

? ? ? ? 從橫向上來(lái)看，該架構(gòu)主要包含了以下幾層：

? ? 接入層：該層橫跨兩個(gè)數(shù)據(jù)中心恢准，部署路由應(yīng)用魂挂，負(fù)責(zé)服務(wù)請(qǐng)求的分發(fā)。網(wǎng)關(guān)應(yīng)用通過(guò)解析服務(wù)請(qǐng)求報(bào)文馁筐，根據(jù)路由規(guī)則確定該請(qǐng)求該路由至哪個(gè)邏輯數(shù)據(jù)中心涂召；

? ? 應(yīng)用層：每個(gè)邏輯數(shù)據(jù)中心部署相同的核心應(yīng)用集群，每個(gè)集群只連接本邏輯數(shù)據(jù)中心的數(shù)據(jù)庫(kù)敏沉；

? ? 數(shù)據(jù)層：對(duì)數(shù)據(jù)按客戶進(jìn)行分庫(kù)分表處理果正，平均分為4份炎码；每個(gè)邏輯數(shù)據(jù)中心只存儲(chǔ)其中的1份。最終在物理部署上秋泳，可以在邏輯數(shù)據(jù)中心之間進(jìn)行跨機(jī)房熱備潦闲，進(jìn)行數(shù)據(jù)庫(kù)層面高可用部署。

? ? 從縱向來(lái)看迫皱，每個(gè)分區(qū)單元都是獨(dú)立自包含的歉闰，按照分區(qū)規(guī)則服務(wù)固定的客戶；當(dāng)某個(gè)分區(qū)出現(xiàn)故障時(shí)卓起，只有該分區(qū)的客戶交易會(huì)受到影響和敬，其它分區(qū)可以正常工作，這也在一定程度上提高了系統(tǒng)的可用性和業(yè)務(wù)連續(xù)性戏阅。

3.3 從彈性到韌性昼弟，提供自愈能力

? ? 高可用IT系統(tǒng)，我們希望它具有良好的韌性奕筐，通俗講就是具有魯棒性舱痘，而非一碰就倒的花瓶、需要精心維護(hù)救欧。

3.3.1 面向高可用的兩個(gè)設(shè)計(jì)原則

? ? ? ? 設(shè)計(jì)一個(gè)韌性的系統(tǒng)衰粹，通常遵循以下兩方面的設(shè)計(jì)原則：

? ? ? ? 面向失敗設(shè)計(jì)：充分考慮分布式微服務(wù)架構(gòu)下會(huì)存在的各類故障锣光，針對(duì)故障進(jìn)行針對(duì)性的設(shè)計(jì)笆怠；進(jìn)行故障測(cè)試，系統(tǒng)是否具備應(yīng)對(duì)故障的能力誊爹。這樣蹬刷，當(dāng)故障真正發(fā)生時(shí)，才能從容應(yīng)對(duì)频丘，避免造成嚴(yán)重影響办成；

? ? ? ? 面向恢復(fù)設(shè)計(jì)：充分考慮系統(tǒng)中應(yīng)用節(jié)點(diǎn)出現(xiàn)宕機(jī)等不可用情況時(shí)，能夠及時(shí)發(fā)現(xiàn)并自動(dòng)恢復(fù)搂漠。這里講的恢復(fù)既包括集群中應(yīng)用節(jié)點(diǎn)宕機(jī)之后的重新啟動(dòng)迂卢，也包括對(duì)宕機(jī)應(yīng)用處理中的業(yè)務(wù)的自動(dòng)恢復(fù)。

3.3.2 面向失敗設(shè)計(jì)

? ? ? ? 應(yīng)用運(yùn)行中會(huì)遇到各種各樣不可預(yù)期的故障桐汤，從大的設(shè)計(jì)方向來(lái)說(shuō)而克，可以分為單點(diǎn)故障和級(jí)聯(lián)故障（中間件和數(shù)據(jù)庫(kù)的高可用方案不在本次討論范圍）。

? ? 故障大類分類具體類型應(yīng)對(duì)策略

? ? 針對(duì)分布式架構(gòu)幾類有效的面向失敗設(shè)計(jì)方法怔毛，主要包括以下幾點(diǎn)：

3.3.3 面向恢復(fù)設(shè)計(jì)

? ? ? ? 雖然進(jìn)行了針對(duì)性的面向失敗設(shè)計(jì)员萍，但是故障是不可避免的。在分布式環(huán)境下拣度，存在著大量的遠(yuǎn)程調(diào)用和分布式事務(wù)碎绎，任何一個(gè)節(jié)點(diǎn)的故障都會(huì)帶來(lái)連鎖反應(yīng)螃壤。在進(jìn)行應(yīng)用設(shè)計(jì)、各種組件設(shè)計(jì)時(shí)筋帖，通過(guò)考慮自動(dòng)恢復(fù)設(shè)計(jì)可以為系統(tǒng)提供自愈能力奸晴，從而更好提高系統(tǒng)可用性。

? ? ? ? 有以下幾類場(chǎng)景日麸，可以幫助我們更好的理解自動(dòng)恢復(fù)的必要性：

? ? ? ? 應(yīng)用存在分布式事務(wù)：例如一個(gè)業(yè)務(wù)處理過(guò)程中蚁滋，需要調(diào)用數(shù)據(jù)庫(kù)創(chuàng)建訂單，同時(shí)需要調(diào)用消息中間件創(chuàng)建物流消息赘淮。在不使用傳統(tǒng)XA事務(wù)機(jī)制的方式下辕录，如何保證應(yīng)用宕機(jī)時(shí)，創(chuàng)建成功訂單梢卸、未發(fā)送的消息最終能夠發(fā)送成功走诞；

? ? ? ? 應(yīng)用存在主從調(diào)度機(jī)制：應(yīng)用集群中的主節(jié)點(diǎn)負(fù)責(zé)調(diào)度，其他節(jié)點(diǎn)作為從節(jié)點(diǎn)被調(diào)度負(fù)責(zé)具體任務(wù)的執(zhí)行蛤高。主節(jié)點(diǎn)故障時(shí)蚣旱，如何自動(dòng)恢復(fù)尋找新的主節(jié)點(diǎn)繼續(xù)進(jìn)行調(diào)度；從節(jié)點(diǎn)故障時(shí)戴陡，如何接管正在該節(jié)點(diǎn)執(zhí)行的任務(wù)塞绿；

? ? ? ? 數(shù)據(jù)庫(kù)采用主從模式部署：例如mysql主從部署，主節(jié)點(diǎn)故障時(shí)如何自動(dòng)切換到從節(jié)點(diǎn)恤批。

? ? ? ? 如何實(shí)現(xiàn)自動(dòng)恢復(fù)异吻，涉及到以下兩個(gè)關(guān)鍵點(diǎn)：

? ? ? ? ? 故障自動(dòng)感知：自動(dòng)識(shí)別故障節(jié)點(diǎn)或應(yīng)用。例如喜庞，對(duì)于分布式事務(wù)诀浪，需要能夠識(shí)別出已經(jīng)中斷的事務(wù)（而非執(zhí)行中的事務(wù)）；主從調(diào)度類應(yīng)用延都，能夠自動(dòng)識(shí)別出主從節(jié)點(diǎn)的可用性雷猪；對(duì)于主從模式數(shù)據(jù)庫(kù)，能夠及時(shí)識(shí)別主庫(kù)是否可以正常提供服務(wù)晰房；

? ? ? ? 故障自動(dòng)恢復(fù)：自動(dòng)對(duì)發(fā)生的故障進(jìn)行恢復(fù)求摇。例如，對(duì)于分布式事務(wù)殊者，自動(dòng)按照預(yù)設(shè)的模式進(jìn)行補(bǔ)償或回滾与境；主從調(diào)度類應(yīng)用，主節(jié)點(diǎn)自動(dòng)選擇新的主節(jié)點(diǎn)并接管調(diào)度幽污，從節(jié)點(diǎn)故障由新從節(jié)點(diǎn)自動(dòng)接管其未完成任務(wù)嚷辅；對(duì)于主從模式數(shù)據(jù)庫(kù)，自動(dòng)進(jìn)行切換讓從節(jié)點(diǎn)變?yōu)橹鞴?jié)點(diǎn)繼續(xù)提供服務(wù)距误。

針對(duì)兩個(gè)關(guān)鍵點(diǎn)簸搞，應(yīng)用系統(tǒng)運(yùn)行過(guò)程中其實(shí)必須要提供兩種角色：故障識(shí)別角色與故障恢復(fù)角色扁位。兩種角色可以是由同一個(gè)技術(shù)組件實(shí)現(xiàn)，也可以是獨(dú)立的實(shí)現(xiàn)趁俊；物理部署上可以是獨(dú)立于應(yīng)用外部署的管理角色域仇，也可以讓?xiě)?yīng)用集群中的任意應(yīng)用節(jié)點(diǎn)具備這兩種角色。

3.3.4 實(shí)際案例

3.3.4.1 MQ消息發(fā)送與消費(fèi)高可用

3.3.4.1.1 業(yè)務(wù)場(chǎng)景需求

? ? ? ? 之前到一個(gè)業(yè)務(wù)場(chǎng)景寺擂，訂單應(yīng)用調(diào)用數(shù)據(jù)庫(kù)創(chuàng)建訂單的同時(shí)暇务，需要調(diào)用消息中間件創(chuàng)建物流消息；物流應(yīng)用對(duì)消息消費(fèi)以生成物流單怔软。該場(chǎng)景的高可用有以下兩方面的要求：

? ? ? ? 數(shù)據(jù)庫(kù)訂單創(chuàng)建成功垦细，物流消息必須通過(guò)MQ發(fā)送成功；

? ? ? ? 物流消息的消費(fèi)挡逼，有且只能有一次括改，避免重復(fù)消費(fèi)。

? ? ? ? 在設(shè)計(jì)過(guò)程中家坎，需要充分考慮面向故障與恢復(fù)設(shè)計(jì)嘱能，例如訂單應(yīng)用節(jié)點(diǎn)宕機(jī)、消息服務(wù)器不可用虱疏、物流應(yīng)用節(jié)點(diǎn)宕機(jī)等各種故障可能性惹骂。

3.3.4.1.2 高可用方案

? ? ? ? 為了確保消息發(fā)送與消費(fèi)的高可用，需要用到面向故障設(shè)計(jì)里的“數(shù)據(jù)庫(kù)事務(wù)”做瞪、“重試”與“冪等性”等方法对粪。

? ? ? ? 方案中MQ（消息）客戶端有兩個(gè)角色：“MQ發(fā)送客戶端”和“MQ消費(fèi)客戶端”；具體實(shí)現(xiàn)方式可參考下圖穿扳。

? ? 消息發(fā)送高可用設(shè)計(jì)關(guān)鍵點(diǎn)衩侥，是采用“共享事務(wù)設(shè)計(jì)模式”和“重試”，確保消息一定發(fā)送成功：

? ? 1. 在訂單創(chuàng)建的數(shù)據(jù)庫(kù)事務(wù)中矛物，同時(shí)往附加“消息表”中插入一條“待發(fā)送消息”記錄；

? ? 2. 數(shù)據(jù)庫(kù)事務(wù)完成后跪但，MQ發(fā)送客戶端會(huì)讀取到“消息表”中的“待發(fā)送消息”履羞，發(fā)送給MQ之后修改狀態(tài)為“已發(fā)送”；

? ? 3. “MQ發(fā)送客戶端”可以與“訂單應(yīng)用”打包部署屡久，也可以獨(dú)立部署忆首；打包部署的好處是當(dāng)一個(gè)“訂單應(yīng)用”宕機(jī)之后，集群中的其它應(yīng)用中的“MQ發(fā)送客戶端”同樣可以完成消息的發(fā)送被环；獨(dú)立部署則需要實(shí)現(xiàn)“MQ發(fā)送客戶端”的集群高可用糙及。

? 消息消費(fèi)高可用設(shè)計(jì)關(guān)鍵點(diǎn)，是采用“冪等性”確保消息消費(fèi)不會(huì)重復(fù)：

? ? 1. 在進(jìn)行消息消費(fèi)時(shí)筛欢，需要基于“冪等性”確保消息消費(fèi)且只消費(fèi)一次浸锨，避免重復(fù)消費(fèi)帶來(lái)的不可預(yù)期問(wèn)題唇聘；

? ? 2. 具體實(shí)現(xiàn)方式可以通過(guò)“消息消費(fèi)表”使用“消息ID”作為主鍵，每次消費(fèi)消息前先往該表中插入一條記錄來(lái)實(shí)現(xiàn)冪等性柱搜。如果消息消費(fèi)成功了迟郎，回調(diào)MQ消息中心失敗該如何處理呢？各位同學(xué)可以自己想想聪蘸，解決起來(lái)也不難宪肖。

3.3.4.2 K8s副本機(jī)制

? ? 我們?cè)倏匆粋€(gè)大家都很熟悉的高可用案例——K8s中通過(guò)副本機(jī)制(replication controller)，確保應(yīng)用Pod崩潰時(shí)能夠自動(dòng)恢復(fù)健爬，確保維持預(yù)設(shè)數(shù)量以提供足夠的系統(tǒng)處理能力控乾。

? ? 在k8s中，Controller擔(dān)當(dāng)了故障識(shí)別與恢復(fù)的角色娜遵。

? ? 回到面向恢復(fù)設(shè)計(jì)的兩個(gè)關(guān)鍵點(diǎn)：故障自動(dòng)感知阱持、故障自動(dòng)恢復(fù)，簡(jiǎn)單探究一下K8s是怎么實(shí)現(xiàn)的魔熏。

3.3.4.2.1 故障自動(dòng)感知

? ? ? ? k8s通過(guò)liveness（存活探針）來(lái)確定Pod是否還可提供服務(wù)衷咽，如果探活結(jié)果最終判定是失敗，則會(huì)重啟容器蒜绽。需要注意的是镶骗，故障結(jié)果的判定是通過(guò)多次探活失敗來(lái)確定的，不能通過(guò)一次簡(jiǎn)單的探活失敗就認(rèn)為Pod故障躲雅，否則極易受網(wǎng)絡(luò)延時(shí)鼎姊、閃斷等因素影響。

? ? ? ? Liveness探針的一個(gè)簡(jiǎn)單示例如下：

? ? ? ? livenessProbe 指定kubelete需要每隔3秒執(zhí)行一次liveness probe相赁。initialDelaySeconds 指定kubelet在該執(zhí)行第一次探測(cè)之前需要等待3秒鐘相寇。該探針將向容器中的server的8080端口發(fā)送一個(gè)HTTP GET請(qǐng)求。如果server的/health路徑的handler返回一個(gè)成功的返回碼钮科，kubelet就會(huì)認(rèn)定該容器是活著的并且很健康唤衫。如果返回失敗的返回碼，kubelet將殺掉該容器并重啟它绵脯。

? ? ? ? LivenessProbe還有很多參數(shù)用于幫助確定故障發(fā)生佳励，例如timeoutSeconds，successThreshold蛆挫，failureThreshold等赃承，在此就不展開(kāi)描述了。

3.3.4.2.2 故障自動(dòng)恢復(fù)

? ? ? ? 在k8s中悴侵，通過(guò)各種類型的Controller來(lái)確保Pod始終維持預(yù)設(shè)的數(shù)量瞧剖，從而實(shí)現(xiàn)自動(dòng)恢復(fù)。

? ? ? ? 以Deployment類型的Controller為例，一個(gè)典型的定義方式如下：

? ? ? ? 示例代碼中抓于，定義了一個(gè)nginx應(yīng)用的部署做粤，“replicas: 3”明確描述了nginx集群的pod數(shù)量需要維持3個(gè)。當(dāng)集群中的一個(gè)pod發(fā)生故障（liveness檢查失斦庇健）驮宴，Controller會(huì)銷(xiāo)毀故障的pod，重新創(chuàng)建一個(gè)新的nginx應(yīng)用pod呕缭。

3.3.4.3 Mysql基于MHA的高可用

? ? ? ? MHA（Master HA）是一款開(kāi)源的 MySQL 的高可用程序堵泽，它為 MySQL 主從復(fù)制架構(gòu)提供了 automating master failover 功能。MHA 在監(jiān)控到 master 節(jié)點(diǎn)故障時(shí)恢总，會(huì)提升其中擁有最新數(shù)據(jù)的 slave 節(jié)點(diǎn)成為新的master 節(jié)點(diǎn)迎罗，在此期間，MHA 會(huì)通過(guò)于其它從節(jié)點(diǎn)獲取額外信息來(lái)避免一致性方面的問(wèn)題片仿。MHA 還提供了 master 節(jié)點(diǎn)的在線切換功能纹安，即按需切換 master/slave 節(jié)點(diǎn)。

3.3.4.3.1 MHA角色

? ? ? ? MHA 服務(wù)有兩種角色砂豌， MHA Manager(管理節(jié)點(diǎn))和 MHA Node(數(shù)據(jù)節(jié)點(diǎn))：

? ? ? ? MHA Manager：通常單獨(dú)部署在一臺(tái)獨(dú)立機(jī)器上管理多個(gè) master/slave 集群(組)厢岂，每個(gè) master/slave 集群稱作一個(gè) application，用來(lái)管理統(tǒng)籌整個(gè)集群阳距。

? ? ? ? MHA node：運(yùn)行在每臺(tái) MySQL 服務(wù)器上(master/slave)塔粒，它通過(guò)監(jiān)控具備解析和清理 logs 功能的腳本來(lái)加快故障轉(zhuǎn)移。主要是接收管理節(jié)點(diǎn)所發(fā)出指令的代理筐摘，代理需要運(yùn)行在每一個(gè) mysql 節(jié)點(diǎn)上卒茬。簡(jiǎn)單講 node 就是用來(lái)收集從節(jié)點(diǎn)服務(wù)器上所生成的 bin-log 。對(duì)比打算提升為新的主節(jié)點(diǎn)之上的從節(jié)點(diǎn)的是否擁有并完成操作咖熟，如果沒(méi)有發(fā)給新主節(jié)點(diǎn)在本地應(yīng)用后提升為主節(jié)點(diǎn)圃酵。

3.3.4.3.2 高可用原理

? ? ? ? MySQL復(fù)制集群中的master故障時(shí)，MHA按如下步驟進(jìn)行故障轉(zhuǎn)移：

? ? ? ? -從宕機(jī)崩潰的master保存二進(jìn)制日志事件(binlogevents)馍管。

? ? ? ? -識(shí)別含有最新更新的slave郭赐。

? ? ? ? -應(yīng)用差異的中繼日志(relay log)到其它slave。

? ? ? ? -應(yīng)用從master保存的二進(jìn)制日志事件(binlogevents)咽斧。

? ? ? ? -提升一個(gè)slave為新master堪置。

? ? ? ? -使其它的slave連接新的master進(jìn)行復(fù)制。

4 驗(yàn)證分布式系統(tǒng)的可用性

? ? ? ? 到目前為止张惹，我們的分布式系統(tǒng)已經(jīng)完成優(yōu)秀的設(shè)計(jì)和開(kāi)發(fā)，進(jìn)入到了PDCA環(huán)的Check（驗(yàn)證）環(huán)節(jié)岭洲。如何對(duì)一個(gè)系統(tǒng)的可用性進(jìn)行驗(yàn)證宛逗，目前主流的思路和技術(shù)方向是逐漸流行起來(lái)的混沌工程，眾多大廠都紛紛在談自己的混沌工程實(shí)踐盾剩，也有很多優(yōu)秀的開(kāi)源軟件（如chaosblade）可以供我們使用雷激。如何使用混沌工程來(lái)驗(yàn)證我們系統(tǒng)的可用性替蔬，是我們本節(jié)要討論的內(nèi)容。

4.1 混沌工程定義與起源

? ? ? ? 混沌工程是在分布式系統(tǒng)上進(jìn)行實(shí)驗(yàn)的學(xué)科? , 目的是建立對(duì)系統(tǒng)抵御生產(chǎn)環(huán)境中失控條件的能力以及信心屎暇。

? ? ? ? 這里邊有一個(gè)關(guān)鍵字——“實(shí)驗(yàn)”承桥。混沌工程圍繞“實(shí)驗(yàn)”展開(kāi)：通過(guò)有計(jì)劃的實(shí)驗(yàn)發(fā)現(xiàn)系統(tǒng)的故障點(diǎn)根悼，觀測(cè)故障發(fā)生時(shí)系統(tǒng)的表現(xiàn)，針對(duì)故障點(diǎn)進(jìn)行修復(fù)或提供應(yīng)急預(yù)案，避免在故障出現(xiàn)時(shí)系統(tǒng)崩潰法瑟，從而提升系統(tǒng)韌性盛末，提升對(duì)系統(tǒng)可用性的信息。

? ? ? ? 混沌工程在2019年突然火了起來(lái)矿卑，然而喉恋，混沌工程的起源可以追溯到2008年，以下為混沌工程在Netflix的發(fā)展歷史：

? ? ? ? 2008年8月母廷， Netflix 主要數(shù)據(jù)庫(kù)的故障導(dǎo)致了三天的停機(jī)轻黑， DVD 租賃業(yè)務(wù)中斷，多個(gè)國(guó)家的大量用戶受此影響琴昆。之后 Netflix 工程師著手尋找替代架構(gòu)氓鄙，并在2011年起，逐步將系統(tǒng)遷移到 AWS 上椎咧，運(yùn)行基于微服務(wù)的新型分布式架構(gòu)玖详。這種架構(gòu)消除了單點(diǎn)故障，但也引入了新的復(fù)雜性類型勤讽，需要更加可靠和容錯(cuò)的系統(tǒng)蟋座。為此， Netflix 工程師創(chuàng)建了 Chaos Monkey 脚牍，會(huì)隨機(jī)終止在生產(chǎn)環(huán)境中運(yùn)行的 EC2 實(shí)例向臀。工程師可以快速了解他們正在構(gòu)建的服務(wù)是否健壯，有足夠的彈性诸狭，可以容忍計(jì)劃外的故障券膀。至此，混沌工程開(kāi)始興起驯遇；

? ? ? ? 2010年 Netflix 內(nèi)部開(kāi)發(fā)了 AWS 云上隨機(jī)終止 EC2 實(shí)例的混沌實(shí)驗(yàn)工具：Chaos Monkey芹彬；

? ? ? ? 2011年 Netflix release了其猴子軍團(tuán)工具集：Simian Army；

? ? ? ? 2012年 Netflix 向社區(qū)開(kāi)源由 Java 構(gòu)建 Simian Army叉庐，其中包括 Chaos Monkey V1 版本舒帮；

? ? ? ? 2014年 Netflix 開(kāi)始正式公開(kāi)招聘 Chaos Engineer；

? ? ? ? 2014年 Netflix 提出了故障注入測(cè)試（FIT），利用微服務(wù)架構(gòu)的特性玩郊，控制混沌實(shí)驗(yàn)的爆炸半徑肢执；

? ? ? ? 2015年 Netflix release了 Chaos Kong ，模擬AWS區(qū)域（Region）中斷的場(chǎng)景译红；

? ? ? ? 2015年 Netflix 和社區(qū)正式提出混沌工程的指導(dǎo)思想 – Principles of Chaos Engineering

? ? ? ? 2016年 Kolton Andrus（前 Netflix 和 Amazon Chaos Engineer ）創(chuàng)立了 Gremlin 预茄，正式將混沌實(shí)驗(yàn)工具商用化；

? ? ? ? 2017年 Netflix 開(kāi)源 Chaos Monkey 由 Golang 重構(gòu)的 V2 版本侦厚，必須集成 CD 工具 Spinnaker（持續(xù)發(fā)布平臺(tái)）來(lái)使用耻陕；

? ? ? ? 2017年 Netflix release了 ChAP （Chaos Automation Platform, 混沌實(shí)驗(yàn)自動(dòng)平臺(tái)），可視為應(yīng)用故障注入測(cè)試（FIT）的加強(qiáng)版假夺；

? ? ? ? 2017年 由Netflix 前混沌工程師撰寫(xiě)的新書(shū)“混沌工程”在網(wǎng)上出版淮蜈；

? ? ? ? 2017年 Russell Miles 創(chuàng)立了 ChaosIQ 公司，并開(kāi)源了 chaostoolkit 混沌實(shí)驗(yàn)框架已卷。

? ? ? ? 而在2019年梧田，阿里開(kāi)源了自己的混沌工程工具（ChaosBlade），讓我們可以看到混沌工程在阿里內(nèi)部的發(fā)展史：

? ? ? ? EOS（2012-2015）：故障演練平臺(tái)的早期版本侧蘸，故障注入能力通過(guò)字節(jié)碼增強(qiáng)方式實(shí)現(xiàn)裁眯，模擬常見(jiàn)的 RPC 故障，解決微服務(wù)的強(qiáng)弱依賴治理問(wèn)題讳癌。

? ? ? ? MonkeyKing（2016-2018）：故障演練平臺(tái)的升級(jí)版本穿稳，豐富了故障場(chǎng)景（如：資源、容器層場(chǎng)景）晌坤，開(kāi)始在生產(chǎn)環(huán)境進(jìn)行一些規(guī)姆晁遥化的演練。

? ? ? ? AHAS（2018.9-至今）：阿里云應(yīng)用高可用服務(wù)骤菠，內(nèi)置演練平臺(tái)的全部功能它改，支持可編排演練、演練插件擴(kuò)展等能力商乎，并整合了架構(gòu)感知和限流降級(jí)的功能央拖。

? ? ? ? ChaosBlade（2019.3）：是 MonkeyKing 平臺(tái)底層故障注入的實(shí)現(xiàn)工具，通過(guò)對(duì)演練平臺(tái)底層的故障注入能力進(jìn)行抽象鹉戚，定義了一套故障模型鲜戒。配合用戶友好的 CLI 工具進(jìn)行開(kāi)源，幫助云原生用戶進(jìn)行混沌工程測(cè)試抹凳。

4.2 阿里開(kāi)源混沌工具(ChaosBlade)

? ? ? ? ChaosBlade 是阿里巴巴開(kāi)源的一款遵循混沌工程原理和混沌實(shí)驗(yàn)?zāi)Ｐ偷膶?shí)驗(yàn)注入工具遏餐，幫助企業(yè)提升分布式系統(tǒng)的容錯(cuò)能力，并且在企業(yè)上云或往云原生系統(tǒng)遷移過(guò)程中業(yè)務(wù)連續(xù)性保障赢底。

? ? ? ? Chaosblade 是內(nèi)部 MonkeyKing 對(duì)外開(kāi)源的項(xiàng)目境输，其建立在阿里巴巴近十年故障測(cè)試和演練實(shí)踐基礎(chǔ)上蔗牡，結(jié)合了集團(tuán)各業(yè)務(wù)的最佳創(chuàng)意和實(shí)踐颖系。

? ? ? ? ChaosBlade官網(wǎng)：https://github.com/chaosblade-io/chaosblade

4.3 通過(guò)混沌實(shí)驗(yàn)驗(yàn)證系統(tǒng)可用性

? ? ? ? 在面向故障設(shè)計(jì)設(shè)計(jì)的內(nèi)容中嗅剖，提到了很多種不同類型的故障。針對(duì)這些故障嘁扼，我們可以混沌實(shí)驗(yàn)來(lái)對(duì)其進(jìn)行模擬信粮，通過(guò)APM（應(yīng)用性能管理）工具監(jiān)測(cè)故障發(fā)生時(shí)的系統(tǒng)運(yùn)行情況，從而采取相應(yīng)的處理策略趁啸。

4.3.1 混沌實(shí)驗(yàn)?zāi)Ｐ?/b>

? ? ? ? 以阿里開(kāi)源的混沌工程工具ChaosBlade為例强缘，我們可以從直觀的感覺(jué)上了解到什么是混沌實(shí)驗(yàn)、混沌實(shí)驗(yàn)?zāi)軒椭植际较到y(tǒng)做哪些故障模擬不傅。以下內(nèi)容來(lái)自ChoasBalde對(duì)混沌實(shí)驗(yàn)的介紹：

? ? ? ? 對(duì)什么做混沌實(shí)驗(yàn)旅掂？

? ? ? ? 混沌實(shí)驗(yàn)實(shí)施的范圍是是什么？

? ? ? ? 具體實(shí)施什么實(shí)驗(yàn)访娶？

? ? ? ? 實(shí)驗(yàn)生效的匹配條件有哪些商虐？

? ? ? ? 舉個(gè)例子：一臺(tái) ip 是 10.0.0.1 機(jī)器上的應(yīng)用，調(diào)用? com.example.HelloService@1.0.0 Dubbo 服務(wù)延遲 3s崖疤。

明確以上內(nèi)容秘车，就可以精準(zhǔn)的實(shí)施一次混沌實(shí)驗(yàn)，抽象出以下模型(ChaosBlade混沌實(shí)驗(yàn)?zāi)Ｐ?：

? ? ? ? 1.Target：實(shí)驗(yàn)靶點(diǎn)劫哼，指實(shí)驗(yàn)發(fā)生的組件叮趴，例如 容器、應(yīng)用框架（Dubbo权烧、Redis眯亦、Zookeeper）等；

? ? ? ? 2.Scope：實(shí)驗(yàn)實(shí)施的范圍般码，指具體觸發(fā)實(shí)驗(yàn)的機(jī)器或者集群等妻率；

? ? ? ? 3.Matcher：實(shí)驗(yàn)規(guī)則匹配器，根據(jù)所配置的? Target侈询，定義相關(guān)的實(shí)驗(yàn)匹配規(guī)則舌涨，可以配置多個(gè)。由于每個(gè) Target 可能有各自特殊的匹配條件扔字，比如 RPC 領(lǐng)域的 HSF囊嘉、Dubbo，可以根據(jù)服務(wù)提供者提供的服務(wù)和服務(wù)消費(fèi)者調(diào)用的服務(wù)進(jìn)行匹配革为，緩存領(lǐng)域的 Redis扭粱，可以根據(jù) set、get 操作進(jìn)行匹配震檩；

? ? ? ? 4.Action：指實(shí)驗(yàn)?zāi)M的具體場(chǎng)景琢蛤，Target 不同蜓堕，實(shí)施的場(chǎng)景也不一樣，比如磁盤(pán)博其，可以演練磁盤(pán)滿套才，磁盤(pán) IO 讀寫(xiě)高，磁盤(pán)硬件故障等慕淡。如果是應(yīng)用背伴，可以抽象出延遲、異常峰髓、返回指定值（錯(cuò)誤碼傻寂、大對(duì)象等）、參數(shù)篡改携兵、重復(fù)調(diào)用等實(shí)驗(yàn)場(chǎng)景疾掰。

? ? ? ? 還以如下dubbo超時(shí)為例：Targe實(shí)驗(yàn)組件就是“dubbo”，Scope范圍就是“10.0.0.1”這臺(tái)機(jī)器徐紧，Matcher規(guī)則匹配器為dubbo服務(wù)“com.example.HelloService@1.0.0”静檬，Action具體場(chǎng)景為“調(diào)用延時(shí)3秒”。

4.3.2 混沌實(shí)驗(yàn)場(chǎng)景

? ? ? ? 以Chaosblade為例浪汪，目前支持的混沌實(shí)驗(yàn)種類如下巴柿，基本上能夠滿足我們絕大多數(shù)的實(shí)驗(yàn)需求。同時(shí)死遭，ChaosBlode還在持續(xù)更新：

? ? ? ? 基礎(chǔ)資源：比如 CPU广恢、內(nèi)存、網(wǎng)絡(luò)呀潭、磁盤(pán)钉迷、進(jìn)程等實(shí)驗(yàn)場(chǎng)景；

? ? ? ? Java 應(yīng)用：比如數(shù)據(jù)庫(kù)钠署、緩存糠聪、消息、JVM 本身谐鼎、微服務(wù)等舰蟆，還可以指定任意類方法注入各種復(fù)雜的實(shí)驗(yàn)場(chǎng)景；

? ? ? ? C++ 應(yīng)用：比如指定任意方法或某行代碼注入延遲狸棍、變量和返回值篡改等實(shí)驗(yàn)場(chǎng)景身害；

? ? ? ? Docker 容器：比如殺容器、容器內(nèi) CPU草戈、內(nèi)存塌鸯、網(wǎng)絡(luò)、磁盤(pán)唐片、進(jìn)程等實(shí)驗(yàn)場(chǎng)景丙猬；

? ? ? ? 云原生平臺(tái)：比如 Kubernetes 平臺(tái)節(jié)點(diǎn)上 CPU涨颜、內(nèi)存、網(wǎng)絡(luò)茧球、磁盤(pán)庭瑰、進(jìn)程實(shí)驗(yàn)場(chǎng)景，Pod 網(wǎng)絡(luò)和 Pod 本身實(shí)驗(yàn)場(chǎng)景如殺 Pod袜腥，容器的實(shí)驗(yàn)場(chǎng)景如上述的 Docker 容器實(shí)驗(yàn)場(chǎng)景见擦。

4.4 混沌實(shí)驗(yàn)平臺(tái)

? ? ? ? ChaosBlade提供了豐富的混沌實(shí)驗(yàn)場(chǎng)景，但是目前還是作為一個(gè)命令行工具直接在實(shí)驗(yàn)節(jié)點(diǎn)上運(yùn)行羹令；雖然也提供了httpserver可以對(duì)外提供restful服務(wù)，然而還沒(méi)有配套的可視化Web應(yīng)用與其集成损痰。如果需要在企業(yè)內(nèi)部搭建一個(gè)混沌實(shí)驗(yàn)平臺(tái)福侈，可以參考阿里云的AHAS（應(yīng)用高可用服務(wù)）。

? ? ? ? 在筆者看來(lái)卢未，搭建一個(gè)混沌實(shí)驗(yàn)平臺(tái)肪凛，可以基于最小可行化產(chǎn)品(MVP)方式，圍繞ChaosBlade快速建設(shè)一套Web可視化平臺(tái)辽社，同時(shí)與現(xiàn)有APM（應(yīng)用性能管理）平臺(tái)進(jìn)行集成伟墙，既可形成一套支撐混沌實(shí)驗(yàn)從準(zhǔn)備、運(yùn)行到監(jiān)控的全流程管理滴铅。

? ? ? ? 以下是一個(gè)簡(jiǎn)單的混沌實(shí)驗(yàn)平臺(tái)功能架構(gòu)圖：

? ? ? ? 混沌實(shí)驗(yàn)平臺(tái)：負(fù)責(zé)管理實(shí)驗(yàn)范圍(節(jié)點(diǎn))戳葵、實(shí)驗(yàn)支持的場(chǎng)景，完成實(shí)驗(yàn)準(zhǔn)備汉匙，執(zhí)行實(shí)驗(yàn)運(yùn)行拱烁；

? ? ? ? ChaosBlade：負(fù)責(zé)具體實(shí)驗(yàn)執(zhí)行。以代理（agent）部署在虛擬機(jī)噩翠、物理機(jī)或k8s集群的node上戏自；以sidecar方式部署在k8s的pod中；

? ? ? ? APM：提供對(duì)實(shí)驗(yàn)過(guò)程中對(duì)系統(tǒng)高可用情況的監(jiān)控伤锚，以驗(yàn)證系統(tǒng)是否在故障發(fā)生時(shí)能夠從容應(yīng)對(duì)擅笔。

5 結(jié)束語(yǔ)

? ? ? ? 面對(duì)越來(lái)越復(fù)雜的分布式甚或多云環(huán)境，開(kāi)發(fā)運(yùn)維的難度在越來(lái)越大屯援，而對(duì)系統(tǒng)高可用的要求卻是越來(lái)越高猛们。

? ? ? ? 善用國(guó)內(nèi)大廠積累的經(jīng)驗(yàn)、善用各種開(kāi)源工具玄呛，時(shí)刻保持對(duì)IT系統(tǒng)的敬畏阅懦，讓我們的系統(tǒng)可用性達(dá)到5個(gè)9、6個(gè)9及至9個(gè)9徘铝，用一顆匠心來(lái)打磨我們的分布式系統(tǒng)耳胎！

6 附錄

? ? ? ? 參考資料：

? ? ? ? 1.《干貨 | 阿里巴巴混沌測(cè)試工具ChaosBlade兩萬(wàn)字解讀》朱小廝https://blog.csdn.net/u013256816/java/article/details/99917021

? ? ? ? 2.ChaosBlade官網(wǎng)：https://github.com/chaosblade-io/chaosblade