微服務是Devops場景下熱門的開發框架，在大型項目中被廣泛採用。它把一個大型的單個應用程式和服務拆分為數十個的支持微服務，獨立部署、互相隔離，通過擴展組件來處理功能瓶頸問題，比傳統的應用程式更能有效利用計算資源。微服務之間無需關心對方的模型，它通過事先約定好的介面進行數據流轉，使業務可以高效響應市 ...
微服務是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微服務架構下兩個節點的調用圖。當從第一層入口組件訪問後，入口組件向後調用下一層節點的時候，後一層節點的運行線程自動取到了前一層節點的用戶信息，並且加入到了第二層節點的運行線程式控制件。這樣，通過精準測試示波器（登錄用戶標識和請求標識一致）就可以收到兩個節點的數據。實現多個用戶同時訪問分散式應用的時候，不同用戶出發的數據自動分離，路由到對應的示波器，最終對應到用例上。
