01

? ?背景

會員業務是公司的重要業務之一，為廣大會員用戶承載最基礎的服務保障，隨著會員數的破億，業務復雜度也是呈現幾何倍的增加，如何高效的支持會員業務的測試，也成為了會員測試團隊不得不面對客觀挑戰，這其中最核心也是最基礎的莫過于測試環境的治理，現將測試環境特點總結如下：

• 特點1：基礎應用服務數量多達數百個，分布在幾十個域名下，維護成本高。

• 特點2：調用關系復雜，應用之間互相調用，并且相互依賴，聯調成本高。

• 特點3：服務之間調用依靠路由轉發、服務發現，定位成本高。

基于如上特點，測試過程中環境會有如下問題：

• 問題1：應用數量眾多，每個應用基礎配置隨意，且存在個性化配置，不好管

  理。

• 問題2：測試環境公用情況嚴重，依賴于各個研發或測試私服，穩定性比較差。

• 問題3：路由功能無法統一管理，調用關系混亂，環境出現問題時，排查問題時間成本高，需按調用關系逐一排查。

• 問題4：測試改進基建不穩定，一些基礎測試工作穩定性較差，收效甚微。
  

02

? ?會員測試環境發展史

? 階段一：手動階段??

經過一段時間對項目測試時間的積累，經過細致系統的分析后，測試環境是項目測試中耗時較多、最為不可控的環節，本著質量可控的原則，測試團隊決定重點建設測試環境，從根本上對測試質量和效率進行把控。申請到若干臺固定虛機作為測試機，結合業務打包方式和部署流程，手動在虛機上進行搭建，我們稱之為“手動階段”，具體流程如圖所示：

由于機器有限，單臺需求需要部署多個應用，為防止端口號沖突，使用wiki進行機器、應用、端口號的維護工作。

解決問題：

測試團隊接手測試環境打包-部署-維護流程，質量和效率可控。

存在問題：

每次在新機器部署應用時需要安裝依賴，此依賴無固定版本、使相同的應用在不同機器部署時配置、啟動命令等不一致。

一個機器部署多個應用，未避免沖突及后續nginx配置，人為規定相同機器不能部署相同應用，且端口號依靠wiki維護，維護成本高且時效性差，準確率不高。

個人習慣不同導致應用配置、啟動腳本不一致，難于統一進行集中管理。

無代碼編譯過程，部署代碼包完全依賴研發，時效性低。

配置類工作較多，操作繁瑣、效率低。

對環境部署人員能力要求高。

? 階段二：腳本階段??

隨著會員業務的不斷壯大，服務的邏輯愈加復雜，原手工方式的部署不堪重負，出現了很多的特殊處理，已經不能滿足業務測試需求，決定使用Jenkins能力進行規范化部署，將應用配置信息統一在mysql數據庫中進行維護，該階段我們稱之為“腳本階段”，整體流程圖如下：

在數據庫中對每個應用基礎信息進行維護，包括代碼路徑，基礎依賴，編譯命令，啟動腳本，具體如下圖：

前端頁面支持單應用部署，在Jenkins構建選擇對應應用、填寫分支、選擇機器后可進行部署：

Jenkins構建的過程如下圖展示：

代碼部署到服務器詳解：

解決問題：

每個應用在數據庫有基礎配置，可進行統一管理及維護。

依賴、服務器初始化、應用啟動等工作通過腳本統一完成，規范化且版本統一好維護。

代碼進行統一管理，接手代碼編譯打包過程，服務質量可把控。

部署環境實現自動化，提高部署效率。

對部署環境人員要求降低。

存在問題：

配置內容沒有頁面操作，只能在數據庫操作，操作不方便。

機器固定且無法動態擴容，出現問題后無人維護，無法支持個性化部署。

路由配置文件無法統一維護。

環境未按使用方式、場景進行區分。

擴展性差，遇到服務器遷移時成本過高。

? 階段三：平臺化??

隨著業務上代碼架構的升級，微服務化，容器化，云原生化的不斷升級，單獨腳本化的配置已經無法適配業務的迭代，測試環境的部署仿佛一夜之間又回到的最初始手動階段。同時業務上又出現了新的訴求：

• 動態申請機器部署測試環境，即用即拋。

• 單應用部署拓展到模板化部署，支持多應用的部署，配置，滿足場景級測試訴求。

• 多角色多用途使用，支持開發聯調/測試驗證，支持聯調環境，測試環境，自動化環境等等。

• 復雜的路由配置和參數替換，支持不同測試能力的對接等等。

  在此背景下，公司測試部基于公司資源搭建環境平臺，完成測試環境資源的統一分配、基準環境的統一部署、應用統一管理和部署、環境一鍵使用等功能，完成測試基礎工程能力建設的關鍵一環，為整體測試效能的提升打下基礎，環境平臺能力介紹如下圖:

依托于測試部提供的測試環境平臺進行業務適配，截止到目前，會員業務的測試環境已全面對接平臺，支持超過數百應用，日均部署次數百余次，服務人次超百人，使用平臺搭建測試環境測試項目覆蓋率為 90%+，穩定環境部署成功率為 99%+，項目手動部署成功率為 90%+。該階段我們稱之為“平臺階段”，具體整體流程圖如下：

解決問題：

每個應用的基礎配置在平臺維護，頁面可操作，集中管理、靈活配置（配置個性化、nginx、依賴host、注冊中心）。

會員測試只需要維護自定義腳本，服務器基本依賴托管平臺處理。

代碼編譯等操作托管公司內部CI/CD，流程規范，提高效率，版本可控。

