分佈式服務架構下的混沌工程實踐

本文來自阿里巴巴高可用架構團隊高級開發工程師肖長軍(花名穹谷)在 GIAC(全球互聯網架構大會)上的分享,包含三部份內容:(阿里巴巴中間件公衆號對話框發送「混沌工程」,獲取分享PPT)mysql

  • 混沌工程的定義、價值、原則和流程;
  • 混沌工程如何在企業中落地,以及 ChaosBlade 和混沌實驗平臺 AHAS Chaos 架構設計;
  • 結合兩個具體案例介紹了分佈式服務下的混沌工程實踐;

你們好,我是來自阿里的肖長軍,今天給你們分享混沌工程在分佈式服務架構下的具體實踐。git

先作個自我介紹,我來自於阿里高可用架構團隊,花名穹谷,作過度布式系統設計和 APM 研發相關工做,如今專一於高可用架構和混沌工程領域,是阿里雲產品 AHAS 底層技術負責人和開源項目 ChaosBlade 負責人,而且承擔集團內故障演練、突襲演練、攻防演練相關的研發工做。今天分享的內容包含如下三個方面。github

先從混沌工程的定義、價值、原則和實施步驟介紹混沌工程,而後分享混沌工程如何在企業中落地,最後介紹分佈式服務下混沌工程實踐案例。咱們先來看一下什麼是混沌工程。sql

混沌工程理論一文中提到,其是在分佈式系統上進行實驗的學科,核心目的是提升生產環境中系統的容錯性和可恢復性。尼采的這句話: "打不倒個人必使我強大",也很好的詮釋了混沌工程反脆弱的思想。除了這裏提到的目的,實施混沌工程還有哪些價值呢?數據庫

這裏我從四個角色來講明,對於架構師來講,能夠驗證系統架構的容錯能力,好比驗證如今提倡的面向失敗設計的系統;對於開發和運維,能夠提升故障的應急效率,實現故障告警、定位、恢復的有效和高效性。對於測試來講,能夠彌補傳統測試方法留下的空白,以前的測試方法基本上是從用戶的角度去作,而混沌工程是從系統的角度進行測試,下降故障複發率。對於產品和設計,經過混沌事件查看產品的表現,提高客戶使用體驗。因此說混沌工程面向的不只僅是開發、測試,擁有最好的客戶體驗是每一個人的目標。咱們知道,系統發生故障的那一刻不是由你來選擇的,而是那一刻選擇你,你所能作,只能是爲之作好準備。瞭解了混沌工程的價值,咱們再來看一下實施混沌工程的一些原則。小程序

前面 Vilas 老師也提到了,我這裏重點來介紹一下這五項原則。第一條:」創建一個圍繞穩定狀態行爲的假說「,其包含兩個含義,一個是定義能直接反應業務服務的監控指標,須要注意的是這裏的監控指標並非系統資源指標,好比CPU、內存等,這裏的監控指標是能直接衡量系統服務質量的業務監控。舉個例子,一個調用延遲故障,請求的 RT 會變長,對上層交易量形成下跌的影響,那麼這裏交易量就能夠做爲一個監控指標。這條原則的另外一個含義是故障觸發時,對系統行爲做出假設以及監控指標的預期變化。第二個指模擬生產環境中真實的或有理論依據的故障,第三個建議在生產環境中運行實驗,但也不是說必須在生產環境中執行,只是實驗環境越真實,混沌工程越有價值。持續的執行才能持續的下降故障複發率和提早發現故障,因此須要持續的自動化運行試驗,最後一個,混沌工程很重要的一點是控制爆炸半徑,也就是試驗影響面,防止預期外的資損發生,後面會介紹控制爆炸半徑的方式。依據這些指導原則能夠更有效實施混沌工程,那麼混沌工程的實施步驟是什麼?網絡

主要細分爲這 8 步,指定試驗計劃,定義穩態指標,作出系統容錯假設,執行實驗,檢查穩態指標,記錄、恢復 實驗,修復發現的問題,而後作持續驗證。以上是對混沌工程理論相關的介紹,那麼如何在企業中落地混沌工程呢?架構

我這裏分爲三個階段,首先要堅決價值,由於你會受到來自多方面的挑戰,其次引入混沌工程技術,最後在企業中推廣混沌工程文化。在實施混沌工程以前,必須能說清楚混沌工程的價值,並且當受到挑戰時,意志要堅決。負載均衡

好比來自老闆的挑戰,」如何衡量混沌工程的價值?「,能夠向老闆表達出,」從故障的應急效率、故障複發率、線上故障發現數來衡量「等等。因此這些問題本身要想清楚。有了堅決的意志,就要開始落地,首先要先了解本身的系統。框架

這裏系統成熟度分 5 個等級,也能夠說是業務系統所處的階段,列出了每一個階段適合什麼故障場景。剛纔也有聽衆問,」個人服務就是單點的,還有沒有實施混沌工程的必要?「,有必要,能夠實施簡單的實驗場景,好比 CPU 滿載等,來驗證監控告警,若是發現沒有監控告警,就要去推進完善它,而後再推進服務多實例部署,經過混沌工程一級一級的去推進系統的演進,最終實現具備韌性的系統。根據系統成熟度瞭解本身系統所適合的場景,接下來就要選擇一款合適的混沌實驗工具。

