簡介:在阿里淘寶雙11 的過程當中,長期以來都是在生產環節作全鏈路壓測的,經過實踐咱們發如今生產環境中作壓測,實際上會和一個 IT 組織的結構、成熟度、流程等緊密相關,因此咱們把全鏈路壓測從簡單的製做範圍內脫離出來,變成整個業務連續性的方案。
在阿里淘寶雙11 的過程當中,長期以來都是在生產環節作全鏈路壓測的,經過實踐咱們發如今生產環境中作壓測,實際上會和一個 IT 組織的結構、成熟度、流程等緊密相關,因此咱們把全鏈路壓測從簡單的製做範圍內脫離出來,變成整個業務連續性的方案。
本文分四個方面爲你們闡述:第一,整個全鏈路壓測的意義,爲何要在生產環節上作全鏈路壓測;第二,關於落地的技術點和解決方案;第三,生產過程當中作全鏈路壓測流程上的建議,考慮到每一個組織的承受度不同,給你們提供一些建議;第四,如何在第三方實現整個在生產環境中作業務連續性包括壓測的結果。
數據庫
上圖顯示了三個問題,其實是不一樣的 IT 組織在和測試交流的時候,這三個問題是比較有表明性的。
緩存
什麼是脆弱?脆弱就像玻璃,你們知道玻璃很脆易碎。脆弱的反義詞是什麼?不是強韌也不是堅韌,多是反脆弱。什麼是反脆弱呢?好比乒乓球,你們知道乒乓球在地上不用很大的力就能夠破壞掉,踩一腳就破壞掉了,可是高速運動的狀況下,乒乓球咱們施加的力度越大,它的反彈力度越大,說明乒乓球在運動過程當中有反脆弱的特性。
咱們的 IT 系統實際上也是這樣的。無論什麼代碼都不能保證是徹底沒有問題的,咱們的基礎設施可能也是脆弱的,像服務器、數據庫等總會有侷限。咱們的框架也老是脆弱的,將這些問題綜合在一塊兒,咱們但願經過某些手段,好比經過預案、風險的識別,或者經過一些熔斷的手段,最終把這些東西組合在一塊兒,讓整個 IT 系統有反脆弱的特性。總之,咱們但願經過一些手段使得 IT 系統有足夠的冗餘,並且有足夠多的預案應對突發的不肯定性風險。
安全
如何打造 IT 系統反脆弱能力呢?咱們但願經過一些手段,好比說像線上的壓測能力,提供不肯定的因素,接着經過在這個過程當中實時監控,包括預案的能力,最終把這些不肯定性的因素識別出來,而且在線上生產壓測過程當中對它作一些處理,更多可能會經過過後覆盤等方式,作到對不肯定性因素的識別。接着咱們可能會在生產環境中經過以前的手段,在生產環境上作一個穩定性的常態化壓測,實現長期穩定的場景,最終咱們可能達到反脆弱能力所須要的總體監控的能力、運營防禦能力,以及管控路由能力,這會讓整個 IT 系統具有反脆弱的特性。
性能優化
如何在生產環境上作全鏈路壓測?它須要用到哪些技術手段?
服務器
通常狀況下,測試是怎麼樣從線下一點點往線上演變的?我把它分爲四個階段:
架構
好比說咱們須要對整個壓測流量作一些染色,可以區分出來正常的業務數據,正常的流量和非正常的壓測流量,可能有的會作一些環境的隔離,而在業務生產期間內咱們作生產的壓測,須要考慮到整個流量的偏移、限流,包括熔斷機制等。無論怎樣作業務,可能都會對最終的生產業務形成必定的影響,真正出現問題的時候可能須要有快速的熔斷機制。
框架
對於整個全鏈路壓測來講,咱們須要幾個關鍵的技術:
運維
可能經過在壓縮機上作一些標識,好比加一個後綴,或者經過一些標識手段把流量讀出來,分散到相關的表裏去。同時在全鏈路流量展現過程當中咱們還須要作流量的識別,對於壓測流量通過的每個中間件,每個服務咱們都但願可以準確的識別出來,這個流量是來自於壓測機仍是來自於正常流量,這是第一步。
工具
咱們須要經過哪些手段,好比經過影子庫,經過運維的同窗作一個和生產上面一樣的影子庫,而後切到影子庫上,或者在生產庫上作一個相同的影子表,來作數據隔離。第一種方式安全度高一些,可是缺點在於咱們用影子庫的時候整個生產環境是不可用的。生產影子庫不能徹底模擬出整個線上的狀況,由於影子表須要咱們有更高的技術水平,可以保障整個鏈路可追蹤,包括整個數據若是一旦出錯數據恢復能力等等。
性能
也就是風險熔斷機制,一旦真的發現生產環境的線上壓測對咱們的業務形成了影響,咱們須要經過一些規則或者其餘的指標來自動觸發風險熔斷,包括管控等等這樣的手段,無論是提供施壓機的流量,仍是把生產系統損壞的部分作業務隔離,這樣的手段都是咱們作生產過程當中全鏈路壓測的必要手段。
其實日誌自己不會對全鏈路形成太大的影響,可是由於作數字化水平的提高,日誌基本上是BI同窗包括運營的同窗對整個業務分析最重要的數據來源,若是咱們不作日誌隔離頗有可能會對 BI 決策形成必定的影響,好比壓測過程當中咱們會大量採用某個地域的流量對生產環境作訪問,BI 的同窗可能會經過日誌分析發現某一個地區作大,致使他錯誤的運營決策,因此說對於生產過程當中的全鏈路壓測來講,咱們須要在整個生產過程當中作必定的日誌隔離,區分出來正常的生產流量和壓測流量之間的存儲。
這部分是真正想做爲全鏈路壓測和業務連續性平臺所須要的功能。
經過這套架構,咱們如今能夠作到目前比按照總體環境大約節省成本是 40%左右,基本上對整個生產業務沒有任何切入。
下面來具體談一談如何作一個影子數據庫,包括整個流量識別。
橙色的部分是真正的壓測流量,這部分咱們會在施壓機上作一個標識,如今是會加一個後綴。另外還會在服務器作 filter,它實際上是攔截器,咱們會攔截到流量裏面相關的標識,而後把它作區分、作染色,而且作跟蹤,每個請求基本上能夠真正作到在任何中間件以及項目堆裏都是透明可見的。
真正在壓測過程當中經過 Agent 字節碼結束將它直接改寫,將字節的條件替換成壓縮的條件。固然要先把影子庫建好,經過底層的追蹤咱們能夠把相應的流量,若是數據庫就會走得比較明確,以後咱們會作流量的測試,看看是否比較明確,並且咱們能夠作到整個測試數據帶有標識,一旦真的沒有走到診斷裏面去,咱們也能夠在正常的表裏作刪除,而且每個通過的區域對咱們來講都是可見的。
經過這樣的方式,目前絕大部分 IT 組織是分三個階段,固然有一些很是成熟的是分爲兩個階段:
這些是咱們目前在整個測試生命週期裏但願在各個階段實現的目的。
考慮到各個組織的成熟度不同,咱們提供的這些建議不必定適用於全部的 IT 組織,但你們能夠根據自身狀況參考一下。
咱們通常爲第三方實施全鏈路壓測,線上生產壓測,會經歷五個階段:
首先是和第三方一塊兒梳理業務的階段,咱們會作如下幾件事情:
1.根據過往系統使用狀況評估業務系統的性能指標、容量指標;
2.對現有信息系統作系統架構的梳理,肯定整個被染色流量的路徑途徑;
3.對壓測時長,包括間隔等作溝通,確認相關的壓測場景設計;
4.生產數據脫敏,若是有一部分涉及到生產數據可能會作生產數據的脫敏等相關工做。
這部分作完是作第二部分,對某些應用進行改造。好比說作流量打標工做,經過監控的流量肯定業務系統,可能在業務系統裏會作相關監控的接入,相關的第三方組件會進行 Mock,整個壓測場景的建立會和第三方溝通好。包括流量表建設和預案等等接入。
三是整個壓測的過程,整個生產狀態下的全鏈路壓測,會對整個系統進行性能優化及容量評估。
四是將線上全鏈路壓測常態化,這裏面會有一些事情,好比說限流、降級、混沌工程驗收,包括生產發佈的事情。
五是對於整個活動作覆盤,看應急預案是否生效,還有哪些地方須要優化,這是生產環節全鏈路壓測的生命週期。
咱們如今作一些更深刻的東西,整個開發過程當中,目前你們都使用 DevOps,可能單接口的性能測試在過程當中就已經用到了,目前咱們給企業打造的都包含了接口級別的單機性能測試,使用單機測試工具,在發佈過程當中開始驗收單接口的性能問題,保證這個接口發到線上不會有代碼級別錯誤,最終會省掉集成壓測包括測試環境中壓測的步驟,直接走到線上壓測這個過程。單接口階段咱們會支持相應主流的框架壓測,目前咱們也在不斷作測試環境集羣的壓測支持,仍是但願直接用戶跳過這個步驟開始在線上直接作流量隔離的壓測。
上圖是咱們認爲一個完整的業務連續性平臺須要的功能。
1.壓測流量發起的控制檯,流量發起端,這塊其實是管理整個壓測流量和場景設計;
2.流量隔離控制檯,這部分但願可以作到統一切流,當出現問題的時候能夠一下把壓測流量切掉,統一路由;
3.壓測過程當中有整個流量監控包括系統監控;壓測過程當中對於整個應用的性能監控平臺,包括鏈路監控、JVM 監控、組件監控等等;
4.真正的混沌工程,包括流控規則、隔離規則、降級規則等等平臺,這裏會維護相應的規則。
最終咱們但願這個平臺可以達到的目的是:隨時隨地以低成本實現全鏈路壓測;對於運維平臺能夠進行週期性的故障演練,並把這種能力給運維團隊,讓他們隨時隨地發起變動;爲整個上線活動包括大促作一些兜底,能夠避免突發活動擊穿。由於長期固化生產壓測會爲咱們帶來容量和水位的極限,在演練過程當中進行預案的實施,突發過程當中會有更好的手段去避免,去作防禦。
以阿里爲例,如今基本上能夠作到以按月爲主,由於你們知道淘寶每月都有活動,每一年有三個大活動:6.1八、雙十一、雙12。咱們目前能夠作小的演練,以周爲實施單位作 雙十一、雙12 或者 6.18 的大促,並且咱們能夠很清晰的組織 BU 內或者跨 BU 的壓測活動,並可以很明確擴容方案。
下面是咱們給第三方的實施案例。
「四通一達」的案例接入,咱們對他們的系統進行了應用的分解,最開始確認的壓縮場景大概有 4 個,後來經過流量渲染、流量染色、流量跟蹤發現整個染色大概有 23 個,經過線上創建影子表的方式,建完影子表以後經過小規模的流量染色,順着把整個影子庫、影子表的方案接入生產環境,而且在生產壓測過程當中沒有形成任何影響,而且經過咱們壓測的 23 個場景,在去年的 雙11 裏沒有出現任何問題,包括爆倉或者是超單的現象出現。
他們前年作這個事的時候,大概有 50 多我的花費了四個月時間,他們維護了一套單獨環境,這個環境仍是有必定的差異,上線以後仍是出現了訂單積壓的現象,經過咱們作全鏈路壓測了以後,如今基本上一個月時間用了 5 個核心骨幹作了全鏈路壓測,基本上已經具有了隨時上線應用,本身複製,作流量應用、流量染色,測試的週期也是以天爲單位,一個比較小的迭代上線基本上一天到兩天就能夠完成整個線上的性能迴歸。對於大的流量,雙十一、雙12 大促活動基本上一週時間就能夠完成整個主鏈路的性能迴歸,而且徹底能夠評估出目前生產環境的容量,包括擴容、生產環境變動等等這樣的功能。
某美妝行業客戶,全部的系統基本上是由第三方開發的,沒有作過性能評估,基本什麼都不知道,最關鍵的問題在於更換的幾回第三方致使整個應用比較複雜,出現的問題是下線一個功能致使整個系統崩潰不能用。咱們評估了一下,每一單成交以後硬件成本大概是 0.18 元,正好我在 2012 年就在淘寶作壓測,他們這個指標大概是 2014 年淘寶花費的 9-10 倍,最關鍵的問題在於他們還有不少未知的風險,好比說他們上線了一個新應用,想作一個推廣,結果直接出了故障,致使秒殺系統崩潰了,基本上那個推廣活動沒有起到任何效果。
咱們大概用一個多月的時間幫他們作線上環境,給他們梳理了 22 個核心鏈路,22 個系統,大概 600 多臺服務器,咱們花費的時間,第一個生產鏈路建設的時間比較長,大概花了半個月左右的時間,後續是他們本身實施的,總共 22 條鏈路花了 55 天時間,把整個操做系統線上的容量所有釐清,在整個過程當中咱們沒有對生產環節的數據作污染,包括整個日誌作了日誌的隔離。在整個過程當中咱們本着共建的態度,幫助客戶創建了平常線上壓測的迴歸機制。
從短時間收益來看,可能咱們對應用的服務器數量作了一些調整,把有些服務器從收益比較低的鏈路調整到收益比較高的鏈路上,最終把他們整個資源的消耗率降到了 20% 左右,而且咱們作了全鏈路壓測以後,給他們作了一個基線,他們每次以這個基線爲基礎作性能的迭代。
目前他們已經徹底掌握了整個生產環境壓測的流程,每次上線基本上均可以按照本身的規劃來作。他們今年的目標是要把整個服務器的資源下降至少 50% 左右,如今也正在爲此而努力。
解決方案諮詢技術交流羣:搜索釘釘羣號 31704055 加入釘釘羣,可獲取雲原生詳細解決方案資料與專家答疑。
本文內容由阿里雲實名註冊用戶自發貢獻,版權歸原做者全部,阿里雲開發者社區不擁有其著做權,亦不承擔相應法律責任。具體規則請查看《阿里雲開發者社區用戶服務協議》和《阿里雲開發者社區知識產權保護指引》。若是您發現本社區中有涉嫌抄襲的內容,填寫侵權投訴表單進行舉報,一經查實,本社區將馬上刪除涉嫌侵權內容。