全鏈路壓測體系建設方案的思考與實踐

簡介:在阿里淘寶雙11 的過程當中,長期以來都是在生產環節作全鏈路壓測的,經過實踐咱們發如今生產環境中作壓測,實際上會和一個 IT 組織的結構、成熟度、流程等緊密相關,因此咱們把全鏈路壓測從簡單的製做範圍內脫離出來,變成整個業務連續性的方案。

 title=

在阿里淘寶雙11 的過程當中,長期以來都是在生產環節作全鏈路壓測的,經過實踐咱們發如今生產環境中作壓測,實際上會和一個 IT 組織的結構、成熟度、流程等緊密相關,因此咱們把全鏈路壓測從簡單的製做範圍內脫離出來,變成整個業務連續性的方案。

本文分四個方面爲你們闡述:第一,整個全鏈路壓測的意義,爲何要在生產環節上作全鏈路壓測;第二,關於落地的技術點和解決方案;第三,生產過程當中作全鏈路壓測流程上的建議,考慮到每一個組織的承受度不同,給你們提供一些建議;第四,如何在第三方實現整個在生產環境中作業務連續性包括壓測的結果。
數據庫

全鏈路壓測的意義


 title=

上圖顯示了三個問題,其實是不一樣的 IT 組織在和測試交流的時候,這三個問題是比較有表明性的。
緩存

  1. 不少測試同行說他們線下也作過性能測試,可是到了線上以後仍是存在不少問題,由於不太可能會在線下模擬一個跟線上 1:1 的環境。在有不少第三方接口的狀況下,你們也不多會去模擬線上整個場景。所以咱們在線下作了不少測試工做後,總結出了爲何不少從線下容量推導到線上容量的公司卻最終效果不是很好,就是這樣的緣由。

  1. 如今全部的 IT 組織都在搞 DevOps,咱們的功能從一個月迭代一次到如今一週迭代一次,留給測試的時間愈來愈短。功能測試時間從以前的一週、兩週縮短到如今三四天、兩三天的時間,那性能測試就沒有辦法按時上線,頗有可能會出現各類各樣的性能問題,這會直接影響到企業的品牌影響力。

  1. 平時線上水位比較低,不多達到高峯期,可是會出現一些突發狀況。好比像去年的疫情使得不少公司的業務變成在線業務。好比教育行業,以前是課堂上老師面對面的教育,如今選擇線上在線平臺來作,這類突發的狀況會使測試工程師,包括開發運維團隊受到很大的困擾。在這以前我先介紹一個概念,這個概念是由《黑天鵝》的原做者 Nassim Nicholas Taleb 提出,概念中心是脆弱與反脆弱


 title=

什麼是脆弱?脆弱就像玻璃,你們知道玻璃很脆易碎。脆弱的反義詞是什麼?不是強韌也不是堅韌,多是反脆弱。什麼是反脆弱呢?好比乒乓球,你們知道乒乓球在地上不用很大的力就能夠破壞掉,踩一腳就破壞掉了,可是高速運動的狀況下,乒乓球咱們施加的力度越大,它的反彈力度越大,說明乒乓球在運動過程當中有反脆弱的特性。

咱們的 IT 系統實際上也是這樣的。無論什麼代碼都不能保證是徹底沒有問題的,咱們的基礎設施可能也是脆弱的,像服務器、數據庫等總會有侷限。咱們的框架也老是脆弱的,將這些問題綜合在一塊兒,咱們但願經過某些手段,好比經過預案、風險的識別,或者經過一些熔斷的手段,最終把這些東西組合在一塊兒,讓整個 IT 系統有反脆弱的特性。總之,咱們但願經過一些手段使得 IT 系統有足夠的冗餘,並且有足夠多的預案應對突發的不肯定性風險。

 title=安全