這裏列舉了五個維度:場景豐富度、工具類型、易用性等。能夠從 awesome-chaos-engineering github 項目查找或者從 CNCF Landscpage 中查看混沌實驗工具。阿里今年開源的 ChaosBlade 也已經加入到 CNCF Landscape 中,後面會對此項目作重點介紹,先來看阿里混沌工程技術的演進。

2012 年阿里內部就上線了 EOS 項目,用於梳理分佈式服務強弱依賴問題,同年進行了同城容災的斷網演練。 15 年 實現異地多活,16 年內部推出故障演練平臺 MonkeyKing,開始在線上環境實施混沌實驗,而後 18 年輸出了 ACP 專有云產品 和 AHAS 公有云產品,其中 AHAS 旨在將阿里的高可用架構經驗以產品的形式對外輸出,服務於外部。19 年推出 ChaosBlade 項目,將底層的故障注入能力對外開源,同年也推出混沌實驗平臺專有云版本 AHAS Chaos,接下來重點介紹一下 ChaosBlade 項目。

ChaosBlade 中文名混沌之刃,是一款混沌實驗實施工具,支持豐富的實驗場景,好比應用、容器、基礎資源等。工具使用簡單,擴展方便,其遵循社區提出的混沌實驗模型。

該模型分四次,層層遞進,很清晰的表達出對什麼組件作實驗,實驗範圍是什麼,實驗觸發的匹配規則有哪些,執行什麼實驗。該模型簡潔、通用,語言領域無關、易於實現。阿里集團內的 C++、NodeJS、Dart 應用以及容器平臺的實驗場景都基於此模型實現。此模型具備很重要的意義,依據此模型能夠更精準的描述、更好的理解、更方便沉澱實驗場景以及發掘更多的場景。依據此模型實現的工具更加規範、簡潔,咱們具體看下 ChaosBlade 基於此模型的架構設計。

image.png

我將 ChaosBlade 的設計總結爲這六點。使用 Golang 構建,實現跨平臺,而且解壓即用;工具使用採用 CLI 的方式,使用簡單,具有完善的命令提示;遵循混沌實驗模型定義場景接口,全部場景基於此接口實現,將模型轉換爲 cobra 框架所支持的命令參數,實現變量參數化、參數規範化,而且經過實驗模型 Yaml 描述,能夠很方便的實現多語言、多領域的場景擴展。並且將整個實驗對象化,每一個實驗對象都會有個 UID,方便管理。左下角是 chaosblade 工具的使用事例,能夠看出使用簡潔、清晰。介紹完工具設計,咱們再來談實施混沌工程很重要的一點,如何控制爆炸半徑,減少實施風險。

環境越往下,實施風險越高,實驗越真實,越具備價值。咱們經過兩種方式來控制爆炸半徑,一是實驗場景粒度,從 IDC 到用戶,影響範圍愈來愈低,另外一個是從生產環境隔離出一部分機器,經過錄制流量,對線上流量重放,進行請求打標,實現流量路由到隔離出的環境,對這些機器和請求作實驗,這樣可控制的爆炸半徑更大。

具有了控制爆炸半徑的能力,咱們能夠經過平臺,標準化實驗流程,實現自動化執行。中間部分的圖片是阿里雲產品 AHAS Chaos 混沌實驗平臺的截圖,該平臺將實施混沌工程分爲四個階段。首先是準備階段,此階段能夠定義監控指標,準備實驗環境等,好比 ChaosBlade 執行 Java 應用實驗,必須先執行 Prepare 操做掛載 Agent,則可放到此階段執行。第二個階段是執行階段,此階段用於執行混沌實驗。第三個檢查階段,用於檢查監控指標,記錄問題等,第四階段是還原階段。此四個階段囊括了前面提到的混沌工程實施的八個步驟,你們看到每一個階段下的每項都是一個小程序,你們能夠基於規範開發本身的小程序來擴展自身實驗所須要的能力,好比對接本身的業務監控,作實驗前通知等。接下來看一下該平臺的架構設計。

這是集團和雲上混沌實驗平臺的架構圖,經過流程引擎規範混沌工程實施步驟,對外開放平臺 OpenAPI,便於上層業務建設,而且提供小程序的機制,能夠對接監控平臺或作一些實驗前的準備操做等,將故障注入能力收斂到 ChaosBlade。基於此混沌實驗平臺承載了集團突襲演練、攻防演練、新零售演練等業務。此平臺已經對外輸出,包含公有云和專有云版本,阿里雲網站搜索 AHAS 便可。具有了完善的混沌實驗平臺,能夠在企業中推廣混沌工程文化

好比創建門戶網站,宣傳好的架構,而且推送演練紅黑榜。制訂攻防制度,如故障分、演練分來推進並量化演練。能夠設定固定的攻防日,全企業參與,以戰養戰,培養混沌文化。介紹完混沌工程在企業落地的流程,咱們最後分享下分佈式服務下的混沌工程實踐,先來看一下分佈式服務所面臨的問題。

