網易雲容器服務微服務化實踐—微服務測試及鏡像化提測全流程實踐

本文來自網易雲社區。

 

前言

近幾年，互聯網項目不少都有從單體服務轉變成微服務化的趨勢，尤爲是一些架構複雜，業務比較普遍的項目，微服務化是大勢所趨，能夠解決獨立構建、更新、運維等一系列問題，從而解放生產力，促進交付效率和質量。

目前網易雲容器服務團隊以 DevOps 的方式管理着30+微服務，如圖所示，容器服務項目微服務化特徵明顯、層次劃分清晰：

從第一個層面來說，線上及 線下環境多樣化和複雜性決定了構建部署次數的頻率，據不徹底統計，線上線下每週構建部署次數 400+。開發人員在每一個迭代（兩週一迭代）提測前每一個模塊在聯調環境至少更新2到6次，測試人員在每一個迭代提測後須要每一個模塊至少更新2到6次，才能達到發佈標準。好的構建、部署工具能夠提升構建部署時間效率從而節約開發人員和測試人員的時間，達到快速交付的目的。所以找到好的構建、部署工具和平臺的重要性和優先級都是第一位的。

另外一個層面，容器化服務在提測模式，上線模式、分支管理跟以前都有很大的不一樣，測試團隊須要針對容器化服務特色在提測模式、分支管理、質量評價方面作出一些適配和優化，以適應容器化及微服務架構的特色，將完整的容器化持續集成流水線模式引入，以及鏡像質量評價打入元數據的實踐探索。

最後一個層面，微服務化的項目對測試的要求更高，體如今測試範圍更廣了，測試深度也更深了。例如網易容器雲平臺的微服務化實踐（一）文中提到的從主工程平滑拆分出用戶服務的例子，一次拆分等於以前關於用戶服務內部調用的流程都變成facade+http接口調用。簡單來講接口個數是翻倍的增加（內部邏輯拆分紅http接口），更專業來講是分層測試的模式進一步體現出來，這樣就使得測試範圍就更廣了。其次不一樣的微服務場景和特色不一樣，須要測試分析更加深刻，測試策略更加有針對性，才能全面覆蓋微服務架構下的多種服務類型。對測試人員的能力、測試平臺及工具、測試效率要求都更高，在這方面的深刻探索頗有必要，目標是更好的進行質量+效率的全方位保障工做。

下面具體從以上三個層面來看容器服務的測試團隊如何解決這一系列問題和挑戰的。

1、構建、部署方式在微服務化架構下的實踐

OMAD服務部署時代：在本年度Q3季度，容器服務的大部分web服務仍是使用OMAD自動部署平臺使用構建機器構建並遠程部署至目標機器。

如圖所示，用戶經過UI去建立部署任務，而且觸發構建和部署動做完成命令下發，構建機器獲得命令後按照集成模板生成工程文件，下載源碼、編譯而且打包上傳nos；目標機器經過agent服務獲取部署安裝包而且替換模板屬性，啓動服務。

這個系統在微服務架構不明顯的項目中仍是比較好用的，可是一旦服務數量增加的很大，而且涉及到多團隊多人員去同時構建部署時就會有一些弊端。好比構建機器多任務並行時延，nos上傳和下載時延在服務數量同時構建更新時效率會變低。另外多人同時操做同一個服務的構建和部署，有可能會形成衝突致使構建失敗。這些問題都不能有效解決。最重要的一點是，構建部署環境強依賴於目標機上的環境配置，例如jdk和tomcat的版本，這樣在線上線下多環境複雜場景下，會致使多環境下同一服務表現有可能不一致。也由此引入了容器化服務時代。

DevOps容器化本地更新時代：

將服務容器化須要解決兩個問題：第一個問題是配置文件與代碼解耦，可使用docker container啓動的時候的env環境變量方式傳入，也能夠將配置數據服務中心化，目前二者兼有。

第二個問題是構建出來的鏡像到目標運行機器之間的傳遞如何來作，目前是採用網易雲容器服務自己在線上提供的鏡像倉庫來存儲和拉取。固然也能夠直接使用scp等操做在構建機器上將鏡像直接傳到到目標機器上。

構建及部署操做分別在構建機器（可多臺）以及目標機器上經過ssh登陸shell命令和腳本執行的方式操做。這個階段是本地更新時代，操做流程以下圖所示。