如何打造 IT 系統反脆弱能力呢?咱們但願經過一些手段,好比說像線上的壓測能力,提供不肯定的因素,接着經過在這個過程當中實時監控,包括預案的能力,最終把這些不肯定性的因素識別出來,而且在線上生產壓測過程當中對它作一些處理,更多可能會經過過後覆盤等方式,作到對不肯定性因素的識別。接着咱們可能會在生產環境中經過以前的手段,在生產環境上作一個穩定性的常態化壓測,實現長期穩定的場景,最終咱們可能達到反脆弱能力所須要的總體監控的能力、運營防禦能力,以及管控路由能力,這會讓整個 IT 系統具有反脆弱的特性。
性能優化

全鏈路壓測解決方案


如何在生產環境上作全鏈路壓測?它須要用到哪些技術手段?
服務器

壓測進程演變

 title=

通常狀況下,測試是怎麼樣從線下一點點往線上演變的?我把它分爲四個階段:
架構

  1. 目前絕大多數 IT 能夠作到的是線下單系統壓測,即針對單個接口或者單個場景作壓測,同時也會作系統分析和性能分析。但在複雜的業務場景之下,咱們可能沒辦法去充分發現問題,不少都是由開發或者測試同窗自發進行的活動。

  1. 咱們成立了一個相似於測試實驗室或者測試組織的機構,這樣一個大的部門可能會構造出一批相似於生產環境的性能測試環境,在這上面咱們可能會作更多的事情,好比說作一個線下環境的全鏈路壓測,而且咱們能夠根據以前積累的經驗在上面作一些線下的迴歸,包括性能的診斷等。其實這一步至關於整個測試往前再走一步,對測試環境中的鏈路作一些分析,在上面演變一些能力,好比說風險的控制等等。

  1. 目前絕大部分 IT 企業和互聯網企業願意嘗試線上生產環境的業務壓測。這部分實際上和以前的第二階段相差很少,可是在這個過程當中人爲的把它分爲了兩層:第一層是單純的作全鏈路壓測,不少 IT 公司已經在非生產環節中作了只讀業務的壓測,由於這樣不會對數據形成污染。而再往下一層 ,有些組織可能會在正常生產時段中作進一步的全鏈路壓測,這種狀況下咱們就會要求這個組織擁有更高的能力。


好比說咱們須要對整個壓測流量作一些染色,可以區分出來正常的業務數據,正常的流量和非正常的壓測流量,可能有的會作一些環境的隔離,而在業務生產期間內咱們作生產的壓測,須要考慮到整個流量的偏移、限流,包括熔斷機制等。無論怎樣作業務,可能都會對最終的生產業務形成必定的影響,真正出現問題的時候可能須要有快速的熔斷機制。
框架

  1. 作到壓縮熔斷渲染,包括對熔斷的機制——有了這樣的能力以後,最後一個階段就是整個生產鏈路的全鏈路壓測,包括讀寫,它就具有了基本能力。這個方面咱們其實更多的是經過引入庫表,加上技術手段,在這個生產上作全鏈路壓測,包括讀業務、寫業務等,同時咱們有系統故障演練和生產變動演練的能力,在這種狀況下咱們可能最終具有了數據隔離能力、監控隔離能力和日誌隔離能力。

全鏈路壓測關鍵技術

 title=

對於整個全鏈路壓測來講,咱們須要幾個關鍵的技術:
運維

  • 全鏈路流量染色

可能經過在壓縮機上作一些標識,好比加一個後綴,或者經過一些標識手段把流量讀出來,分散到相關的表裏去。同時在全鏈路流量展現過程當中咱們還須要作流量的識別,對於壓測流量通過的每個中間件,每個服務咱們都但願可以準確的識別出來,這個流量是來自於壓測機仍是來自於正常流量,這是第一步。
工具

  • 全鏈路的數據隔離

咱們須要經過哪些手段,好比經過影子庫,經過運維的同窗作一個和生產上面一樣的影子庫,而後切到影子庫上,或者在生產庫上作一個相同的影子表,來作數據隔離。第一種方式安全度高一些,可是缺點在於咱們用影子庫的時候整個生產環境是不可用的。生產影子庫不能徹底模擬出整個線上的狀況,由於影子表須要咱們有更高的技術水平,可以保障整個鏈路可追蹤,包括整個數據若是一旦出錯數據恢復能力等等。
性能

  • 全鏈路風險管控機制

