您好,登錄后才能下訂單哦!
微服務是Devops場景下熱門的開發框架,在大型項目中被廣泛采用。它把一個大型的單個應用程序和服務拆分為數十個的支持微服務,獨立部署、互相隔離,通過擴展組件來處理功能瓶頸問題,比傳統的應用程序更能有效利用計算資源。微服務之間無需關心對方的模型,它通過事先約定好的接口進行數據流轉,使業務可以高效響應市場變化。但微服務一個明顯的表象就是隨著服務的增多,傳統的測試模式受到很大制約,無法有效進行下去,威脅到整體系統質量。所有J2EE代碼層白盒采集工具都無法區分覆蓋和具體功能的對應關系,只能以后臺模式“籠統“的采集一個階段的總的覆蓋,無法滿足對于Devops下對于故障定位、深度測試分析以及敏捷發布算法的要求。
星云測試(www.teststars.cc)發布分布式微服務精準測試解決方案,是目前市場上唯一可達到在復雜分布式系統中,跨多個服務器進行代碼白盒級分析、實現請求分布式追蹤的測試平臺。其中產品內的穿透模塊,可以支持各種主流微服務通信架構。例如httpclient,springcloud微服務架構、阿里dubbo微服務架構,以及消息隊列,將并發訪問場景下跨多個服務多組代碼邏輯分離并重建追蹤出來。實現業務邏輯的代碼在開發層面通過微服務離散后,在測試階段則可以反向復原整個完整代碼執行視圖。精準測試里面的穿線概念(Threadingtest)增加了第三層含義,即針對的分布式服務的穿透能力。
微服務場景下,一個完整請求會跨多個計算(服務)節點,而對于以節點為剖面的各種測試和監控手段都變得不那么直接和有效。一個請求鏈路的失效和性能故障等問題,從一個計算節點剖面去分析是很困難的,因為在一個計算節點剖面上的數據是混合型數據,而無法區分這里面的數據來自于那個請求。原始的方法無法將一個調用鏈路上的所有信息完整的重新刻畫出來。業界流行的APM技術可以某種程度實現這種調用鏈路分析,該項技術主要用于監控,體現的數據是組件級的,而且為了性能考慮還經常抽取樣本,無法達到測試要求的代碼級的分析。
微服務采用的“分而治之”的策略,而精準測試對于微服務的測試和運營管控上采用的是“概覽全局”的策略。精準測試在編譯階段,重新將微服務所有模塊視為一個完整項目,統一編譯和插裝,經過插裝后的代碼重新部署到原有節點上。在微服務的啟動過程中附加上分布式追蹤所需要的agent啟動,即可完成微服務場景下達到測試用例級的代碼全調用路徑分析。由于微服務有多個程序模塊,星云測試平臺支持模塊級增量編譯模式,即每次編譯替換某一個模塊就可以生成一個新的版本,而無需將所有微服務模塊全新編譯。
穿透和分布式追蹤的原理,這里要重點將以下星云測試JavaEE應用服務器agent的能力。agent提供了一個虛擬jsp的技術,通過agent啟動的被測應用,都附加了一個虛擬jsp,地址類似于http://www.appundertest.com/teststars.jsp。 訪問這個頁面可以用來指本機的用戶,一般這個設置和精準測試示波器的登錄用戶需要一致。設置完成后,對被測試應用的請求將附加上一個用戶標識的cookie信息,這個信息會在微服務的多層架構中一直攜帶和穿透。例如從瀏覽器發起的一個帶著用戶標識信息的請求,到了應用服務的處理線程中,這個線程執行的所有代碼將附加上這個用戶信息,如果應用在向后調用其他的節點的服務,則這個用戶信息會繼續向后傳遞,直到最后的執行節點。由于每個節點的代碼均有精準測試系統插裝的代碼,會自動的向用戶請求發起端的示波器回饋數據,那么就可以實現將整個調用鏈路上的代碼邏輯發送給示波器。示波器收到數據后,將動態數據和代碼編譯階段的程序靜態數據結合起來,即可展示全鏈路的程序調用路徑信息。從另外角度,當微服務系統有多個請求同時并行的時候,那么每個示波器收到的是自己對應的請求代碼的全鏈路執行情況,而其他示波器用戶和其他普通用戶的數據則不會被收錄進來。
上圖是一個spring cloud微服務架構下兩個節點的調用圖。當從第一層入口組件訪問后,入口組件向后調用下一層節點的時候,后一層節點的運行線程自動取到了前一層節點的用戶信息,并且加入到了第二層節點的運行線程控件。這樣,通過精準測試示波器(登錄用戶標識和請求標識一致)就可以收到兩個節點的數據。實現多個用戶同時訪問分布式應用的時候,不同用戶出發的數據自動分離,路由到對應的示波器,最終對應到用例上。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。