這種方式能夠解決OMAD時代的多任務並行阻塞問題，以及多人操做構建部署的問題（構建機器多臺，另外即便是一臺，因爲是腳本化構建，徹底獨立進程，互不影響；部署操做只須要更新目標機器的pod.yaml模板中的image字段便可，幾乎不會形成衝突，即便衝突也以最近一次更新的鏡像version爲準更新下載鏡像並從新啓動容器）。而且能夠解決不一樣的目標機器上環境不一樣致使的服務表現不一樣，由於每一個服務都運行在標準化的容器中，該容器預置的tomcat、jdk等依賴包都是徹底如出一轍的。

目前在開發人員和測試人員的合做下，線上環境已經大部分都採用這種模式部署，線下演練環境由測試人員更新成這種本地更新模式，儘可能保證演練環境和線上環境一致性。

DevOps容器化集羣管理更新時代：

在本地更新部署模式下若是想更新環境就須要ssh登陸到多個目標機器上更新，另外部署完的模塊不能根據須要遷移目標機器，這些問題在最近幾個迭代中線下環境的聯調環境以及測試環境進行了改進，即轉變爲集羣管理更新模式。所謂集羣管理更新模式是指將目標機器分別獨立去使用kubelet監控管理轉變成註冊到kubernetes master上去管理。在dashboard上調用建立deployment來啓動對應微服務的部署與更新，能夠可視化的查看部署進度和狀態，以及能夠動態的指定服務部署的目標機器，以便於一臺目標機器宕機快速的從另一臺目標機器上拉起服務的場景。

最近在測試人員將線下測試CI環境更新到這個模式之後，測試人員廣泛反饋更新操做比之前方便了。構建操做也能夠省去，當開發人員在聯調環境自測完畢後，測試人員直接在dashboard獲取到開發提測的最新鏡像地址，替換鏡像地址便可完成服務升級更新，能夠開展測試，大大下降了測試人員重複打包、鏈接目標機器等繁瑣的動做時間。

集羣管理更新模式以下圖所示：

集羣管理模式在線下實驗穩定後逐步升級至演練環境以及線上。目前存在kubelet升級或重啓會致使目標機器上所有容器重啓的風險，須要進一步解決及評估風險。

2、微服務化架構下鏡像化提測全流程實踐

容器服務項目測試團隊針對微服務化架構自己結合測試全流程提出了一套完整的解決方案，包含鏡像提測、容器化持續集成建設及質量評價全流程的一套方案及實踐，從多角度涵蓋微服務化的項目從開發、提測、上線、質量歸檔等所有環節，從而打造質量+效率的全方位保障工做。

鏡像提測模式引入

目前容器服務線上線下大部分服務都由代碼發佈轉變爲容器發佈，並且經過配置參數環境變量方式傳入容器以及配置數據服務中心化等方式支持了鏡像多環境發佈，這樣自然就帶來了遍歷。即多個環境可使用同一個鏡像部署運行服務。測試團隊綜合評估效率、版本可追溯的因素，提出了鏡像提測的方案。即開發人員由提交commitid給測試人員的方式轉變爲提交鏡像tag給測試人員，一方面能夠省去測試人員本身構建代碼，更新環境的步驟，另外一方面，經過鏡像版本化管理以及新引入的質量評價打入鏡像元數據等手段來歸檔提測後的鏡像，能夠快速追溯到不一樣質量版本的鏡像記錄。

代碼提測模式以下：

開發人員開發自測完畢後，告知測試人員git提交commitid，由測試人員構建打包，而且部署到線下環境，若是有bug的話，修復要之後須要再次構建打包部署。而且劣勢是隻能往前增長邏輯，不方便回滾。一旦合入的代碼若是想回退或者拆分就很難操做。另不方便排查引入新增的問題的提交和版本，質量評價只能按迭代而不能按提測版本，一旦有問題只能全量回退而不能回退某些特定提交。

下圖爲代碼提測方式的流程圖，黃色表明開發人員完成的內容，綠色表明測試人員所作的動做。

鏡像提測模式及質量評價打入鏡像元數據：

爲了更好的追溯鏡像版本的質量數據，容器服務的測試團隊建設了一個跟jira平臺打通的質量評價及歸檔工具，能夠實如今jira上評價的版本質量自動關聯到特定版本的鏡像元數據中並歸檔到鏡像倉庫中。根據評價的內容判斷鏡像是否能夠知足上線標準。後續追溯歷史版本也方便快捷。

質量評價打入鏡像元數據與提測及上線的流程圖以下所示，黃色表明開發人員完成的內容，綠色表明測試人員所作的動做，其中觸發jenkins job是jira回調事件自動觸發的，不須要人工參與：