也就是風險熔斷機制,一旦真的發現生產環境的線上壓測對咱們的業務形成了影響,咱們須要經過一些規則或者其餘的指標來自動觸發風險熔斷,包括管控等等這樣的手段,無論是提供施壓機的流量,仍是把生產系統損壞的部分作業務隔離,這樣的手段都是咱們作生產過程當中全鏈路壓測的必要手段。

  • 全鏈路日誌日誌隔離

其實日誌自己不會對全鏈路形成太大的影響,可是由於作數字化水平的提高,日誌基本上是BI同窗包括運營的同窗對整個業務分析最重要的數據來源,若是咱們不作日誌隔離頗有可能會對 BI 決策形成必定的影響,好比壓測過程當中咱們會大量採用某個地域的流量對生產環境作訪問,BI 的同窗可能會經過日誌分析發現某一個地區作大,致使他錯誤的運營決策,因此說對於生產過程當中的全鏈路壓測來講,咱們須要在整個生產過程當中作必定的日誌隔離,區分出來正常的生產流量和壓測流量之間的存儲。

全鏈路壓測和業務連續性平臺核心功能


 title=

這部分是真正想做爲全鏈路壓測和業務連續性平臺所須要的功能。

  1. 首先是有來自於全地域的壓測流量工具,這個流量工具具有的功能包括全地域流量挖掘、流量改造相關的功能。
  2. 整個壓測識別,包括影子存儲一部分的功能。黃色的部分是正常流量,藍色的部分是壓測的流量,咱們可能經過施壓機的改造讓藍色的部分加入一些標識,經過 Agent 的技術,它能夠標識出帶有的流量,經過底層的 Agent 技術將這些落到相應的影子庫或者影子表裏去,或者是緩存的影子區裏。
  3. 作熔斷的規則管理,因此須要有合理的控制檯,這裏可能會作一些安裝探針管理,包括整個架構的管理、庫表的維護、規則的維護、熔斷機制的維護等。
  4. 最後是真正的施壓部分。這裏可能會安裝一些探針或者是 Agent,這些 Agent 的做用是可以讓這些流量落到相應的影子表裏去,還有是經過相應的監控指標,好比說咱們的錯誤達到 1%,或者是檢查時間超過了必定的閾值以後,Agent 會及時上報,經過規則配置起到限流的做用。


經過這套架構,咱們如今能夠作到目前比按照總體環境大約節省成本是 40%左右,基本上對整個生產業務沒有任何切入。

全鏈路壓測風險防控能力

 title=

下面來具體談一談如何作一個影子數據庫,包括整個流量識別。

橙色的部分是真正的壓測流量,這部分咱們會在施壓機上作一個標識,如今是會加一個後綴。另外還會在服務器作 filter,它實際上是攔截器,咱們會攔截到流量裏面相關的標識,而後把它作區分、作染色,而且作跟蹤,每個請求基本上能夠真正作到在任何中間件以及項目堆裏都是透明可見的。

真正在壓測過程當中經過 Agent 字節碼結束將它直接改寫,將字節的條件替換成壓縮的條件。固然要先把影子庫建好,經過底層的追蹤咱們能夠把相應的流量,若是數據庫就會走得比較明確,以後咱們會作流量的測試,看看是否比較明確,並且咱們能夠作到整個測試數據帶有標識,一旦真的沒有走到診斷裏面去,咱們也能夠在正常的表裏作刪除,而且每個通過的區域對咱們來講都是可見的。

