通過擺脫共享環(huán)境，團(tuán)隊可以并行測試，從而實現(xiàn)更快、更高質(zhì)量的發(fā)布。

譯自Why Staging Is a Bottleneck for Microservice Testing，作者 Arjun Iyer。

采用微服務(wù)架構(gòu)的工程團(tuán)隊的典型 CI/CD 工作流程如下：

1. 在合并拉取請求 (PR) 之前構(gòu)建并運(yùn)行基本的單元測試。
2. 合并 PR 后，CI/CD 管道將構(gòu)建部署到共享暫存環(huán)境。
3. 集成和端到端 (E2E) 測試在此環(huán)境中運(yùn)行，通常按批次安排。

對于每個微服務(wù)，每天可能會有多次部署到暫存環(huán)境。雖然這種設(shè)置已成為常態(tài)，但共享暫存環(huán)境通常會造成瓶頸，從而減緩團(tuán)隊速度并削弱微服務(wù)的優(yōu)勢。讓我們深入了解為什么會發(fā)生這種情況，以及領(lǐng)先的工程團(tuán)隊如何超越暫存環(huán)境來有效地擴(kuò)展測試。

共享暫存環(huán)境的脆弱性

1. 一個 PR，多個問題: 當(dāng)一個團(tuán)隊將帶有錯誤的 PR 部署到暫存環(huán)境時，它可能會擾亂整個工程團(tuán)隊。在共享暫存環(huán)境中，這個問題會加劇，因為來自一個團(tuán)隊的錯誤可能會阻止多個其他團(tuán)隊。
2. 尋找有問題的 PR 就像大海撈針: 每天合并數(shù)百個 PR，找到導(dǎo)致環(huán)境崩潰的那個 PR 非常耗時。
3. 測試失敗含糊不清: 微服務(wù)之間的依賴關(guān)系使得隔離測試失敗的原因變得很困難。例如，考慮以下電子商務(wù)微服務(wù)架構(gòu)：

來源：DeathStarBench，一個用于云微服務(wù)的開源基準(zhǔn)測試套件

在這個架構(gòu)中，多個服務(wù)（如支付、訂單、運(yùn)輸和媒體）相互交互。一個服務(wù)（如支付服務(wù)）的故障可能不會立即顯現(xiàn)，并可能表現(xiàn)為訂單服務(wù)中的問題。這些相互依賴關(guān)系使得難以確定測試失敗的根本原因，尤其是在涉及多個服務(wù)時。調(diào)試這種復(fù)雜的微服務(wù)網(wǎng)絡(luò)中的故障非常耗時，因為每個服務(wù)可能都有不同的團(tuán)隊負(fù)責(zé)維護(hù)它。

4. 功能測試變成等待游戲: 多個團(tuán)隊經(jīng)常等待輪到他們在暫存環(huán)境中測試功能。這會造成瓶頸。團(tuán)隊之間共享資源的壓力會嚴(yán)重延遲發(fā)布，因為他們爭奪對暫存環(huán)境的訪問權(quán)限。嘗試在本地機(jī)器上啟動整個堆棧以進(jìn)行測試的開發(fā)人員會遇到類似的問題。正如分布式系統(tǒng)工程師 Cindy Sridharan 指出，“我現(xiàn)在認(rèn)為，無論是在初創(chuàng)公司還是在大公司，嘗試在開發(fā)人員的筆記本電腦上啟動整個堆棧從根本上來說是錯誤的思維方式?！?微服務(wù)的復(fù)雜性使得在本地復(fù)制整個環(huán)境變得不切實際，就像在規(guī)模上維護(hù)共享暫存環(huán)境很困難一樣。
5. 來自計劃測試的延遲反饋: 自動化測試通常安排在非高峰時段，例如夜間運(yùn)行。當(dāng)檢測到故障時，可能已經(jīng)部署了多個 PR，這使得追蹤有問題的代碼變得更加困難。這會延遲反饋循環(huán)，并對生產(chǎn)力造成“時間稅”。

連鎖反應(yīng)：減緩工程速度，降低質(zhì)量

這些問題會導(dǎo)致開發(fā)人員生產(chǎn)力大幅下降。CI/CD 管道中的瓶頸會導(dǎo)致他們花費(fèi)更多時間調(diào)試而不是編碼。如果您的工程團(tuán)隊每月因暫存環(huán)境相關(guān)問題而損失數(shù)天時間，這對您的速度和士氣都是一個嚴(yán)重的打擊。

