分布式服务架构下的混沌工程实践
本文來自阿里巴巴高可用架構(gòu)團(tuán)隊高級開發(fā)工程師肖長軍(花名穹谷)在 GIAC(全球互聯(lián)網(wǎng)架構(gòu)大會)上的分享,包含三部分內(nèi)容:(阿里巴巴中間件公眾號對話框發(fā)送“混沌工程”,獲取分享PPT)
- 混沌工程的定義、價值、原則和流程;
- 混沌工程如何在企業(yè)中落地,以及 ChaosBlade 和混沌實(shí)驗(yàn)平臺 AHAS Chaos 架構(gòu)設(shè)計;
- 結(jié)合兩個具體案例介紹了分布式服務(wù)下的混沌工程實(shí)踐;
大家好,我是來自阿里的肖長軍,今天給大家分享混沌工程在分布式服務(wù)架構(gòu)下的具體實(shí)踐。
先做個自我介紹,我來自于阿里高可用架構(gòu)團(tuán)隊,花名穹谷,做過分布式系統(tǒng)設(shè)計和 APM 研發(fā)相關(guān)工作,現(xiàn)在專注于高可用架構(gòu)和混沌工程領(lǐng)域,是阿里云產(chǎn)品 AHAS 底層技術(shù)負(fù)責(zé)人和開源項(xiàng)目 ChaosBlade 負(fù)責(zé)人,并且承擔(dān)集團(tuán)內(nèi)故障演練、突襲演練、攻防演練相關(guān)的研發(fā)工作。今天分享的內(nèi)容包含以下三個方面。
先從混沌工程的定義、價值、原則和實(shí)施步驟介紹混沌工程,然后分享混沌工程如何在企業(yè)中落地,最后介紹分布式服務(wù)下混沌工程實(shí)踐案例。我們先來看一下什么是混沌工程。
混沌工程理論一文中提到,其是在分布式系統(tǒng)上進(jìn)行實(shí)驗(yàn)的學(xué)科,核心目的是提高生產(chǎn)環(huán)境中系統(tǒng)的容錯性和可恢復(fù)性。尼采的這句話: "打不倒我的必使我強(qiáng)大",也很好的詮釋了混沌工程反脆弱的思想。除了這里提到的目的,實(shí)施混沌工程還有哪些價值呢?
這里我從四個角色來說明,對于架構(gòu)師來說,可以驗(yàn)證系統(tǒng)架構(gòu)的容錯能力,比如驗(yàn)證現(xiàn)在提倡的面向失敗設(shè)計的系統(tǒng);對于開發(fā)和運(yùn)維,可以提高故障的應(yīng)急效率,實(shí)現(xiàn)故障告警、定位、恢復(fù)的有效和高效性。對于測試來說,可以彌補(bǔ)傳統(tǒng)測試方法留下的空白,之前的測試方法基本上是從用戶的角度去做,而混沌工程是從系統(tǒng)的角度進(jìn)行測試,降低故障復(fù)發(fā)率。對于產(chǎn)品和設(shè)計,通過混沌事件查看產(chǎn)品的表現(xiàn),提升客戶使用體驗(yàn)。所以說混沌工程面向的不僅僅是開發(fā)、測試,擁有最好的客戶體驗(yàn)是每個人的目標(biāo)。我們知道,系統(tǒng)發(fā)生故障的那一刻不是由你來選擇的,而是那一刻選擇你,你所能做,只能是為之做好準(zhǔn)備。了解了混沌工程的價值,我們再來看一下實(shí)施混沌工程的一些原則。
前面 Vilas 老師也提到了,我這里重點(diǎn)來介紹一下這五項(xiàng)原則。第一條:”建立一個圍繞穩(wěn)定狀態(tài)行為的假說“,其包含兩個含義,一個是定義能直接反應(yīng)業(yè)務(wù)服務(wù)的監(jiān)控指標(biāo),需要注意的是這里的監(jiān)控指標(biāo)并不是系統(tǒng)資源指標(biāo),比如CPU、內(nèi)存等,這里的監(jiān)控指標(biāo)是能直接衡量系統(tǒng)服務(wù)質(zhì)量的業(yè)務(wù)監(jiān)控。舉個例子,一個調(diào)用延遲故障,請求的 RT 會變長,對上層交易量造成下跌的影響,那么這里交易量就可以作為一個監(jiān)控指標(biāo)。這條原則的另一個含義是故障觸發(fā)時,對系統(tǒng)行為作出假設(shè)以及監(jiān)控指標(biāo)的預(yù)期變化。第二個指模擬生產(chǎn)環(huán)境中真實(shí)的或有理論依據(jù)的故障,第三個建議在生產(chǎn)環(huán)境中運(yùn)行實(shí)驗(yàn),但也不是說必須在生產(chǎn)環(huán)境中執(zhí)行,只是實(shí)驗(yàn)環(huán)境越真實(shí),混沌工程越有價值。持續(xù)的執(zhí)行才能持續(xù)的降低故障復(fù)發(fā)率和提前發(fā)現(xiàn)故障,所以需要持續(xù)的自動化運(yùn)行試驗(yàn),最后一個,混沌工程很重要的一點(diǎn)是控制爆炸半徑,也就是試驗(yàn)影響面,防止預(yù)期外的資損發(fā)生,后面會介紹控制爆炸半徑的方式。依據(jù)這些指導(dǎo)原則可以更有效實(shí)施混沌工程,那么混沌工程的實(shí)施步驟是什么?
主要細(xì)分為這 8 步,指定試驗(yàn)計劃,定義穩(wěn)態(tài)指標(biāo),做出系統(tǒng)容錯假設(shè),執(zhí)行實(shí)驗(yàn),檢查穩(wěn)態(tài)指標(biāo),記錄、恢復(fù) 實(shí)驗(yàn),修復(fù)發(fā)現(xiàn)的問題,然后做持續(xù)驗(yàn)證。以上是對混沌工程理論相關(guān)的介紹,那么如何在企業(yè)中落地混沌工程呢?
我這里分為三個階段,首先要堅定價值,因?yàn)槟銜艿絹碜远喾矫娴奶魬?zhàn),其次引入混沌工程技術(shù),最后在企業(yè)中推廣混沌工程文化。在實(shí)施混沌工程之前,必須能說清楚混沌工程的價值,而且當(dāng)受到挑戰(zhàn)時,意志要堅定。
比如來自老板的挑戰(zhàn),”如何衡量混沌工程的價值?“,可以向老板表達(dá)出,”從故障的應(yīng)急效率、故障復(fù)發(fā)率、線上故障發(fā)現(xiàn)數(shù)來衡量“等等。所以這些問題自己要想清楚。有了堅定的意志,就要開始落地,首先要先了解自己的系統(tǒng)。
這里系統(tǒng)成熟度分 5 個等級,也可以說是業(yè)務(wù)系統(tǒng)所處的階段,列出了每個階段適合什么故障場景。剛才也有聽眾問,”我的服務(wù)就是單點(diǎn)的,還有沒有實(shí)施混沌工程的必要?“,有必要,可以實(shí)施簡單的實(shí)驗(yàn)場景,比如 CPU 滿載等,來驗(yàn)證監(jiān)控告警,如果發(fā)現(xiàn)沒有監(jiān)控告警,就要去推動完善它,然后再推動服務(wù)多實(shí)例部署,通過混沌工程一級一級的去推動系統(tǒng)的演進(jìn),最終實(shí)現(xiàn)具有韌性的系統(tǒng)。根據(jù)系統(tǒng)成熟度了解自己系統(tǒng)所適合的場景,接下來就要選擇一款合適的混沌實(shí)驗(yàn)工具。
這里列舉了五個維度:場景豐富度、工具類型、易用性等。可以從 awesome-chaos-engineering github 項(xiàng)目查找或者從 CNCF Landscpage 中查看混沌實(shí)驗(yàn)工具。阿里今年開源的 ChaosBlade 也已經(jīng)加入到 CNCF Landscape 中,后面會對此項(xiàng)目做重點(diǎn)介紹,先來看阿里混沌工程技術(shù)的演進(jìn)。
?
2012 年阿里內(nèi)部就上線了 EOS 項(xiàng)目,用于梳理分布式服務(wù)強(qiáng)弱依賴問題,同年進(jìn)行了同城容災(zāi)的斷網(wǎng)演練。 15 年 實(shí)現(xiàn)異地多活,16 年內(nèi)部推出故障演練平臺 MonkeyKing,開始在線上環(huán)境實(shí)施混沌實(shí)驗(yàn),然后 18 年輸出了 ACP 專有云產(chǎn)品 和 AHAS 公有云產(chǎn)品,其中 AHAS 旨在將阿里的高可用架構(gòu)經(jīng)驗(yàn)以產(chǎn)品的形式對外輸出,服務(wù)于外部。19 年推出 ChaosBlade 項(xiàng)目,將底層的故障注入能力對外開源,同年也推出混沌實(shí)驗(yàn)平臺專有云版本 AHAS Chaos,接下來重點(diǎn)介紹一下 ChaosBlade 項(xiàng)目。
ChaosBlade 中文名混沌之刃,是一款混沌實(shí)驗(yàn)實(shí)施工具,支持豐富的實(shí)驗(yàn)場景,比如應(yīng)用、容器、基礎(chǔ)資源等。工具使用簡單,擴(kuò)展方便,其遵循社區(qū)提出的混沌實(shí)驗(yàn)?zāi)P汀?/p>
該模型分四次,層層遞進(jìn),很清晰的表達(dá)出對什么組件做實(shí)驗(yàn),實(shí)驗(yàn)范圍是什么,實(shí)驗(yàn)觸發(fā)的匹配規(guī)則有哪些,執(zhí)行什么實(shí)驗(yàn)。該模型簡潔、通用,語言領(lǐng)域無關(guān)、易于實(shí)現(xiàn)。阿里集團(tuán)內(nèi)的 C++、NodeJS、Dart 應(yīng)用以及容器平臺的實(shí)驗(yàn)場景都基于此模型實(shí)現(xiàn)。此模型具有很重要的意義,依據(jù)此模型可以更精準(zhǔn)的描述、更好的理解、更方便沉淀實(shí)驗(yàn)場景以及發(fā)掘更多的場景。依據(jù)此模型實(shí)現(xiàn)的工具更加規(guī)范、簡潔,我們具體看下 ChaosBlade 基于此模型的架構(gòu)設(shè)計。
我將 ChaosBlade 的設(shè)計總結(jié)為這六點(diǎn)。使用 Golang 構(gòu)建,實(shí)現(xiàn)跨平臺,并且解壓即用;工具使用采用 CLI 的方式,使用簡單,具備完善的命令提示;遵循混沌實(shí)驗(yàn)?zāi)P投x場景接口,所有場景基于此接口實(shí)現(xiàn),將模型轉(zhuǎn)換為 cobra 框架所支持的命令參數(shù),實(shí)現(xiàn)變量參數(shù)化、參數(shù)規(guī)范化,并且通過實(shí)驗(yàn)?zāi)P?Yaml 描述,可以很方便的實(shí)現(xiàn)多語言、多領(lǐng)域的場景擴(kuò)展。而且將整個實(shí)驗(yàn)對象化,每個實(shí)驗(yàn)對象都會有個 UID,方便管理。左下角是 chaosblade 工具的使用事例,可以看出使用簡潔、清晰。介紹完工具設(shè)計,我們再來談實(shí)施混沌工程很重要的一點(diǎn),如何控制爆炸半徑,減小實(shí)施風(fēng)險。
環(huán)境越往下,實(shí)施風(fēng)險越高,實(shí)驗(yàn)越真實(shí),越具有價值。我們通過兩種方式來控制爆炸半徑,一是實(shí)驗(yàn)場景粒度,從 IDC 到用戶,影響范圍越來越低,另一個是從生產(chǎn)環(huán)境隔離出一部分機(jī)器,通過錄制流量,對線上流量重放,進(jìn)行請求打標(biāo),實(shí)現(xiàn)流量路由到隔離出的環(huán)境,對這些機(jī)器和請求做實(shí)驗(yàn),這樣可控制的爆炸半徑更大。
具備了控制爆炸半徑的能力,我們可以通過平臺,標(biāo)準(zhǔn)化實(shí)驗(yàn)流程,實(shí)現(xiàn)自動化執(zhí)行。中間部分的圖片是阿里云產(chǎn)品 AHAS Chaos 混沌實(shí)驗(yàn)平臺的截圖,該平臺將實(shí)施混沌工程分為四個階段。首先是準(zhǔn)備階段,此階段可以定義監(jiān)控指標(biāo),準(zhǔn)備實(shí)驗(yàn)環(huán)境等,比如 ChaosBlade 執(zhí)行 Java 應(yīng)用實(shí)驗(yàn),必須先執(zhí)行 Prepare 操作掛載 Agent,則可放到此階段執(zhí)行。第二個階段是執(zhí)行階段,此階段用于執(zhí)行混沌實(shí)驗(yàn)。第三個檢查階段,用于檢查監(jiān)控指標(biāo),記錄問題等,第四階段是還原階段。此四個階段囊括了前面提到的混沌工程實(shí)施的八個步驟,大家看到每個階段下的每項(xiàng)都是一個小程序,大家可以基于規(guī)范開發(fā)自己的小程序來擴(kuò)展自身實(shí)驗(yàn)所需要的能力,比如對接自己的業(yè)務(wù)監(jiān)控,做實(shí)驗(yàn)前通知等。接下來看一下該平臺的架構(gòu)設(shè)計。
這是集團(tuán)和云上混沌實(shí)驗(yàn)平臺的架構(gòu)圖,通過流程引擎規(guī)范混沌工程實(shí)施步驟,對外開放平臺 OpenAPI,便于上層業(yè)務(wù)建設(shè),并且提供小程序的機(jī)制,可以對接監(jiān)控平臺或做一些實(shí)驗(yàn)前的準(zhǔn)備操作等,將故障注入能力收斂到 ChaosBlade。基于此混沌實(shí)驗(yàn)平臺承載了集團(tuán)突襲演練、攻防演練、新零售演練等業(yè)務(wù)。此平臺已經(jīng)對外輸出,包含公有云和專有云版本,阿里云網(wǎng)站搜索 AHAS 即可。具備了完善的混沌實(shí)驗(yàn)平臺,可以在企業(yè)中推廣混沌工程文化
比如建立門戶網(wǎng)站,宣傳好的架構(gòu),并且推送演練紅黑榜。制訂攻防制度,如故障分、演練分來推動并量化演練。可以設(shè)定固定的攻防日,全企業(yè)參與,以戰(zhàn)養(yǎng)戰(zhàn),培養(yǎng)混沌文化。介紹完混沌工程在企業(yè)落地的流程,我們最后分享下分布式服務(wù)下的混沌工程實(shí)踐,先來看一下分布式服務(wù)所面臨的問題。
系統(tǒng)日益龐大,服務(wù)間的依賴錯綜復(fù)雜,很難評估單個服務(wù)故障對整個系統(tǒng)的影響,并且請求鏈路長,監(jiān)控告警不完善,導(dǎo)致發(fā)現(xiàn)問題、定位問題難度增大,同時業(yè)務(wù)和技術(shù)迭代快,如何持續(xù)保障系統(tǒng)的穩(wěn)定性受到很大的挑戰(zhàn)。那么一個高可用的分布式服務(wù)應(yīng)該具備哪些能力呢?
這里列舉了分布式系統(tǒng)的高可用原則,前面的講師伍道長提到系統(tǒng)的好模式和壞模式,我這里列舉出的都是好模式。比如入口請求負(fù)載均衡,對異常的節(jié)點(diǎn)進(jìn)行流量調(diào)度,通過請求限流來控制訪問量,防止打垮系統(tǒng),提供超時重試,當(dāng)單個服務(wù)實(shí)例訪問超時時,可以將請求路由到其他服務(wù)實(shí)例進(jìn)行重試,梳理強(qiáng)弱依賴,對占用資源高的弱依賴服務(wù)進(jìn)行降級,對下游出問題的服務(wù)進(jìn)行熔斷等等。還有系統(tǒng)運(yùn)維方面,系統(tǒng)要做到可監(jiān)控、可灰度、可回滾,具備彈性伸縮的能力,能快速擴(kuò)容或者線下有問題的節(jié)點(diǎn)。這些高可用原則都可以作為混沌實(shí)驗(yàn)場景,從中挑選兩個來講下具體的混沌工程實(shí)踐。先來看一下 Demo 拓?fù)鋱D。
此拓?fù)鋱D來自于阿里云 AHAS 產(chǎn)品架構(gòu)感知功能,可自動感知架構(gòu)拓?fù)?#xff0c;并且可以展示進(jìn)程、網(wǎng)絡(luò)、節(jié)點(diǎn)等數(shù)據(jù)。這個分布式服務(wù) Demo 分三級調(diào)用,consumer 調(diào)用 provider,provider 調(diào)用 base,同時 provider 還調(diào)用 mk-demo 數(shù)據(jù)庫,provider 和 base 服務(wù)具有兩個實(shí)例,在 AHAS 架構(gòu)拓?fù)鋱D上,我們點(diǎn)擊一個實(shí)例節(jié)點(diǎn),可以到非常清晰的調(diào)用關(guān)系。我們后面結(jié)合這個 Demo 去講解案例。
案例一,我們驗(yàn)證系統(tǒng)的監(jiān)控告警性有效性。按照前面提到的混沌工程實(shí)施步驟,那么這個案例執(zhí)行的實(shí)驗(yàn)場景是數(shù)據(jù)庫調(diào)用延遲,我們先定義監(jiān)控指標(biāo):慢 SQL 數(shù)和告警信息,做出期望假設(shè):慢 SQL 數(shù)增加,釘釘群收到慢 SQL 告警。接下來執(zhí)行實(shí)驗(yàn)。我們直接使用 ChaosBlade 工具執(zhí)行,可以看下左下角,我們對 demo-provider 注入調(diào)用 mysql 查詢時,若數(shù)據(jù)庫是 demo 且表名是 d_discount,則對 50% 的查詢操作延遲 600 毫秒。我們使用阿里云產(chǎn)品 ARMS 做監(jiān)控告警。大家可以看到,當(dāng)執(zhí)行完混沌實(shí)驗(yàn)后,很快釘釘群里就收到了報警。所以我們對比下之前定義的監(jiān)控指標(biāo),是符合預(yù)期的。但需要注意的是這次符合預(yù)期并不代表以后也符合,所以需要通過混沌工程持續(xù)性的驗(yàn)證。出現(xiàn)慢 SQL,可通過 ARMS 的鏈路根據(jù)來排查定位,可以很清楚的看出哪條語句執(zhí)行慢。
前面講了一個符合預(yù)期的案例,我們再來看一個不符合預(yù)期的。此案例是驗(yàn)證系統(tǒng)異常實(shí)例隔離的能力,我們的 Demo 中 consumer 調(diào)用 provider 服務(wù),provider 服務(wù)具有兩個實(shí)例,我們對其中一個注入延遲故障,監(jiān)控指標(biāo)是 consumer 的 QPS,穩(wěn)態(tài)在 510 左右。我們做的容錯假設(shè)是系統(tǒng)會自動隔離或下線出問題的服務(wù)實(shí)例,防止請求路由的此實(shí)例,所有 QPS 會有短暫的下跌,但很快會恢復(fù)。這個案例,我們使用阿里云 AHAS 混沌實(shí)驗(yàn)平臺來執(zhí)行,我們對 demo-provider-1 注入延遲故障,基于此平臺可以很方便的執(zhí)行混沌實(shí)驗(yàn)。執(zhí)行混沌實(shí)驗(yàn)后,QPS 下跌到 40 左右,很長時間沒有自動恢復(fù),所以不符合預(yù)期,我們通過人工的方式對該異常的實(shí)例做下線處理,很快就看到,consumer 的 QPS 恢復(fù)正常。所以我們通過混沌工程發(fā)現(xiàn)了系統(tǒng)問題,我們后面需要做就是記錄此問題,并且推動修復(fù),后續(xù)做持續(xù)性的驗(yàn)證。
我這次分享從介紹混沌工程到如何在企業(yè)中落地,并且通過具體的分布式服務(wù)的例子介紹混沌工程的實(shí)踐。我們做一下回顧總結(jié)。一是混沌工程是一種主動防御的穩(wěn)定性手段,體現(xiàn)了反脆弱的思想;二,落地混沌工程會遇到很多挑戰(zhàn),堅持原則不能退讓;很重要的一點(diǎn)是實(shí)施混沌工程不能只是把故障制造出來,需要有明確的驅(qū)動目標(biāo);最后選擇合適的工具和平臺,控制演練風(fēng)險,實(shí)現(xiàn)常態(tài)化演練。
這個是部門內(nèi)部部分高可用架構(gòu)相關(guān)的產(chǎn)品圖,以及對應(yīng)的對外輸出的阿里云產(chǎn)品,如包含架構(gòu)感知、故障演練、限流降級的 AHAS,具備監(jiān)控告警和鏈路跟蹤的 ARMS,以及性能測試服務(wù) PTS,歡迎大家使用。我的分享到此結(jié)束,謝謝大家。
原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容,未經(jīng)允許不得轉(zhuǎn)載。
總結(jié)
以上是生活随笔為你收集整理的分布式服务架构下的混沌工程实践的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 揭秘 Flink 1.9 新架构,Bli
- 下一篇: BDS-HA:构建高可用、低延迟的HBa