微服務是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微服務架構下兩個節點的呼叫圖。當從第一層入口元件訪問後，入口元件向後呼叫下一層節點的時候，後一層節點的執行執行緒自動取到了前一層節點的使用者資訊，並且加入到了第二層節點的執行執行緒控制元件。這樣，通過精準測試示波器（登入使用者標識和請求標識一致）就可以收到兩個節點的資料。實現多個使用者同時訪問分散式應用的時候，不同使用者出發的資料自動分離，路由到對應的示波器，最終對應到用例上。