歡迎光臨
每天分享高質量文章
當前位置：知識星球 > 後端 > 正文

微服務測試及映象化提測全流程實踐

2019-03-10 分類：後端 閱讀(470) 評論(0)

產品的技術架構從單體服務進行微服務化改造，解決了獨立構建、更新、運維等一系列問題，但這也對微服務化專案的測試提出了更高的要求和挑戰。
本文將從三個方面出發，詳細解讀專案的微服務化改造會給測試團隊帶來哪些挑戰，同時，測試團隊對這些挑戰該如何進行高效應對。
近幾年網際網路專案很多都有從單體服務轉變成微服務化的趨勢，尤其是一些架構複雜，業務比較廣泛的專案，微服務化是大勢所趨。微服務化可以解決獨立構建、更新、運維等一系列問題，從而解放生產力，促進交付效率和質量。
目前網易雲輕舟團隊以 DevOps 的方式管理著 30+ 微服務，如圖所示，容器服務專案微服務化特徵明顯、層次劃分清晰：

業務的微服務化改造提升了各模組部署上線的效率，但對微服務專案的測試團隊帶來了新的要求和挑戰。
從第一個層面來講，線上及線下環境多樣化和複雜性決定了構建部署次數的頻率。好的構建、部署工具可以提高構建部署時間效率從而節約開發人員和測試人員的時間，達到快速交付的目的。因此找到好的構建、部署工具和平臺的重要性和優先順序都是第一位的。
另一個層面，容器化服務在提測樣式，上線樣式、分支管理上跟之前都有很大的不同，測試團隊需要針對容器化服務特點在提測樣式、分支管理、質量評價方面做出一些適配和最佳化，以適應容器化及微服務架構的特點，將完整的容器化持續整合流水線樣式引入，以及將映象質量評價打入元資料的實踐探索。
第三個層面，微服務化的專案對測試的要求更高，具體體現在測試範圍更廣、測試深度也要更深。例如《網易容器雲平臺的微服務化實踐（一）》文中提到的從主工程平滑拆分出使用者服務的例子，一次拆分等於之前關於使用者服務內部呼叫的流程都變成 facade + http 介面呼叫。也就是說介面個數會翻倍增長（內部邏輯拆分成 http 介面），分層測試的樣式進一步體現出來，這樣就使得測試範圍更廣了。其次，不同的微服務場景和特點不同，需要測試分析更加深入，測試策略更加有針對性，才能全面改寫微服務架構下的多種服務型別。對測試人員的能力、測試平臺及工具、測試效率要求都更高，在這方面的深入探索很有必要，標的是更好地進行質量 + 效率的全方位保障工作。
下麵具體從這三個層面出發，來看下輕舟的測試團隊該如何解決這一系列問題和挑戰。
一、構建、部署方式在微服務化架構下的實踐

 

OMAD 服務部署時代：
OMAD 是網易自研的一套部署管理平臺。2017 年輕舟的前身——容器服務的大部分 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 來啟動對應微服務的部署與更新，可以視覺化地檢視部署進度和狀態，以及可以動態的指定服務部署的標的機器，以便於一臺標的機器宕機時可以快速從另外一臺標的機器上拉起服務的場景。
在測試人員將線下測試環境更新到這個樣式以後，測試人員普遍反饋更新操作比以前方便了。構建操作也可以省去，當開發人員在聯調環境自測完畢後，測試人員直接在 Dashboard 獲取到開發提測的最新映象地址，替換映象地址即可完成服務升級更新，可以開展測試，大大降低了測試人員重覆打包、連線標的機器等繁瑣的動作時間。
叢集管理更新樣式如下圖所示：

叢集管理樣式線上下實驗穩定後逐步升級至演練環境以及線上。但諸如 kubelet 升級或重啟會導致標的機器上全部容器重啟的風險等，也還需要進一步解決及評估風險。
二、微服務化架構下映象化提測全流程實踐

 

我們針對微服務化架構本身，結合測試全流程提出了一套完整的解決方案，包含映象提測、容器化持續整合建設及質量評價，涵蓋微服務化專案從開發、提測、上線、質量歸檔等全部環節，力求打造質量 + 效率的全方位保障工作。
映象提測樣式引入
目前輕舟所有模組都由由程式碼釋出轉變為由容器釋出，同時透過配置引數環境變數方式傳入容器以及配置資料服務中心化等方式支援了映象多環境釋出，這樣天然就帶來了便利。即多個環境可以使用同一個映象部署執行服務。測試團隊綜合評估效率、版本可追溯的因素，提出了映象提測的方案。即開發人員由提交 commitid 給測試人員的方式轉變為提交映象 tag 給測試人員，一方面可以省去測試人員自己構建程式碼，更新環境的步驟，另一方面，透過映象版本化管理以及新引入的質量評價打入映象元資料等手段來歸檔提測後的映象，可以快速追溯到不同質量版本的映象記錄。
程式碼提測樣式如下：開發人員開發自測完畢後，告知測試人員 Git 提交 commitid，由測試人員構建打包，並且部署到線下環境，如果有 bug 的話，修複以後需要再次構建打包部署。並且只能往前增加邏輯，不方便回滾。一旦合入的程式碼想回退或者拆分就很難操作。另不方便排查引入新增的問題的提交和版本，質量評價只能按迭代而不能按提測版本，一旦有問題只能全量回退而不能回退某些特定提交。
下圖為程式碼提測方式的流程圖，黃色代表開發人員完成的內容，綠色代表測試人員所做的動作。