經過這樣的方式,目前絕大部分 IT 組織是分三個階段,固然有一些很是成熟的是分爲兩個階段:

  1. 在上線以前發現問題,大可能是由線下的開發或者測試調試過程當中發現問題,而後作到整個接口的優化,確保最後沒有代碼的問題,包括 DNS 問題。這類問題基本上是在線下的環境,開發的環境解決掉。
  2. 在部署過程當中,咱們會作第三方插件好比安全等等問題,可是目前隨着容器的發展,開發部署環境會被逐漸淡化掉。
  3. 在線上真正作生產環境的壓測,這部分可能會作容量規劃或者是壓測,其餘像整個大環境,好比說 CDN 或者 DNS 問題,或者是整個線上系統容量評估等等問題。


這些是咱們目前在整個測試生命週期裏但願在各個階段實現的目的。

壓測流程的建議


考慮到各個組織的成熟度不同,咱們提供的這些建議不必定適用於全部的 IT 組織,但你們能夠根據自身狀況參考一下。

咱們通常爲第三方實施全鏈路壓測,線上生產壓測,會經歷五個階段:

首先是和第三方一塊兒梳理業務的階段,咱們會作如下幾件事情:

1.根據過往系統使用狀況評估業務系統的性能指標、容量指標;
2.對現有信息系統作系統架構的梳理,肯定整個被染色流量的路徑途徑;
3.對壓測時長,包括間隔等作溝通,確認相關的壓測場景設計;
4.生產數據脫敏,若是有一部分涉及到生產數據可能會作生產數據的脫敏等相關工做。

這部分作完是作第二部分,對某些應用進行改造。好比說作流量打標工做,經過監控的流量肯定業務系統,可能在業務系統裏會作相關監控的接入,相關的第三方組件會進行 Mock,整個壓測場景的建立會和第三方溝通好。包括流量表建設和預案等等接入。

三是整個壓測的過程,整個生產狀態下的全鏈路壓測,會對整個系統進行性能優化及容量評估。

四是將線上全鏈路壓測常態化,這裏面會有一些事情,好比說限流、降級、混沌工程驗收,包括生產發佈的事情。

五是對於整個活動作覆盤,看應急預案是否生效,還有哪些地方須要優化,這是生產環節全鏈路壓測的生命週期。

咱們如今作一些更深刻的東西,整個開發過程當中,目前你們都使用 DevOps,可能單接口的性能測試在過程當中就已經用到了,目前咱們給企業打造的都包含了接口級別的單機性能測試,使用單機測試工具,在發佈過程當中開始驗收單接口的性能問題,保證這個接口發到線上不會有代碼級別錯誤,最終會省掉集成壓測包括測試環境中壓測的步驟,直接走到線上壓測這個過程。單接口階段咱們會支持相應主流的框架壓測,目前咱們也在不斷作測試環境集羣的壓測支持,仍是但願直接用戶跳過這個步驟開始在線上直接作流量隔離的壓測。

 title=

上圖是咱們認爲一個完整的業務連續性平臺須要的功能。

1.壓測流量發起的控制檯,流量發起端,這塊其實是管理整個壓測流量和場景設計;
2.流量隔離控制檯,這部分但願可以作到統一切流,當出現問題的時候能夠一下把壓測流量切掉,統一路由;
3.壓測過程當中有整個流量監控包括系統監控;壓測過程當中對於整個應用的性能監控平臺,包括鏈路監控、JVM 監控、組件監控等等;
4.真正的混沌工程,包括流控規則、隔離規則、降級規則等等平臺,這裏會維護相應的規則。

最終咱們但願這個平臺可以達到的目的是:隨時隨地以低成本實現全鏈路壓測;對於運維平臺能夠進行週期性的故障演練,並把這種能力給運維團隊,讓他們隨時隨地發起變動;爲整個上線活動包括大促作一些兜底,能夠避免突發活動擊穿。由於長期固化生產壓測會爲咱們帶來容量和水位的極限,在演練過程當中進行預案的實施,突發過程當中會有更好的手段去避免,去作防禦。

以阿里爲例,如今基本上能夠作到以按月爲主,由於你們知道淘寶每月都有活動,每一年有三個大活動:6.1八、雙十一、雙12。咱們目前能夠作小的演練,以周爲實施單位作 雙十一、雙12 或者 6.18 的大促,並且咱們能夠很清晰的組織 BU 內或者跨 BU 的壓測活動,並可以很明確擴容方案。