容器化持續集成建設及質量評價全流程建設

除了提測模式轉變，手工測試完而後質量評價自動打入鏡像之外，咱們還在線下建設了多個微服務的容器化持續集成及質量評價pipeline建設。目的是爲了將靜態代碼檢查、單元測試、容器化構建部署、自動化接口測試、覆蓋率統計、測試結論自動打入鏡像整合成一套流程，能夠知足從代碼提交到自動化測試到自動發佈及結論歸檔的全流程服務，適用於接口比較穩定、單元測試建設良好、模塊依賴少的微服務模塊。

目前已在容器服務團隊在中間層服務中建設這樣的全流程實踐，流程以下所示：

當新增邏輯提交後，觸發容器化持續集成全流程的啓動。

1. interlayer-UnitTest-SA是使用sonar+PMD的方式對代碼進行靜態檢查並統計出須要修改的問題（Major以上須要上線前修復完畢），而且執行開發編寫的單元測試。運行經過後觸發interlayer-image-build job。

2. interlayer-image-build主要作了本文第一部分介紹的使用構建機器腳本構建鏡像並上傳的過程，爲環境更新作準備工做。打出來的鏡像tag傳遞到下個job中。

3. interlayer-image-deploy拿到新打好的鏡像tag之後，使用本文第一部分中容器化集羣管理更新時代中kubelet 更新接口去遠程更新目標機器的鏡像tag，從而更新中間層對應的服務版本。

4. interlayer-it-test 包含了中間層全部接口測試內容，在環境更新之後自動觸發並執行，同時在遠程jacoco打樁收集執行覆蓋率並回填到sonar的覆蓋率統計項中顯示。

5. interlayer-buildimage-test是最後一個步驟，當全部接口測試執行經過之後，將測試結果傳遞到這個job參數中，而且觸發從新打包的動做，將測試結果狀況打包到被測的鏡像元數據中，歸檔到鏡像倉庫。

最終測試人員拿到帶有自動化測試經過的鏡像包，能夠繼續進行手工測試，繼而將手工驗證結果經過jira備註觸發的方式再次構建手工測試經過的鏡像tag，以此版本鏡像提供到演練環境甚至線上環境。

理想狀況下，假如迭代內容通過評估後只須要完成自動化驗證便可上線的，能夠直接略過手工測試，將自動化測試經過的鏡像tag更新到演練環境和線上環境。相信在不久之後的DevOps時代，這個也會成爲現實。這樣開發人員就能夠直接從代碼提交到發佈全流程DevOps化了，歷史鏡像版本也可追溯查看，可作到快速更新、快速回滾等操做。

3、微服務化架構下測試工做實踐

容器服務項目的微服務化趨勢愈來愈明顯，對測試的深度和廣度要求也提高了一個臺階。

容器服務包含的30+個微服務中，大概能夠分爲兩類業務類型的服務，一類是垂直業務類型，就是從上而下徹底都是容器服務項目提供的應用支撐業務，例如微服務、鏡像倉庫，這兩大塊兒垂直業務都是由多個微服務合做完成的。第二類是橫向業務，經過接入其餘外部項目應用，或者被外部項目應用調用來提供服務，例如G0網關是提供給其餘項目的openapi接口來接入的，G1網關是提供給底層項目的資源調用接口來接入的，internal模塊服務是被其餘項目調用的，用戶服務也是被其餘項目調用來完成其職責的。這兩類微服務各有各的特色。首先來看垂直業務型的服務微服務拆分後的測試特色。

微服務化的分層測試應對：針對垂直業務型微服務進行分層自動化及端到端自動化

拿微服務業務和鏡像倉庫業務舉例，服務拆分前：

服務拆分後：

黃色塊是獨立對外的http服務，能夠看到，直接可被用戶調用的http服務從3個拆分變成7個，這還只是容器服務及鏡像倉庫提供的主幹邏輯拆分，目前容器服務團隊項目服務拆分之後已達到30+的獨立微服務。服務拆分能夠將不一樣業務的服務範圍劃分的更明確，更新升級服務也不會形成其餘業務的影響。然而對測試人員來講，拆分之後即便邏輯沒有變複雜，接口的個數是成倍的增長。

