摘要：我們決定使用一個已有的實驗平臺來對圍繞系統(tǒng)的應(yīng)用級別混沌實驗進(jìn)行編排，即紫色部分，通過對下層像這樣的中間件進(jìn)行注入來實現(xiàn)。所以一些人可能沒有對應(yīng)的知識和機能來進(jìn)行合適的混沌實驗。

Roman Atachiants · Tharaka Wijebandara · Abeesh Thomas
原文： https://engineering.grab.com/...
譯：祝坤榮

對每個用戶來說，Grab是一個可以叫車，叫外賣或付款的一個APP。對工程師來說，Grab是一個有許多服務(wù)并通過RPC交互的分布式系統(tǒng)，有時也可以叫做微服務(wù)架構(gòu)。在數(shù)千臺服務(wù)器上運行的數(shù)百個服務(wù)每天都有工程師在上面進(jìn)行變更。每次復(fù)雜的配置，事情可能都會變糟。 幸運的是，很多Grab App的內(nèi)部服務(wù)不像用戶叫車那樣的動作這么重要。例如，收藏夾可以幫用戶記住之前的位置，但如果它們不工作，用戶仍然可以得到較合理的用戶體驗。

服務(wù)部分可用并不是沒有風(fēng)險。工程師需要對于RPC調(diào)用非核心服務(wù)時需要有有備用計劃。如果應(yīng)急策略沒有很好地執(zhí)行，非核心服務(wù)的問題也可能導(dǎo)致停機。

所以我們?nèi)绾伪ＷCGrab的用戶可以使用核心功能，例如叫車，而此時非核心服務(wù)正在出問題？答案是混沌工程。

在Grab，我們通過在整體業(yè)務(wù)流的內(nèi)部服務(wù)或組件上引入故障來實踐混沌工程。但失敗的服務(wù)不是實驗的關(guān)注點。我們感興趣的是測試依賴這個失敗服務(wù)的服務(wù)。

照理來說，上游服務(wù)應(yīng)該有彈性并且整體業(yè)務(wù)流應(yīng)該可以繼續(xù)工作。比如，叫車流程就算在司機地址服務(wù)上出現(xiàn)故障時仍應(yīng)該可以工作。我們測試重試和降級是否配置正確，是否熔斷器被正確的設(shè)置。

為了將混沌引入我們的系統(tǒng)，我們使用了我們的實驗平臺(ExP)和Grab-Kit.

混沌實驗平臺Exp將故障注入到處理流量服務(wù)的中間件(gRPC或HTTP服務(wù)器)。如果系統(tǒng)的行為與期望一致，你將對非核心服務(wù)故障時服務(wù)會平穩(wěn)降級產(chǎn)生信心。

混沌實驗平臺ExP在Grab的基礎(chǔ)設(shè)施中模擬不同的混沌類型，如延遲和內(nèi)存泄漏。這保證了每個組件在系統(tǒng)的依賴不響應(yīng)或響應(yīng)很高時仍能返回一些東西。它能保證我們對于實例級失敗有彈性，因為微服務(wù)級別的中斷對于可用性也是一個威脅。

為了構(gòu)建我們的混沌工程系統(tǒng)，我們認(rèn)為需要在兩個主要領(lǐng)域引入混沌：

基礎(chǔ)設(shè)置：隨機關(guān)閉基礎(chǔ)設(shè)施的實例和其他部分

應(yīng)用： 在較粗粒度引入運行時故障（如endpoint/request級別）

你可以稍后啟用有意的或隨機的混沌實驗：

隨機的

比較適合‘一次性’基礎(chǔ)設(shè)施（如EC2實例）

測試冗余的基礎(chǔ)設(shè)施對最終用戶的影響

當(dāng)影響面已經(jīng)十分確定

實驗

精確度量影響

使用實驗參數(shù)控制

對最終用戶有限的影響

適用于對于影響不十分確定的復(fù)雜故障（如延遲）

最后，你可以將故障模式按以下分類：

資源：CPU,內(nèi)存，IO，磁盤

網(wǎng)絡(luò)：黑洞，延遲，丟包，DNS

狀態(tài)：關(guān)機，時間，殺進(jìn)程

這些模型都可以在基礎(chǔ)設(shè)施或應(yīng)用級別使用或模擬：

對于Grab，進(jìn)行應(yīng)用級別的混沌實驗并仔細(xì)度量影響面很重要。我們決定使用一個已有的實驗平臺來對圍繞系統(tǒng)的應(yīng)用級別混沌實驗進(jìn)行編排，即紫色部分，通過對下層像Grab-Kit這樣的中間件進(jìn)行注入來實現(xiàn)。

現(xiàn)在有一些混沌工程工具。但是，使用它們經(jīng)常需要較高級的基礎(chǔ)設(shè)施和運維技巧，有能力設(shè)計和執(zhí)行實驗，以受控的方式有資源手工編排失敗場景。混沌工程不是簡單的在生產(chǎn)環(huán)境搞破壞。

將混沌工程理解成受控的實驗。我們的ExP SDK提供彈性和異步追蹤。這樣，我們可以將潛在的業(yè)務(wù)屬性度量對應(yīng)到混沌失敗上。比如，在訂車服務(wù)上進(jìn)行10秒延遲的混沌故障，我們可以知道多少輛車被影響了進(jìn)而知道損失了多少錢。

使用ExP作為混沌工程的工具意味著我們可以基于應(yīng)用或環(huán)境精確定制，讓它可以像監(jiān)控和部署管道一樣與其他環(huán)境緊密集成。