從發(fā)布流程的角度來看，脆弱的暫存環(huán)境造成的延遲會導(dǎo)致功能和補(bǔ)丁發(fā)布速度變慢。當(dāng)團(tuán)隊花費(fèi)更多時間修復(fù)暫存環(huán)境問題而不是構(gòu)建新功能時，產(chǎn)品開發(fā)速度會變慢。在快速發(fā)展的行業(yè)中，這可能是一個主要的競爭劣勢。

如果您的發(fā)布流程很痛苦，您發(fā)布的頻率就會降低，生產(chǎn)環(huán)境中錯誤的成本也會更高。這種放緩也會影響產(chǎn)品質(zhì)量，因為工程師在壓力下為了趕上截止日期，可能會跳過添加新的測試用例。結(jié)果是什么？錯誤會進(jìn)入生產(chǎn)環(huán)境。例如，對于電子商務(wù)公司來說，即使是微不足道的錯誤也會擾亂結(jié)賬流程，導(dǎo)致收入損失和品牌受損。

最后，還有對開發(fā)人員體驗的影響。開發(fā)人員在能夠快速高效地發(fā)布代碼的環(huán)境中茁壯成長。發(fā)布流程中的摩擦?xí)岄_發(fā)人員感到沮喪，增加倦怠和人員流動?？鞓返拈_發(fā)人員編寫更好的代碼，而無摩擦的發(fā)布流程是實現(xiàn)這一目標(biāo)的關(guān)鍵。

為什么暫存環(huán)境會崩潰：爭用問題

共享預(yù)發(fā)布環(huán)境的核心問題在于競爭。團(tuán)隊無法安全地隔離測試他們的更改。這種隔離的缺乏會導(dǎo)致瓶頸，阻礙團(tuán)隊有效地驗證他們的工作。

正如 Sridharan 恰如其分地指出：

Sridharan 的引言

預(yù)發(fā)布環(huán)境是針對單體應(yīng)用程序設(shè)計的，而不是針對微服務(wù)的動態(tài)、分散的性質(zhì)。

一種天真的方法可能是創(chuàng)建更多預(yù)發(fā)布環(huán)境，但這也不能很好地擴(kuò)展。管理多個環(huán)境會帶來更多復(fù)雜性，正如“環(huán)境復(fù)制不適用于微服務(wù)”中所述，跨微服務(wù)準(zhǔn)確地復(fù)制環(huán)境極其困難且成本高昂。

更好的方法：隔離測試

那么解決方案是什么？一些最具創(chuàng)新性的科技公司——如 Uber、Lyft 和 DoorDash——已經(jīng)放棄了共享預(yù)發(fā)布環(huán)境。他們開發(fā)了通過沙盒服務(wù)和使用動態(tài)流量路由來隔離測試的方法。

正如Lyft 博客文章關(guān)于預(yù)發(fā)布覆蓋的說明：

“我們從根本上改變了隔離模型的方法：我們不是提供完全隔離的環(huán)境，而是在共享環(huán)境中隔離請求。”

通過隔離微服務(wù)更改，團(tuán)隊可以避免競爭并獨(dú)立測試代碼。這種隔離測試模型消除了共享環(huán)境帶來的問題，并實現(xiàn)了真正的持續(xù)交付。隔離測試允許團(tuán)隊在開發(fā)周期的早期發(fā)現(xiàn)問題，降低了后期修復(fù)錯誤的復(fù)雜性和成本。

隔離測試的實際應(yīng)用

構(gòu)建內(nèi)部系統(tǒng)以實現(xiàn)這種級別的隔離在技術(shù)上可能很復(fù)雜且成本高昂。但是，像Signadot這樣的平臺提供了解決方案，可以大規(guī)模提供隔離的測試環(huán)境。得益于沙盒和流量路由，團(tuán)隊可以安全高效地測試微服務(wù)，而無需傳統(tǒng)的預(yù)發(fā)布環(huán)境。

結(jié)論：微服務(wù)測試的未來

預(yù)發(fā)布環(huán)境非常適合單體應(yīng)用程序，但對于當(dāng)今的微服務(wù)架構(gòu)來說已經(jīng)過時了。隨著工程團(tuán)隊的規(guī)模擴(kuò)大，共享環(huán)境會帶來代價高昂的延遲，降低質(zhì)量并讓開發(fā)人員感到沮喪。

微服務(wù)測試的未來在于隔離測試。通過放棄共享環(huán)境，團(tuán)隊可以并行測試，從而實現(xiàn)更快、更高質(zhì)量的發(fā)布。在一個速度、質(zhì)量和開發(fā)人員幸福至關(guān)重要的世界里，隔離測試不僅僅是錦上添花——它是必不可少的。