環境按使用方式進行區分，減少因使用混亂導致的環境問題，避免分支與環境沖突。

通過權限控制人員可見系統及可操作范圍。

聯調環境方便管理，可集中度量。

03

? ?解決業務痛點

在結合會員業務特點不斷迭代測試環境，我們將重點解決如下幾個業務痛點：?

? 1. 測試環境整合??

基于用途整合測試環境，按域名區分進行管理，每個域名下按使用功能不同，搭建不同測試環境：

• 穩定環境：各應用每天定時部署master分支，與線上服務代碼保持一致，對內，對外提供聯調穩定聯調環境、自動化執行環境。

• CI環境：當git變更時觸發CI模板，進行環境部署后啟動個性化腳本，執行自動化和安全測試，確保問題提前暴露。

• 業務測試：基于穩定分支進行配置和分支信息的修改，部署環境后進行項目測試，測試完成后環境釋放，服務器可循環使用。

理想的環境搭建是只部署修改或新增的應用，其他應用使用穩定的，在降低測試環境搭建成本的同時減少因配置因素導致的其他環境問題。

例如圖中需要完成項目：測試項目一，此功能需要用到應用A、應用B、應用C、應用D完成整體流程測試，本次只修改應用C、應用D，只部署這2個應用，剩余應用使用穩定環境的即可，環境搭建如下圖展示：

? 2. 路由管理??

2.1 nginx 管理

會員應用之間路由強依賴 nginx，會員測試環境是否可用，路由服務是否正確全部依賴于 nginx 配置是否正確，此種配置重要且個性化，經過協商會員測試與環境平臺公共管理配置文件，業務負責配置文件管理及研發自定義腳本，環境平臺提供配置、替換的能力，按照如下分工進行配合，保障 nginx 穩定運行，流程圖如下：

就圖中的項目測試而言，如何保證穩定環境中的應用可以回調到項目環境中對應應用，而不是穩定環境中的對應應用，一旦修改了如圖應用B的調用地址，就無法保證2套環境可并行使用，此問題可歸結為路由問題，如下圖展示：

服務之間調用強依賴 nginx，如果 nginx 可動態的獲取變更的應用 ip+端口號，未變更的應用則使用穩定環境的應用來提供服務問題就會變得簡單，這也就解決了臨時環境與穩定環境的相互調用問題，效果如下圖：

想實現如上圖的效果，需要通過路由來處理，具體流程如下：

路由是轉發功能，具體邏輯還在應用中，啟動具體應用時除了應用的必要參數外，會員測試團隊還添加個性化內容，用于測試及相關質量改進，具體流程如下：

2.2.nginx集成guardro

QAE 是公司內部的基于 Docker 的應用引擎，可實現高效、可靠的自動化運維。guardro 即 Guardro-template，通過訂閱 QAE Controller（Guardro）的事件消息，可以實時更新 nginx 的 upstream 文件，并且觸發nginx重新載入配置。通過引入 guardro 來解決容器動態申請服務導致 ip 不固定替換 nginx 失敗的問題，它實現的過程如下：

訂閱 QAE 應用的實踐消息

在本地開啟一個小的 web 服務器，用于接收消息

當有消息到來時，根據消息內容，將 template 文件內特定的部分替換，生成相應 nginx 的 upstream 文件

觸發 nginx 重新載入配置

引入guardro后，具體流程如下展示：

2.3.注冊中心

服務之間調用逐漸從nginx改為微服務調用，為適配線下測試，對應用配置、部署方式、個性化腳本優化、Eureka自身進行升級，支持同步穩定注冊中心的其他應用及替換能力，實現模板中應用按順序部署自動注冊功能，實現環境一個注冊中心的能力，同時支持穩定與項目注冊中心分離，流程如下：

核心能力依賴于eureka-plus進行二次開發，部署的時候除了部署注冊中心外會額外部署一個同步工具，該工具實現了同步+過濾的功能，實現能力如下：

? 3.環境問題智能定位??

業務鏈路復雜帶來的最顯著的問題就是排查問題困難，很多因素都有導致這樣的問題出現，如依賴服務部署失敗，路由跳轉錯誤，服務配置錯誤等等問題，我們協同公司已有全鏈路平臺rover和圖譜平臺atlas對接到測試環境上，提供了一鍵問題定位能力，解決方案如下：

3.1整體交互圖

3.1.1 qae對接skywalking

skywalking可提供jar包形式，qae容器在啟動時引入即可

3.1.2 nginx對接全鏈路

nginx升級為openresty、需要預裝lua、同時需要業務線自己對接日志收集系統，動態變更監聽的IP地址，進行信息投遞完成調用鏈路展示。

3.2 最終鏈路呈現

應用與路由對接后，可清晰展現調用鏈路信息，便于測試快速確定項目測試過程中環境阻塞問題，迅速解決環境問題，提高測試效率。

04

? ?展望

會員測試環境經過幾年的積累和治理已經取得階段性成果，在支持測試業務和質量改進上起著至關重要的作用，也是隨著降本增效的整體浪潮下，測試環境的建設也會從虛擬化->容器化->云原生化持續不斷發展，下一步繼續協同測試環境平臺嘗試云原生化遷移，進一步賦能業務，進一步保持先進，進一步降本增效。

也許你還想看

會員接口治理的探索與實踐

視頻生產大鏡像優化實踐

愛奇藝數據湖實戰

?關注我們，更多精彩內容陪伴你！

總結

以上是生活随笔為你收集整理的会员测试环境治理之路的全部內容，希望文章能夠幫你解決所遇到的問題。

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