為什么暫存環境是微服務測試的瓶頸
通過擺脫共享環境，團隊可以并行測試，從而實現更快、更高質量的發布。
譯自Why Staging Is a Bottleneck for Microservice Testing，作者 Arjun Iyer。
采用微服務架構的工程團隊的典型 CI/CD 工作流程如下：
- 在合并拉取請求 (PR) 之前構建并運行基本的單元測試。
- 合并 PR 后，CI/CD 管道將構建部署到共享暫存環境。
- 集成和端到端 (E2E) 測試在此環境中運行，通常按批次安排。
對于每個微服務，每天可能會有多次部署到暫存環境。雖然這種設置已成為常態，但共享暫存環境通常會造成瓶頸，從而減緩團隊速度并削弱微服務的優勢。讓我們深入了解為什么會發生這種情況，以及領先的工程團隊如何超越暫存環境來有效地擴展測試。
共享暫存環境的脆弱性
- 一個 PR，多個問題: 當一個團隊將帶有錯誤的 PR 部署到暫存環境時，它可能會擾亂整個工程團隊。在共享暫存環境中，這個問題會加劇，因為來自一個團隊的錯誤可能會阻止多個其他團隊。
- 尋找有問題的 PR 就像大海撈針: 每天合并數百個 PR，找到導致環境崩潰的那個 PR 非常耗時。
- 測試失敗含糊不清: 微服務之間的依賴關系使得隔離測試失敗的原因變得很困難。例如，考慮以下電子商務微服務架構：
來源：DeathStarBench，一個用于云微服務的開源基準測試套件
在這個架構中，多個服務（如支付、訂單、運輸和媒體）相互交互。一個服務（如支付服務）的故障可能不會立即顯現，并可能表現為訂單服務中的問題。這些相互依賴關系使得難以確定測試失敗的根本原因，尤其是在涉及多個服務時。調試這種復雜的微服務網絡中的故障非常耗時，因為每個服務可能都有不同的團隊負責維護它。
- 功能測試變成等待游戲: 多個團隊經常等待輪到他們在暫存環境中測試功能。這會造成瓶頸。團隊之間共享資源的壓力會嚴重延遲發布，因為他們爭奪對暫存環境的訪問權限。嘗試在本地機器上啟動整個堆棧以進行測試的開發人員會遇到類似的問題。正如分布式系統工程師 Cindy Sridharan 指出，“我現在認為，無論是在初創公司還是在大公司，嘗試在開發人員的筆記本電腦上啟動整個堆棧從根本上來說是錯誤的思維方式。” 微服務的復雜性使得在本地復制整個環境變得不切實際，就像在規模上維護共享暫存環境很困難一樣。
- 來自計劃測試的延遲反饋: 自動化測試通常安排在非高峰時段，例如夜間運行。當檢測到故障時，可能已經部署了多個 PR，這使得追蹤有問題的代碼變得更加困難。這會延遲反饋循環，并對生產力造成“時間稅”。
連鎖反應：減緩工程速度，降低質量
這些問題會導致開發人員生產力大幅下降。CI/CD 管道中的瓶頸會導致他們花費更多時間調試而不是編碼。如果您的工程團隊每月因暫存環境相關問題而損失數天時間，這對您的速度和士氣都是一個嚴重的打擊。
從發布流程的角度來看，脆弱的暫存環境造成的延遲會導致功能和補丁發布速度變慢。當團隊花費更多時間修復暫存環境問題而不是構建新功能時，產品開發速度會變慢。在快速發展的行業中，這可能是一個主要的競爭劣勢。
如果您的發布流程很痛苦，您發布的頻率就會降低，生產環境中錯誤的成本也會更高。這種放緩也會影響產品質量，因為工程師在壓力下為了趕上截止日期，可能會跳過添加新的測試用例。結果是什么？錯誤會進入生產環境。例如，對于電子商務公司來說，即使是微不足道的錯誤也會擾亂結賬流程，導致收入損失和品牌受損。
最后，還有對開發人員體驗的影響。開發人員在能夠快速高效地發布代碼的環境中茁壯成長。發布流程中的摩擦會讓開發人員感到沮喪，增加倦怠和人員流動。快樂的開發人員編寫更好的代碼，而無摩擦的發布流程是實現這一目標的關鍵。
為什么暫存環境會崩潰：爭用問題
共享預發布環境的核心問題在于競爭。團隊無法安全地隔離測試他們的更改。這種隔離的缺乏會導致瓶頸，阻礙團隊有效地驗證他們的工作。
正如 Sridharan 恰如其分地指出：
Sridharan 的引言
預發布環境是針對單體應用程序設計的，而不是針對微服務的動態、分散的性質。
一種天真的方法可能是創建更多預發布環境，但這也不能很好地擴展。管理多個環境會帶來更多復雜性，正如“環境復制不適用于微服務”中所述，跨微服務準確地復制環境極其困難且成本高昂。
更好的方法：隔離測試
那么解決方案是什么？一些最具創新性的科技公司——如 Uber、Lyft 和 DoorDash——已經放棄了共享預發布環境。他們開發了通過沙盒服務和使用動態流量路由來隔離測試的方法。
正如Lyft 博客文章關于預發布覆蓋的說明：
“我們從根本上改變了隔離模型的方法：我們不是提供完全隔離的環境，而是在共享環境中隔離請求。”
通過隔離微服務更改，團隊可以避免競爭并獨立測試代碼。這種隔離測試模型消除了共享環境帶來的問題，并實現了真正的持續交付。隔離測試允許團隊在開發周期的早期發現問題，降低了后期修復錯誤的復雜性和成本。
隔離測試的實際應用
構建內部系統以實現這種級別的隔離在技術上可能很復雜且成本高昂。但是，像Signadot這樣的平臺提供了解決方案，可以大規模提供隔離的測試環境。得益于沙盒和流量路由，團隊可以安全高效地測試微服務，而無需傳統的預發布環境。
結論：微服務測試的未來
預發布環境非常適合單體應用程序，但對于當今的微服務架構來說已經過時了。隨著工程團隊的規模擴大，共享環境會帶來代價高昂的延遲，降低質量并讓開發人員感到沮喪。
微服務測試的未來在于隔離測試。通過放棄共享環境，團隊可以并行測試，從而實現更快、更高質量的發布。在一個速度、質量和開發人員幸福至關重要的世界里，隔離測試不僅僅是錦上添花——它是必不可少的。
