點擊上方“朱小廝的博客”，選擇“設為星標”

后臺回復"書"，獲取

后臺回復“k8s”，可領取k8s資料

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

本文分四個方面為大家闡述：第一，整個全鏈路壓測的意義，為什么要在生產環節上做全鏈路壓測；第二，關于落地的技術點和解決方案；第三，生產過程中做全鏈路壓測流程上的建議，考慮到每個組織的承受度不一樣，給大家提供一些建議；第四，如何在第三方實現整個在生產環境中做業務連續性包括壓測的結果。

全鏈路壓測的意義?

ALIWARE

上圖顯示了三個問題，實際上是不同的 IT 組織在和測試交流的時候，這三個問題是比較有代表性的。

1. 很多測試同行說他們線下也做過性能測試，但是到了線上之后還是存在很多問題，因為不太可能會在線下模擬一個跟線上 1：1 的環境。在有很多第三方接口的情況下，大家也很少會去模擬線上整個場景。因此我們在線下做了很多測試工作后，總結出了為什么很多從線下容量推導到線上容量的公司卻最終效果不是很好，就是這樣的原因。

2. 現在所有的 IT 組織都在搞 DevOps，我們的功能從一個月迭代一次到現在一周迭代一次，留給測試的時間越來越短。功能測試時間從之前的一周、兩周縮短到現在三四天、兩三天的時間，那性能測試就沒有辦法按時上線，很有可能會出現各種各樣的性能問題，這會直接影響到企業的品牌影響力。

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

什么是脆弱？脆弱就像玻璃，大家知道玻璃很脆易碎。脆弱的反義詞是什么？不是強韌也不是堅韌，可能是反脆弱。什么是反脆弱呢？比如乒乓球，大家知道乒乓球在地上不用很大的力就可以破壞掉，踩一腳就破壞掉了，但是高速運動的情況下，乒乓球我們施加的力度越大，它的反彈力度越大，說明乒乓球在運動過程中有反脆弱的特性。

我們的 IT 系統實際上也是這樣的。不管什么代碼都不能保證是完全沒有問題的，我們的基礎設施可能也是脆弱的，像服務器、數據庫等總會有局限。我們的框架也總是脆弱的，將這些問題綜合在一起，我們希望通過某些手段，比如通過預案、風險的識別，或者通過一些熔斷的手段，最終把這些東西組合在一起，讓整個 IT 系統有反脆弱的特性。總之，我們希望通過一些手段使得 IT 系統有足夠的冗余，而且有足夠多的預案應對突發的不確定性風險。

如何打造 IT 系統反脆弱能力呢？我們希望通過一些手段，比如說像線上的壓測能力，提供不確定的因素，接著通過在這個過程中實時監控，包括預案的能力，最終把這些不確定性的因素識別出來，并且在線上生產壓測過程中對它做一些處理，更多可能會通過事后復盤等方式，做到對不確定性因素的識別。接著我們可能會在生產環境中通過之前的手段，在生產環境上做一個穩定性的常態化壓測，實現長期穩定的場景，最終我們可能達到反脆弱能力所需要的整體監控的能力、運營防護能力，以及管控路由能力，這會讓整個 IT 系統具備反脆弱的特性。

全鏈路壓測解決方案

ALIWARE

如何在生產環境上做全鏈路壓測？它需要用到哪些技術手段？

1

壓測進程演變

一般情況下，測試是怎么樣從線下一點點往線上演變的？我把它分為四個階段：

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

2. 我們成立了一個類似于測試實驗室或者測試組織的機構，這樣一個大的部門可能會構造出一批類似于生產環境的性能測試環境，在這上面我們可能會做更多的事情，比如說做一個線下環境的全鏈路壓測，并且我們可以根據之前積累的經驗在上面做一些線下的回歸，包括性能的診斷等。其實這一步相當于整個測試往前再走一步，對測試環境中的鏈路做一些分析，在上面演變一些能力，比如說風險的控制等等。

3. 目前絕大部分 IT 企業和互聯網企業愿意嘗試線上生產環境的業務壓測。這部分實際上和之前的第二階段相差不多，但是在這個過程中人為的把它分為了兩層：第一層是單純的做全鏈路壓測，很多 IT 公司已經在非生產環節中做了只讀業務的壓測，因為這樣不會對數據造成污染。而再往下一層?，有些組織可能會在正常生產時段中做進一步的全鏈路壓測，這種情況下我們就會要求這個組織擁有更高的能力。

比如說我們需要對整個壓測流量做一些染色，能夠區分出來正常的業務數據，正常的流量和非正常的壓測流量，可能有的會做一些環境的隔離，而在業務生產期間內我們做生產的壓測，需要考慮到整個流量的偏移、限流，包括熔斷機制等。不管怎樣做業務，可能都會對最終的生產業務造成一定的影響，真正出現問題的時候可能需要有快速的熔斷機制。

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

2

全鏈路壓測關鍵技術

對于整個全鏈路壓測來說，我們需要幾個關鍵的技術：

• 全鏈路流量染色