舉例來講，建立鏡像倉庫在拆分以前是存在於web模塊接口中的，自動化和手工只須要覆蓋web模塊的建立鏡像倉庫接口就能夠了。可是拆分以後，web模塊保留了代理轉發操做、流控等邏輯，真正的業務邏輯移動到nce-repo模塊中，以http接口的方式被web服務調用。這樣一來，建立鏡像倉庫接口就有了兩個維度的http接口對外提供。其餘服務的拆分也以此類推。所以自動化覆蓋須要在多層服務級別進行覆蓋。直接調用nce-repo模塊的接口重點覆蓋業務和邏輯維度；從web層調用的接口中重點覆蓋端到端場景。目前光是算http接口已經達到上千個接口。還有一些sdk包及獨立工具和工程的測試。光靠人肉測試和迴歸工做量巨大，所以自動化尤其重要。

分層自動化模式：

目前在容器服務項目中已落地實踐線下定時觸發分層的接口維度測試，確保各個層次的服務都能接口和邏輯維度覆蓋到，接口覆蓋普遍，目前已涵蓋全部http服務模塊（web、openapi、api、repo、build、internal、user），定時爲天天一次運行。

自動化策略：接口覆蓋、參數檢查等能夠依賴接口文檔快速進行的跟開發迭代同步完成，能夠確保演練迴歸、線上迴歸的效率提高，以及後續迭代的迴歸效率。邏輯複雜的接口測試取決於接口穩定程度和重要程度後續按優先級補充進行。

下圖爲jenkins job+TestNG方式涵蓋的http服務的定時接口測試，其中下面的四個獨立服務的定時接口測試是微服務化後新增的測試job。

端到端自動化模式：

目前已落地實踐線上定時觸發端到端業務測試，確保用戶觸發頻率高的主幹端到端場景能覆蓋到，並及時監控，定時爲每一個場景每小時一次（線上目前已部署10個主幹場景+），能夠快速發現線上用戶可能出現的問題。

下圖爲目前在線上環境健康運行的端到端業務測試：

微服務化的分層測試應對：針對橫向業務型微服務加強mock、增強獨立服務邏輯測試、增強專項測試

針對垂直業務分層自動化以及端到端自動化效率顯著，針對橫向業務，例如G0、G1網關這些自己不提供邏輯接口的服務來講，如何進行有效針對性的測試呢？

拿G0網關舉例，G0網關的主體功能及在項目中的位置以下：

若是隻基於接口的測試則徹底不能覆蓋G0網關自己的邏輯，而且接口自己邏輯不屬於容器服務的範疇，效率不佳。在這類微服務測試中，測試人員採用mock後端服務、增強獨立服務邏輯測試的模式去覆蓋。mock後的G0網關以下所示：

G0網關中的認證服務、流控、審計功能經過模擬不一樣的認證方式、參數組合、場景組合、mock接口加壓觸發流控、日誌檢索等方式去進行測試覆蓋。在單獨的環境下，將大部分依賴的外部服務mock掉，而後進行測試場景模擬以及自動化，在微服務化架構下，是一個測試人員必備的手段。這樣能夠有效排除掉因爲依賴方的異常或不穩定致使的問題，可以專一於G0網關這個服務自己的邏輯和穩定性。

除了基礎的功能和邏輯覆蓋之外，測試深度不斷深刻也是微服務化項目的一個必然的要求。容器服務項目測試團隊的測試深度挖掘包含多種工具、平臺的應用以及專項測試的實踐。

微服務化項目的邏輯複雜性決定了測試團隊不能只專一於基本功能和邏輯的知足需求，還須要在某些極端狀況下驗證多個微服務之間合做是否順暢，例如請求流量大的場景、 服務之間網絡異常場景、依賴服務返回值異常的場景，這些都須要在專項測試中完成場景的分析和覆蓋。在容器服務項目中，落地了屢次專項的異常測試以及穩定性、性能測試。在測試過程當中也發掘了很多有價值的場景和異常分支的潛在風險。同時也引入了一些工具和平臺，例如性能測試工具、加壓工具及平臺、異常構造工具及平臺、mock平臺等。

微服務化後，因爲分層測試引入的測試的自動化覆蓋率要求就更高，因爲專項測試須要的手段更加繁瑣，自動化複雜度也變得更高，所以相應的測試執行和自動化時間若是沒有更好地方法，時間勢必會佔用的更高。在容器服務項目中，測試人員進行了一系列的效率提高手段，以解決測試深度廣度加大之後帶來的工做量增長問題。

微服務化效率提高手段：接口自動化之tc關聯以及自動化前移