系統日益龐大,服務間的依賴錯綜複雜,很難評估單個服務故障對整個系統的影響,而且請求鏈路長,監控告警不完善,致使發現問題、定位問題難度增大,同時業務和技術迭代快,如何持續保障系統的穩定性受到很大的挑戰。那麼一個高可用的分佈式服務應該具有哪些能力呢?

這裏列舉了分佈式系統的高可用原則,前面的講師伍道長提到系統的好模式和壞模式,我這裏列舉出的都是好模式。好比入口請求負載均衡,對異常的節點進行流量調度,經過請求限流來控制訪問量,防止打垮系統,提供超時重試,當單個服務實例訪問超時時,能夠將請求路由到其餘服務實例進行重試,梳理強弱依賴,對佔用資源高的弱依賴服務進行降級,對下游出問題的服務進行熔斷等等。還有系統運維方面,系統要作到可監控、可灰度、可回滾,具有彈性伸縮的能力,能快速擴容或者線下有問題的節點。這些高可用原則均可以做爲混沌實驗場景,從中挑選兩個來說下具體的混沌工程實踐。先來看一下 Demo 拓撲圖。

此拓撲圖來自於阿里雲 AHAS 產品架構感知功能,可自動感知架構拓撲,而且能夠展現進程、網絡、節點等數據。這個分佈式服務 Demo 分三級調用,consumer 調用 provider,provider 調用 base,同時 provider 還調用 mk-demo 數據庫,provider 和 base 服務具備兩個實例,在 AHAS 架構拓撲圖上,咱們點擊一個實例節點,能夠到很是清晰的調用關係。咱們後面結合這個 Demo 去講解案例。

案例一,咱們驗證系統的監控告警性有效性。按照前面提到的混沌工程實施步驟,那麼這個案例執行的實驗場景是數據庫調用延遲,咱們先定義監控指標:慢 SQL 數和告警信息,作出指望假設:慢 SQL 數增長,釘釘羣收到慢 SQL 告警。接下來執行實驗。咱們直接使用 ChaosBlade 工具執行,能夠看下左下角,咱們對 demo-provider 注入調用 mysql 查詢時,若數據庫是 demo 且表名是 d_discount,則對 50% 的查詢操做延遲 600 毫秒。咱們使用阿里雲產品 ARMS 作監控告警。你們能夠看到,當執行完混沌實驗後,很快釘釘羣裏就收到了報警。因此咱們對比下以前定義的監控指標,是符合預期的。但須要注意的是此次符合預期並不表明之後也符合,因此須要經過混沌工程持續性的驗證。出現慢 SQL,可經過 ARMS 的鏈路根據來排查定位,能夠很清楚的看出哪條語句執行慢。

前面講了一個符合預期的案例,咱們再來看一個不符合預期的。此案例是驗證系統異常實例隔離的能力,咱們的 Demo 中 consumer 調用 provider 服務,provider 服務具備兩個實例,咱們對其中一個注入延遲故障,監控指標是 consumer 的 QPS,穩態在 510 左右。咱們作的容錯假設是系統會自動隔離或下線出問題的服務實例,防止請求路由的此實例,全部 QPS 會有短暫的下跌,但很快會恢復。這個案例,咱們使用阿里雲 AHAS 混沌實驗平臺來執行,咱們對 demo-provider-1 注入延遲故障,基於此平臺能夠很方便的執行混沌實驗。執行混沌實驗後,QPS 下跌到 40 左右,很長時間沒有自動恢復,因此不符合預期,咱們經過人工的方式對該異常的實例作下線處理,很快就看到,consumer 的 QPS 恢復正常。因此咱們經過混沌工程發現了系統問題,咱們後面須要作就是記錄此問題,而且推進修復,後續作持續性的驗證。

我此次分享從介紹混沌工程到如何在企業中落地,而且經過具體的分佈式服務的例子介紹混沌工程的實踐。咱們作一下回顧總結。一是混沌工程是一種主動防護的穩定性手段,體現了反脆弱的思想;二,落地混沌工程會遇到不少挑戰,堅持原則不能退讓;很重要的一點是實施混沌工程不能只是把故障製造出來,須要有明確的驅動目標;最後選擇合適的工具和平臺,控制演練風險,實現常態化演練。

這個是部門內部部分高可用架構相關的產品圖,以及對應的對外輸出的阿里雲產品,如包含架構感知、故障演練、限流降級的 AHAS,具有監控告警和鏈路跟蹤的 ARMS,以及性能測試服務 PTS,歡迎你們使用。個人分享到此結束,謝謝你們。

ChaosBlade 項目地址:https://github.com/chaosblade-io/chaosblade
AHAS 雲產品地址:https://www.aliyun.com/product/ahas



本文做者:中間件小哥

閱讀原文

本文爲雲棲社區原創內容,未經容許不得轉載。

相關文章
相關標籤/搜索