隨著持續(xù)集成，持續(xù)交付等理念的傳播，很多軟件開發(fā)團隊都搭建了自己的staging、UAT等類生產環(huán)境。這些環(huán)境的軟硬件及網絡配置會盡量貼近真實的生產環(huán)境，起到沙盤演練的作用。

類生產環(huán)境畢竟前面還有一個類字，沙盤畢竟不是真實的戰(zhàn)場，盡量貼近畢竟還不是完全吻合。

類生產環(huán)境與真實生產環(huán)境的一個重要差異就是訪問量。稍具規(guī)模的互聯(lián)網應用每天幾百萬訪問量是很正常的，而類生產環(huán)境的訪問量一般都會相形見絀。

有各種工具可以彌合這個差異，比如Apache JMeter，Gatling。測試人員可以和開發(fā)人員一起設計測試用例，以自動化或者半自動化的方式對類生產環(huán)境進行壓力測試。

不過即便是精心設計出來的用例也還是用例，不是真實請求。真實請求具有多樣性，會隨著晝夜交替而變化，會隨著時事熱點而波動，這是很難用工具模擬出來的。

這就引出了這篇文章的主角-影子流量(shadow traffic)。

簡言之，影子流量(shadow traffic)就是將發(fā)給生產環(huán)境的請求復制一份轉發(fā)到類生產環(huán)境上去，以此來達到壓力測試和正確性測試的目的。

這就如同把真實戰(zhàn)場上的敵方炮火投放到演習場里去。

[[250046]]

一、實現(xiàn)方式

Shadow traffic通常有兩種實現(xiàn)方式：服務端實現(xiàn)，客戶端實現(xiàn)。

下圖描述的是服務端實現(xiàn)的簡化示例。

生產環(huán)境接收到來自于用戶或者是上游系統(tǒng)的請求，在響應該請求的同時，將這個請求原封不動的也發(fā)送給類生產環(huán)境。

下圖描述的是客戶端的實現(xiàn)。

客戶設備或者上游系統(tǒng)在發(fā)給生產環(huán)境請求的同時，給類生產環(huán)境也發(fā)送一個一模一樣的請求。

這兩種實現(xiàn)方式各有優(yōu)劣，放到服務端做可以減少客戶端設備的流量消耗，這一點對于移動應用很重要。

客戶端的實現(xiàn)則較簡單，通常只需要幾行代碼即可。如果后端架構較復雜，則可以選擇前端實現(xiàn)。

無論前端還是后端實現(xiàn)，都需要遵循發(fā)射后不管(fire and forget)的原則，以免阻塞正常流程或者增加響應時間。

1. 適用場景

籠統(tǒng)來說，shadow traffic可以適用于所有互聯(lián)網應用。而在以下場景中，shadow traffic的作用格外明顯：

• 要用新系統(tǒng)替換掉老舊系統(tǒng)
• 系統(tǒng)經歷了大規(guī)模改造，直接上線面對客戶風險較大
• 系統(tǒng)更新，需要提供向后兼容性
• 試驗性質的架構調整

在以上場景運用shadow traffic，可以在不影響終端用戶的情況下完成驗證與測試。

2. 啟用時機

在上線之前一段時間集中地進行測試固然是一種可行的方式，不過我個人更傾向于在項目運轉的早期引入shadow traffic。

這樣做可以讓開發(fā)團隊盡早的并且持續(xù)的接觸到真實的外界壓力。相當于用一種成本并不怎么高的方式構建出了具有產品運維經驗的開發(fā)團隊。

二、配套機制

Shadow traffic的原理和實現(xiàn)方式并不深奧，但要讓它發(fā)揮出應有的價值還需要一些前期工作的配合。

1. 基礎設施監(jiān)控

要了解系統(tǒng)的表現(xiàn)，基礎設施監(jiān)控是必不可少的。

上圖是我所經歷過的一個項目的可視化監(jiān)控界面。監(jiān)控范圍涵蓋了docker container的數(shù)量，請求數(shù)量，響應時間，以4或者5打頭的HTTP狀態(tài)碼的數(shù)量，網絡、內存、CPU用量等等。

通過如上的可視化圖表，開發(fā)團隊可以實時得到反饋。

2. 日志

基礎設施監(jiān)控可以提供一個外部視角，日志則能夠窺見應用內部。

日志可以幫助開發(fā)團隊定位shadow traffic中發(fā)現(xiàn)的問題，shadow traffic也可以促使開發(fā)團隊提升日志的質量。這二者可以起到雙向的積極促進作用。

3. 下游系統(tǒng)的配合

如果一個系統(tǒng)開啟了shadow traffic，可以想見它的下游系統(tǒng)所面對的壓力也會陡升。

這時有必要與下游系統(tǒng)負責團隊做好事先溝通。

三、用法變式

Shadow traffic并非是一成不變的技術實踐，可以按需微調。

1. 請求挑取

并非每一個請求都有被轉發(fā)的必要?？梢詢?yōu)先選取流量大或者業(yè)務價值高的請求。

2. 流量控制

如果想做極限壓力測試，可以把每一個請求重復發(fā)送多次給類生產環(huán)境。

當然也可以只挑取10%的請求來發(fā)送給類生產環(huán)境，隨著團隊信心的提升而逐步升高。

3. 重播

可以截取并保存每天尖峰時刻的請求，在其他時段反復重播。

這種考驗可以有效的鍛煉團隊的心理素質，并促使團隊形成應急預案。

四、小結

如果明天要上線，今天會是一個讓人惴惴不安的日子。

系統(tǒng)性能表現(xiàn)如何?會不會有奇形怪狀的用戶行為導致系統(tǒng)異常?與上下游系統(tǒng)的銜接會不會出現(xiàn)問題?

這些問題的答案，可以通過測試人員的精心模擬來尋找。但仍難免會掛一漏萬。

啟用shadow traffic，如果開發(fā)團隊可以習慣于有shadow traffic的日常，也就具有了應對線上運維問題的能力。

【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉載請聯(lián)系原作者】

戳這里，看該作者更多好文