在安全上也可以獲得收益。使用ExP，所有的連接都在我們的內(nèi)部網(wǎng)絡(luò)中，給我們攻擊表面區(qū)域的能力。所有東西都可以掌控在手中，對外部世界沒有依賴。這也潛在的使監(jiān)控和控制流量變?nèi)菀琢恕?/p>

混沌故障可以點對點，編程式的，或定期執(zhí)行。你可以讓它們在特定日期的特定時間窗口來執(zhí)行。你可以設(shè)定故障的最大數(shù)量并定制它們（比如泄漏的內(nèi)存MB數(shù)量，等待的秒）。

ExP的核心價值是讓工程師可以啟動，控制和觀察系統(tǒng)在各種失敗條件下的行為。ExP提供全面的故障原子集，用來設(shè)計實驗并觀察問題在復(fù)雜分布式系統(tǒng)發(fā)生時的表現(xiàn)。而且，將混沌測試集成到ExP，我們對于部署流水線或網(wǎng)絡(luò)基礎(chǔ)設(shè)施不需要任何改動。因此這種組合可以很容易的在各種基礎(chǔ)設(shè)施和部署范式上使用。

要開發(fā)混沌工程SDK,我們使用我們已有ExP SDK的屬性 - single-digit , 不需要網(wǎng)絡(luò)調(diào)用。你可以看這里對于ExP SDK的實現(xiàn)?，F(xiàn)在我們要做兩件事：

一個在ExP SDK之上的很小的混沌SDK。我們將這個直接集成在我們的已有中間件，如Grab-Kit和DB層。

一個專門的用來創(chuàng)建混沌實驗的基于web的UI

歸功于我們與Grab-Kit的集成，Grab工程師不需要直接使用混沌SDK。當(dāng)Grab-Kit處理進(jìn)入的請求時，它先使用ExP SDK進(jìn)行檢查。如果請求“應(yīng)該失敗”，它將產(chǎn)生適合的失敗類型。然后它被轉(zhuǎn)發(fā)到特定endpoint的處理器。

我們現(xiàn)在支持以下失敗類型：

Error - 讓請求產(chǎn)生error

CPU Load - 在CPU上加大load

內(nèi)存泄漏 - 產(chǎn)生一些永遠(yuǎn)不能釋放的內(nèi)存

延遲 - 在一小段隨機時間內(nèi)停止請求的處理

磁盤空間 - 在機器上填入一些臨時文件

Goroutine泄漏 - 創(chuàng)建并泄漏goroutines

Panic - creates a panic in the request

限流 - 在請求上設(shè)置一個頻率限制并在超過限制時拒絕請求

舉個例子，如果一個叫車請求到了我們的叫車服務(wù)，我們調(diào)用GetVariable(“chaosFailure”)來決定請求是否應(yīng)該成功。請求里包含所有需要用來做決定的信息（如請求ID，實例的IP地址等）。關(guān)于實驗SDK的實現(xiàn)細(xì)節(jié)，看這篇博客。

為了在我們的工程師中推廣混沌工程我們圍繞它建立了很好的開發(fā)者體驗。在Grab不同的工程團(tuán)隊會有很多不同的技術(shù)和領(lǐng)域。所以一些人可能沒有對應(yīng)的知識和機能來進(jìn)行合適的混沌實驗。但使用我們簡化過的用戶界面，他們不需要擔(dān)心底層實現(xiàn)。

并且，運行混沌實驗的工程師是與像產(chǎn)品分析師和產(chǎn)品經(jīng)理不同的實驗平臺用戶。所以我們使用一種簡單和定制化UI配置新的混沌實驗來提供一種不同的創(chuàng)建實驗的體驗。

在混沌工程平臺，一個實驗有以下四步：

定義系統(tǒng)正常情況下的理想狀態(tài)。

創(chuàng)建一個控制組的配置和一個對比組的配置?？刂平M的變量使用已有值來賦值。對比組的變量使用新值來賦值。

引入真實世界的故障，例如增加CPU負(fù)載。

找到區(qū)分系統(tǒng)正確和失敗狀態(tài)標(biāo)志性不同。

要創(chuàng)建一個混沌實驗，標(biāo)明你想要實驗破壞的服務(wù)。你可以在以后通過提供環(huán)境，可用區(qū)或?qū)嵗斜韥砀?xì)化這個選擇范圍。

下一步，指定一組會被破壞的服務(wù)影響的服務(wù)列表。你在試驗期間需要仔細(xì)監(jiān)控這些服務(wù)。盡管我們持續(xù)跟蹤表示系統(tǒng)健康的整體度量指標(biāo)，它仍能幫助你在稍后分析實驗的影響。

然后，我們提供UI來指定目標(biāo)組和對比組的策略，失敗類型，每個對比組的配置。最后一步，提供時間周期并創(chuàng)建實驗。你已經(jīng)在你的系統(tǒng)中加入了混沌故障并可以監(jiān)控它對系統(tǒng)的影響了。

在運行混沌實驗后，一般會有兩種可能輸出。你已經(jīng)確認(rèn)了在引入的故障中系統(tǒng)保持了足夠的彈性，或你發(fā)現(xiàn)了需要修復(fù)的問題。如果混沌實驗最初被運行在預(yù)發(fā)環(huán)境那么兩種都是不錯的結(jié)果。在第一種場景，你對系統(tǒng)的行為產(chǎn)生了信心。在另一個場景，你在導(dǎo)致停機故障前發(fā)現(xiàn)了一個問題。

混沌工程是讓你工作更簡單的工具。通過主動測試和驗證你系統(tǒng)的故障模式你減輕了你的運維負(fù)擔(dān)，增加了你的彈性，在晚上也能睡個好覺。

本文來自微信公眾號「麥芽面包，id「darkjune_think」轉(zhuǎn)載請注明。
交流Email: [email protected]