客戶案例


下面是咱們給第三方的實施案例。

案例一

「四通一達」的案例接入,咱們對他們的系統進行了應用的分解,最開始確認的壓縮場景大概有 4 個,後來經過流量渲染、流量染色、流量跟蹤發現整個染色大概有 23 個,經過線上創建影子表的方式,建完影子表以後經過小規模的流量染色,順着把整個影子庫、影子表的方案接入生產環境,而且在生產壓測過程當中沒有形成任何影響,而且經過咱們壓測的 23 個場景,在去年的 雙11 裏沒有出現任何問題,包括爆倉或者是超單的現象出現。

 title=

他們前年作這個事的時候,大概有 50 多我的花費了四個月時間,他們維護了一套單獨環境,這個環境仍是有必定的差異,上線以後仍是出現了訂單積壓的現象,經過咱們作全鏈路壓測了以後,如今基本上一個月時間用了 5 個核心骨幹作了全鏈路壓測,基本上已經具有了隨時上線應用,本身複製,作流量應用、流量染色,測試的週期也是以天爲單位,一個比較小的迭代上線基本上一天到兩天就能夠完成整個線上的性能迴歸。對於大的流量,雙十一、雙12 大促活動基本上一週時間就能夠完成整個主鏈路的性能迴歸,而且徹底能夠評估出目前生產環境的容量,包括擴容、生產環境變動等等這樣的功能。

案例二

某美妝行業客戶,全部的系統基本上是由第三方開發的,沒有作過性能評估,基本什麼都不知道,最關鍵的問題在於更換的幾回第三方致使整個應用比較複雜,出現的問題是下線一個功能致使整個系統崩潰不能用。咱們評估了一下,每一單成交以後硬件成本大概是 0.18 元,正好我在 2012 年就在淘寶作壓測,他們這個指標大概是 2014 年淘寶花費的 9-10 倍,最關鍵的問題在於他們還有不少未知的風險,好比說他們上線了一個新應用,想作一個推廣,結果直接出了故障,致使秒殺系統崩潰了,基本上那個推廣活動沒有起到任何效果。

咱們大概用一個多月的時間幫他們作線上環境,給他們梳理了 22 個核心鏈路,22 個系統,大概 600 多臺服務器,咱們花費的時間,第一個生產鏈路建設的時間比較長,大概花了半個月左右的時間,後續是他們本身實施的,總共 22 條鏈路花了 55 天時間,把整個操做系統線上的容量所有釐清,在整個過程當中咱們沒有對生產環節的數據作污染,包括整個日誌作了日誌的隔離。在整個過程當中咱們本着共建的態度,幫助客戶創建了平常線上壓測的迴歸機制。

 title=

從短時間收益來看,可能咱們對應用的服務器數量作了一些調整,把有些服務器從收益比較低的鏈路調整到收益比較高的鏈路上,最終把他們整個資源的消耗率降到了 20% 左右,而且咱們作了全鏈路壓測以後,給他們作了一個基線,他們每次以這個基線爲基礎作性能的迭代。

目前他們已經徹底掌握了整個生產環境壓測的流程,每次上線基本上均可以按照本身的規劃來作。他們今年的目標是要把整個服務器的資源下降至少 50% 左右,如今也正在爲此而努力。

解決方案諮詢技術交流羣:搜索釘釘羣號 31704055 加入釘釘羣,可獲取雲原生詳細解決方案資料與專家答疑。

本文內容由阿里雲實名註冊用戶自發貢獻,版權歸原做者全部,阿里雲開發者社區不擁有其著做權,亦不承擔相應法律責任。具體規則請查看《阿里雲開發者社區用戶服務協議》和《阿里雲開發者社區知識產權保護指引》。若是您發現本社區中有涉嫌抄襲的內容,填寫侵權投訴表單進行舉報,一經查實,本社區將馬上刪除涉嫌侵權內容。
相關文章
相關標籤/搜索