可能通過在壓縮機上做一些標識，比如加一個后綴，或者通過一些標識手段把流量讀出來，分散到相關的表里去。同時在全鏈路流量展示過程中我們還需要做流量的識別，對于壓測流量經過的每一個中間件，每一個服務我們都希望能夠準確的識別出來，這個流量是來自于壓測機還是來自于正常流量，這是第一步。

• 全鏈路的數據隔離

我們需要通過哪些手段，比如通過影子庫，通過運維的同學做一個和生產上面同樣的影子庫，然后切到影子庫上，或者在生產庫上做一個相同的影子表，來做數據隔離。第一種方式安全度高一些，但是缺點在于我們用影子庫的時候整個生產環境是不可用的。生產影子庫不能完全模擬出整個線上的情況，因為影子表需要我們有更高的技術水平，能夠保障整個鏈路可追蹤，包括整個數據如果一旦出錯數據恢復能力等等。

• 全鏈路風險管控機制

也就是風險熔斷機制，一旦真的發現生產環境的線上壓測對我們的業務造成了影響，我們需要通過一些規則或者其他的指標來自動觸發風險熔斷，包括管控等等這樣的手段，不管是提供施壓機的流量，還是把生產系統損壞的部分做業務隔離，這樣的手段都是我們做生產過程中全鏈路壓測的必要手段。

• 全鏈路日志日志隔離

其實日志本身不會對全鏈路造成太大的影響，但是因為做數字化水平的提升，日志基本上是BI同學包括運營的同學對整個業務分析最重要的數據來源，如果我們不做日志隔離很有可能會對 BI 決策造成一定的影響，比如壓測過程中我們會大量采用某個地域的流量對生產環境做訪問，BI 的同學可能會通過日志分析發現某一個地區做大，導致他錯誤的運營決策，所以說對于生產過程中的全鏈路壓測來說，我們需要在整個生產過程中做一定的日志隔離，區分出來正常的生產流量和壓測流量之間的存儲。

3

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

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

1. 首先是有來自于全地域的壓測流量工具，這個流量工具具備的功能包括全地域流量挖掘、流量改造相關的功能。

2. 整個壓測識別，包括影子存儲一部分的功能。黃色的部分是正常流量，藍色的部分是壓測的流量，我們可能通過施壓機的改造讓藍色的部分加入一些標識，通過 Agent 的技術，它可以標識出帶有的流量，通過底層的 Agent 技術將這些落到相應的影子庫或者影子表里去，或者是緩存的影子區里。

3. 做熔斷的規則管理，所以需要有合理的控制臺，這里可能會做一些安裝探針管理，包括整個架構的管理、庫表的維護、規則的維護、熔斷機制的維護等。

4. 最后是真正的施壓部分。這里可能會安裝一些探針或者是 Agent，這些 Agent 的作用是能夠讓這些流量落到相應的影子表里去，還有是通過相應的監控指標，比如說我們的錯誤達到 1%，或者是檢查時間超過了一定的閾值之后，Agent 會及時上報，通過規則配置起到限流的作用。

通過這套架構，我們現在可以做到目前比按照整體環境大約節省成本是 40%左右，基本上對整個生產業務沒有任何切入。

4

全鏈路壓測風險防控能力

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

橙色的部分是真正的壓測流量，這部分我們會在施壓機上做一個標識，現在是會加一個后綴。另外還會在服務器做 filter，它其實是攔截器，我們會攔截到流量里面相關的標識，然后把它做區分、做染色，并且做跟蹤，每一個請求基本上可以真正做到在任何中間件以及項目堆里都是透明可見的。

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

通過這樣的方式，目前絕大部分 IT 組織是分三個階段，當然有一些非常成熟的是分為兩個階段：

1. 在上線之前發現問題，大多是由線下的開發或者測試調試過程中發現問題，然后做到整個接口的優化，確保最后沒有代碼的問題，包括 DNS 問題。這類問題基本上是在線下的環境，開發的環境解決掉。

2. 在部署過程中，我們會做第三方插件比如安全等等問題，但是目前隨著容器的發展，開發部署環境會被逐漸淡化掉。

3. 在線上真正做生產環境的壓測，這部分可能會做容量規劃或者是壓測，其他像整個大環境，比如說 CDN 或者 DNS問題，或者是整個線上系統容量評估等等問題。

這些是我們目前在整個測試生命周期里希望在各個階段實現的目的。

壓測流程的建議

ALIWARE

考慮到各個組織的成熟度不一樣，我們提供的這些建議不一定適用于所有的 IT 組織，但大家可以根據自身情況參考一下。

我們一般為第三方實施全鏈路壓測，線上生產壓測，會經歷五個階段：

首先是和第三方一起梳理業務的階段，我們會做以下幾件事情：

1.根據過往系統使用情況評估業務系統的性能指標、容量指標；

2.對現有信息系統做系統架構的梳理，確定整個被染色流量的路徑途徑；

3.對壓測時長，包括間隔等做溝通，確認相關的壓測場景設計；