映象提測樣式及質量評價打入映象元資料
為了更好地追溯映象版本的質量資料，輕舟測試團隊建設了一個跟 Jira 平臺打通的質量評價及歸檔工具，可以實現在 Jira（任務管理平臺） 上評價的版本質量自動關聯到特定版本的映象元資料中並歸檔到映象倉庫中。根據評價的內容判斷映象是否可以滿足上線標準。後續追溯歷史版本也方便快捷。
質量評價打入映象元資料與提測及上線的流程圖如下所示，黃色代表開發人員完成的內容，綠色代表測試人員所做的動作，其中觸發 Jenkins job 是 Jira 回呼事件自動觸發的，不需要人工參與：

容器化持續整合建設及質量評價全流程建設
除了提測樣式轉變、手工測試完然後質量評價自動打入映象以外，我們還線上下建設了多個微服務的容器化持續整合及質量評價 Pipeline 建設。目的是為了將靜態程式碼檢查、單元測試、容器化構建部署、自動化介面測試、改寫率統計、測試結論自動打入映象整合成一套流程，可以滿足從程式碼提交到自動化測試到自動釋出及結論歸檔的全流程服務，適用於介面比較穩定、單元測試建設良好、模組依賴少的微服務模組。
目前輕舟團隊已在某些獨立服務模組中建設這樣的全流程實踐，如下所示：

當新增邏輯提交後，觸發容器化持續整合全流程的啟動。
最終測試人員拿到帶有自動化測試透過的映象包，可以繼續進行手工測試，繼而將手工驗證結果透過 Jira 備註觸發的方式再次構建手工測試透過的映象 tag，以此版本映象提供到演練環境甚至線上環境。
理想情況下，假如迭代內容經過評估後只需要完成自動化驗證即可上線，可以直接略過手工測試，將自動化測試透過的映象 tag 更新到演練環境和線上環境。這樣開發人員就可以直接從程式碼提交到釋出全流程 DevOps 化了，歷史映象版本也可追溯檢視，可做到快速更新、快速回滾等操作。
三、微服務化架構下測試工作實踐

 

輕舟專案的微服務化趨勢越來越明顯，對測試的深度和廣度要求也提升了一個臺階。
輕舟包含微服務中，大概可以分為兩類，一類是垂直業務型別，就是從上而下完全都是輕舟專案提供的應用支撐業務，例如 NSF、APM 等業務。第二類是橫向業務，透過接入其他外部專案應用，或者被外部專案應用呼叫來提供服務，例如 閘道器業務。這兩類微服務各有各的特點。首先來看垂直業務型的服務微服務拆分後的測試特點。
微服務化的分層測試應對：針對垂直業務型微服務進行分層自動化及端到端自動化
分層自動化樣式：
目前在輕舟專案中已落地實踐線下定時觸發分層的介面維度測試，確保各個層次的服務都能按介面和邏輯維度改寫到，介面改寫廣泛，目前已涵蓋所有 http 服務模組，定時為每天一次執行。
自動化策略：介面改寫、引數檢查等可以依賴介面檔案快速進行跟開發迭代同步完成，可以確保演練回歸、線上回歸的效率提升，以及後續迭代的回歸效率。邏輯複雜的介面測試取決於介面穩定程度和重要程度後續按優先順序補充進行。
端到端自動化樣式：
目前已落地實踐線上定時觸髮端到端業務測試，確保使用者觸發頻率高的主幹端到端場景能改寫到，並及時監控，定時為每個場景每小時一次（線上目前已部署 10 個主幹場景+），可以快速發現線上使用者可能出現的問題。
微服務化的分層測試應對：針對橫向業務型微服務增強 Mock、加強獨立服務邏輯測試、加強專項測試
針對垂直業務分層自動化以及端到端自動化效率顯著，針對橫向業務，例如閘道器業務這些本身不提供邏輯介面的服務來說，如何進行有效針對性的測試呢？
拿 API 閘道器舉例，閘道器的主體功能及在專案中的位置如下：

如果只基於介面的測試則完全不能改寫 API 閘道器本身的邏輯，並且介面本身邏輯不屬於容器服務的範疇，效率不佳。在這類微服務測試中，測試人員採用 Mock 後端服務、加強獨立服務邏輯測試的樣式去改寫。Mock 後的 API 閘道器如下所示：