上文提到，服務拆分以及接口分層化會致使接口成倍增加，自動化必不可少，編寫自動化以前每每是在手工測試執行以後開始編寫，有時候甚至等到該接口和功能上線之後再來補齊，這樣會形成手工測試在多環境反覆執行，由於上線前自動化代碼仍然沒有編寫，所以會形成效率低下。在容器服務項目團隊中，測試人員引入了自動化前移以及tc平臺關聯自動化的流程。

自動化前移是指：在開發提測前，測試人員拿到開發接口文檔和部分設計文檔後就開展自動化編寫工做。基於的前提是接口文檔全面無變動，這在新版openapi模式下已經成爲能夠落地的現狀，由於新版openapi模式從需求提出開始就要求接口是肯定的，較少變動的。所以也助力於自動化前移能夠落地。測試人員編寫大部分自動化代碼後，在提測後可使用較少的時間調試經過，而且補充少許手工測試，以完成這些接口和功能的測試任務，在代碼質量達標之後上到演練環境以及線上環境能夠快速的適配自動化代碼的配置文件以達到快速回歸的目的。這樣有效的下降重複的手工屢次迴歸的時間。

tc平臺關聯自動化是指：咱們目前全部的執行集合都是由tc平臺 上建立並管理的，即便自動化測試在線下運行之後，仍然須要手工操做對應的測試用例置爲成功狀態。存在重複的操做工做量。引入tc關聯自動化之後，經過在自動化代碼case的元數據中加入tc對應用例的id的方式，能夠將tc的用例跟自動化代碼case關聯起來，經過tc上觸發自動化的迴歸而且同時回填測試用例的成功或失敗狀態，節省手工查看用例跟自動化的對應關係而且置位的操做步驟。

下圖爲容器服務項目中新版計算需求大部分接口自動化之後跟tc相關聯的執行及回填效果：

接口自動化以及邏輯自動化幾乎均可以採用這種手段提升效率，可是容器服務項目還存在着一大部分關於UI的測試範圍，好比微服務以及鏡像倉庫的頁面也須要測試人員去例行迴歸。這部分的效率怎麼解決呢?

微服務化效率提高手段：前端自動化錄製迴歸

容器服務項目測試團隊引入了UIRecorder組件去進行前端自動化錄製的步驟。而且將錄製方式經過培訓、合做調研的方式提供給前端開發人員，這樣可使得前端有樣式或者邏輯變動的時候快速識別而且從新錄製。

測試人員可使用前端開發提供的錄製腳本結合jenkins job的方式一鍵迴歸各環境的前端用例。目前容器服務的前端已經有30+個場景經過腳本錄製的方式集成到jenkins job，解放了一大部分的測試人員迴歸的工做量。

微服務化效率提高手段：mock平臺引入

容器服務項目測試團隊引入了平臺基礎服務一組自研的mock平臺 ，在進行橫向業務型微服務測試工做中，快速使用mock平臺去將依賴服務mock掉，並完成微服務自己邏輯的測試及自動化工做。經實踐，容器服務項目已使用mock平臺構造比本身使用Moco等Mock Server工具構造場景時間大概節約了80%，在異常專項測試以及橫向業務型微服務測試執行中大大提高了執行效率。

下圖爲目前在mock平臺已mock化的外部依賴接口：

總結

本文是《網易容器雲平臺的微服務化實踐》系列文章之一，一共從三個層面講述了目前容器服務的測試團隊所作的一系列實踐工做，關於容器部署模式、提測模式、容器化持續集成等活動已經在部分模塊和服務中有一些已經落地的實踐，也必定程度解決了微服務化後測試團隊面臨的質量效率雙重挑戰的問題。在後續的測試工做中，須要進一步固化微服務容器化提測流程，質量元數據歸檔等步驟，而且推廣給其餘微服務化架構項目團隊中。在測試具體工做上引入的一些實踐活動效率提高的手段也效果顯著，後續須要再挖掘一些加強測試探索的理念和實踐，從而爲項目的質量保障工做以及打造團隊影響力作出重要的貢獻。

 

網易雲容器服務爲用戶提供了無服務器容器，讓企業可以快速部署業務，輕鬆運維服務。容器服務支持彈性伸縮、垂直擴容、灰度升級、服務發現、服務編排、錯誤恢復及性能監測等功能。

背景回顧：網易容器雲平臺的微服務化實踐

本文來自網易雲社區，經做者崔曉晴受權發佈。

原文地址：網易雲容器服務微服務化實踐—微服務測試及鏡像化提測全流程實踐

更多網易研發、產品、運營經驗分享請訪問網易雲社區。