4.生產數據脫敏，如果有一部分涉及到生產數據可能會做生產數據的脫敏等相關工作。

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

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

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

五是對于整個活動做復盤，看應急預案是否生效，還有哪些地方需要優化，這是生產環節全鏈路壓測的生命周期。

我們現在做一些更深入的東西，整個開發過程中，目前大家都使用 DevOps，可能單接口的性能測試在過程中就已經用到了，目前我們給企業打造的都包含了接口級別的單機性能測試，使用單機測試工具，在發布過程中開始驗收單接口的性能問題，保證這個接口發到線上不會有代碼級別錯誤，最終會省掉集成壓測包括測試環境中壓測的步驟，直接走到線上壓測這個過程。單接口階段我們會支持相應主流的框架壓測，目前我們也在不斷做測試環境集群的壓測支持，還是希望直接用戶跳過這個步驟開始在線上直接做流量隔離的壓測。

上圖是我們認為一個完整的業務連續性平臺需要的功能。

1.壓測流量發起的控制臺，流量發起端，這塊實際上是管理整個壓測流量和場景設計；

2.流量隔離控制臺，這部分希望能夠做到統一切流，當出現問題的時候可以一下把壓測流量切掉，統一路由；

3.壓測過程中有整個流量監控包括系統監控；壓測過程中對于整個應用的性能監控平臺，包括鏈路監控、JVM 監控、組件監控等等；

4.真正的混沌工程，包括流控規則、隔離規則、降級規則等等平臺，這里會維護相應的規則。

最終我們希望這個平臺能夠達到的目的是：隨時隨地以低成本實現全鏈路壓測；對于運維平臺可以進行周期性的故障演練，并把這種能力給運維團隊，讓他們隨時隨地發起變更；為整個上線活動包括大促做一些兜底，可以避免突發活動擊穿。因為長期固化生產壓測會為我們帶來容量和水位的極限，在演練過程中進行預案的實施，突發過程中會有更好的手段去避免，去做防護。

以阿里為例，現在基本上可以做到以按月為主，因為大家知道淘寶每個月都有活動，每年有三個大活動：6.18、雙11、雙12。我們目前可以做小的演練，以周為實施單位做 雙11、雙12 或者 6.18 的大促，而且我們可以很清晰的組織 BU 內或者跨 BU 的壓測活動，并能夠很明確擴容方案。

客戶案例

ALIWARE

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

• 案例一

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

他們前年做這個事的時候，大概有 50 多個人花費了四個月時間，他們維護了一套單獨環境，這個環境還是有一定的差別，上線之后還是出現了訂單積壓的現象，通過我們做全鏈路壓測了之后，現在基本上一個月時間用了 5 個核心骨干做了全鏈路壓測，基本上已經具備了隨時上線應用，自己復制，做流量應用、流量染色，測試的周期也是以天為單位，一個比較小的迭代上線基本上一天到兩天就可以完成整個線上的性能回歸。對于大的流量，雙11、雙12 大促活動基本上一周時間就可以完成整個主鏈路的性能回歸，并且完全可以評估出目前生產環境的容量，包括擴容、生產環境變更等等這樣的功能。

• 案例二

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

我們大概用一個多月的時間幫他們做線上環境，給他們梳理了 22 個核心鏈路，22 個系統，大概 600 多臺服務器，我們花費的時間，第一個生產鏈路建設的時間比較長，大概花了半個月左右的時間，后續是他們自己實施的，總共 22 條鏈路花了 55 天時間，把整個操作系統線上的容量全部厘清，在整個過程中我們沒有對生產環節的數據做污染，包括整個日志做了日志的隔離。在整個過程中我們本著共建的態度，幫助客戶建立了日常線上壓測的回歸機制。

從短期收益來看，可能我們對應用的服務器數量做了一些調整，把有些服務器從收益比較低的鏈路調整到收益比較高的鏈路上，最終把他們整個資源的消耗率降到了 20% 左右，并且我們做了全鏈路壓測之后，給他們做了一個基線，他們每次以這個基線為基礎做性能的迭代。

目前他們已經完全掌握了整個生產環境壓測的流程，每次上線基本上都可以按照自己的規劃來做。他們今年的目標是要把整個服務器的資源降低至少 50% 左右，現在也正在為此而努力。

來源：阿里巴巴中間件

想知道更多？掃描下面的二維碼關注我

后臺回復"技術"，加入技術群

后臺回復“k8s”，可領取k8s資料

【精彩推薦】

• ClickHouse到底是什么？為什么如此牛逼！

• 原來ElasticSearch還可以這么理解

• 面試官：InnoDB中一棵B+樹可以存放多少行數據？

• 架構之道：分離業務邏輯和技術細節

• 星巴克不使用兩階段提交

• 面試官：Redis新版本開始引入多線程，談談你的看法？

• 喜馬拉雅自研網關架構演進過程

• 收藏：存儲知識全面總結

• 微博千萬級規模高性能高并發的網絡架構設計

總結

以上是生活随笔為你收集整理的阿里巴巴：全链路压测体系建设方案的思考与实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。