API 閘道器中的認證服務、流控、審計功能透過模擬不同的認證方式、引陣列合、場景組合、Mock 介面加壓觸發流控、日誌檢索等方式去進行測試改寫。在單獨的環境下，將大部分依賴的外部服務 Mock 掉，然後進行測試場景模擬以及自動化，在微服務化架構下，是一個測試人員必備的手段。這樣可以有效排除掉由於依賴方的異常或不穩定導致的問題，能夠專註於閘道器這個服務本身的邏輯和穩定性。
除了基礎的功能和邏輯改寫以外，測試深度不斷深入也是微服務化專案的一個必然的要求。輕舟專案測試團隊的測試深度挖掘包含多種工具、平臺的應用以及專項測試的實踐。
微服務化專案的邏輯複雜性決定了測試團隊不能只專註於基本功能和邏輯的滿足需求，還需要在某些極端情況下驗證多個微服務之間合作是否順暢，例如請求流量大的場景、 服務之間網路異常場景、依賴服務傳回值異常的場景，這些都需要在專項測試中完成場景的分析和改寫。在容器服務專案中，落地了多次專項的異常測試以及穩定性、效能測試。在測試過程中也發掘了不少有價值的場景和異常分支的潛在風險。同時也引入了一些工具和平臺，例如效能測試工具、加壓工具及平臺、異常構造工具及平臺、Mock 平臺等。
微服務化後，由於分層測試引入的測試的自動化改寫率要求就更高，由於專項測試需要的手段更加繁瑣，自動化複雜度也變得更高，因此相應的測試執行和自動化時間如果沒有更好的方法，時間勢必會佔用的更多。在輕舟專案中，測試人員進行了一系列的效率提升手段，以解決測試深度廣度加大以後帶來的工作量增加的問題。
微服務化效率提升手段：介面自動化之 tc 關聯以及自動化前移
上文提到，服務拆分以及介面分層化會導致介面成倍增長，自動化必不可少，編寫自動化之前往往是在手工測試執行之後開始編寫，有時候甚至等到該介面和功能上線以後再來補齊，這樣會造成手工測試在多環境反覆執行，因為上線前自動化程式碼仍然沒有編寫，因此會造成效率低下。在輕舟專案團隊中，測試人員引入了自動化前移以及 tc 平臺關聯自動化的流程。
自動化前移是指：在開發提測前，測試人員拿到開發介面檔案和部分設計檔案後就開展自動化編寫工作。基於的前提是介面檔案全面無變更，這在新版 OpenAPI 樣式下已經成為可以落地的現狀，因為新版 OpenAPI 樣式從需求提出開始就要求介面是確定的，較少變更的，也助力了自動化前移可以落地。測試人員編寫大部分自動化程式碼後，在提測後可以使用較少的時間除錯透過，並且補充少量手工測試，以完成這些介面和功能的測試任務，在程式碼質量達標以後上到演練環境以及線上環境可以快速的適配自動化程式碼的配置檔案以達到快速回歸的目的。這樣有效的降低重覆的手工多次回歸工作。
tc 平臺關聯自動化是指：我們目前所有的執行集合都是由 tc 平臺上建立並管理的，即使自動化測試線上下執行以後，仍然需要手工操作對應的測試用例置為成功狀態。存在重覆操作的工作量。引入 tc 關聯自動化以後，透過在自動化程式碼 case 的元資料中加入 tc 對應用例的 id 的方式，可以將 tc 的用例跟自動化程式碼 case 關聯起來，透過 tc 上觸發自動化的回歸併且同時回填測試用例的成功或失敗狀態，節省手工檢視用例跟自動化的對應關係並且置位的操作步驟。
下圖為輕舟專案中某專案大部分介面自動化以後跟 tc 相關聯的執行及回填效果：
介面自動化以及邏輯自動化幾乎都可以採用這種手段提高效率，但是輕舟專案還存在著一大部分關於 UI 的測試範圍，比如微服務以及映象倉庫的頁面也需要測試人員去例行回歸。這部分的效率怎麼解決呢?
微服務化效率提升手段：前端自動化錄製回歸
輕舟專案測試團隊引入了 SmartAuto 元件去進行前端自動化錄製的步驟。並且將錄製方式透過培訓、合作調研的方式提供給前端開發人員，這樣可以使得前端有樣式或者邏輯變更的時候快速識別並且重新錄製。
測試人員可以使用 SmartAuto 指令碼一鍵回歸各環境的前端用例。目前輕舟的前端已經有部分場景透過指令碼錄製的方式實現自動化，解放了一大部分測試人員回歸的工作量。

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

 

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

贊(0)
標籤：

相關推薦

熱門標籤

iOS (11238)微軟 (4955)Linux (4274)安全 (4180)Python (4161)效能 (3165)運維 (2774)最佳化 (2419).NET (2262)Google (2136)機器學習 (1795)併發 (1613)分散式 (1559)叢集 (1240)SQL (1174)Mysql (1060)區塊鏈 (1017)Docker (977)微服務 (922)面試 (919)Apache (743)NLP (725)Redis (719)Android (668)Git (640)架構師 (632)Nginx (630)Facebook (599)JVM (595)爬蟲 (476)

熱門文章

分享創造快樂