摘要：本文將以Sermant的SpringBoot 註冊外掛的效能測試及最佳化過程為例，分享在Java Agent場景如何進行更好的效能測試最佳化及在Java Agent下需要著重注意的效能陷阱。
作者：欒文飛 高階軟體工程師
一、背景介紹
Sermant是一個主打服務治理領域的Java Agent框架，在服務治理中難免會有針對業務流量進行解析和處理的過程，此類服務治理能力將會對微服務的服務能力產生一定的效能影響，作為一個基於Java Agent技術做服務治理的框架，我們需要在保證服務治理能力生效的同時，極小的影響微服務原有的服務效能。
雖然基於Java Agent的服務治理和基於SDK的服務治理在其原理上有所不同，但也避免不了微服務治理過程中產生對微服務原有效能的影響，基於Java Agent服務治理方式的相較於SDK的服務治理方式免去了侵入式的程式碼開發，是一種執行時技術，所以還需要考慮更多方面效能最佳化問題，例如在啟動時間，執行時增強效能開銷等，本文將以Sermant的SpringBoot 註冊外掛的效能測試及最佳化過程為例，分享在Java Agent場景如何進行更好的效能測試最佳化及在Java Agent下需要著重注意的效能陷阱。
SpringBoot 註冊外掛為SpringBoot應用提供服務註冊發現能力，可用於在不修改原有程式碼的前提下快速從ESB架構演進為微服務架構，在該外掛中包含針對域名的替換能力，服務註冊發現能力，請求的超時重試等，為架構的成功演進，原有架構中基於域名的請求呼叫，將會被基於註冊資訊的請求呼叫（透過該外掛的服務註冊發現能力，獲取服務提供者註冊的資訊）所取代，如下圖所示：
在域名處理的過程是必然會參與到呼叫過程中的，這是服務治理能力對業務效能影響的典型場景。
二、測試方案
眾所周知，Java Agent程式和被增強應用執行時同程式，Java Agent程式最重要的是不能對被掛載的應用產生異常影響，導致應用不可用，所以Sermant在執行時的處理效能及穩定性等做多方面的測試考量。在針對微服務進行測試的過程中，我們往往只需要關注該微服務的效能即可，透過壓力測試來檢驗微服務的服務提供能力，由於服務治理能力並不直接提供服務，我們更多地需要關注在開啟服務治理能力時，對微服務本身服務提供能力的影響，所以我們在測試方案中需要進行對比測試來評估服務治理能力的好壞。
本對照測試中，我們透過壓力測試讓系統達到極限場景（consumer端的CPU已經到達瓶頸），來分析攜帶Sermant並啟用服務治理能力時，對應用原有服務提供能力的影響，此處採用兩種部署方案
- 不攜帶Sermant，基於閘道器的場景，是架構改造前的執行模式
- 攜帶Sermant的場景，是遷移後的微服務架構執行模式
注：在這種對比測試中，基於Java Agent的服務治理只需要對攜帶Java Agent程式和不攜帶Java Agent程式的場景進行對照測試即可，無需兩套程式碼進行對照測試。
由於Java Agent程式和被增強應用處於統一程式，資源共享，基於上述兩種部署方案進行測試，以不攜帶Java Agent程式作為測試分析的對照組，就可以很清晰的看出引入Java Agent程式後產生的影響，並可根據對照結果進行最佳化，應用於Sermant上，就可以很容易的分析出Sermant的服務治理能力對微服務本身服務提供能力帶來的影響。
三、效能分析
由於需要針對應用發起的請求透過位元組碼增量的方式做域名的替換，SpringBoot 註冊外掛透過對HttpClient、Openfeign、Okhttp等http客戶端進行了位元組碼增強，我們根據上一章節中的測試方案對該外掛提供的服務治理能力進行了測試，下面我們以HttpClien為例透過CPU火焰圖來講述如何在Java Agent場景下分析效能瓶頸：
在效能調優過程中，我們可透過CPU火焰圖來分析效能瓶頸，火焰圖可以稱之為效能問題分析的"X光"，可以很一針見血的看出在程式執行中哪些程式碼片段產生了異常的CPU佔用。可以參考《使用火焰圖(FlameGraph)分析程式效能》進行學習，當然，採集CPU火焰圖的方式很多，我們只需要學會如何看懂火焰圖即可。
分析步驟
1. 找到位元組碼增強邏輯的CPU佔用
在分析過程中，首先需要找到位元組碼增強時選中的被增強方法（本文場景增強方法為InternalHttpClient::doExecute），位元組碼增強需要被增強程式的原有方法呼叫觸發，所以也可以很清晰的在CPU火焰圖中可以看到，Sermant實現的邏輯呼叫棧在被增強方法之上，在位元組碼增強邏輯執行結束後，被增強方法還會繼續執行。
所以除被增強方法執行的呼叫棧及CPU時間片佔用外，皆為位元組碼增強所引入邏輯，在效能最佳化中需著重關注。
2. 分析異常佔用
根據CPU火焰圖原理，找出位元組碼增強部分，找出異常佔用CPU時間片的呼叫棧，並進行程式的最佳化，如下圖所示紅框選擇部分，皆為位元組碼增強中引入的邏輯，佔用了非常多的CPU時間片，由於位元組碼增強程式和被增強程式，這種異常的佔用，將會嚴重影響原程式的效能，在針對Java Agent場景的最佳化中可著重最佳化
透過上述步驟，我們可以一目瞭然的看到我們透過Java Agent程式引入的CPU額外佔用，具體佔用原因本文就不一一分析。
四、效能陷阱
基於上述兩個章節的測試和分析方法，在本文的最後，列舉出在Java Agent開發過程中經常會遇到的效能陷阱，這裡也給出解決方式，可以在開發中注意：
減少反射使用
在位元組碼增強開發過程中，很多情況下，如果類載入器不同，針對被增強應用的類和方法往往需要透過反射去獲取並使用，在我們的效能分析中，反射是一個CPU佔用的巨大陷阱，在有些被BootstrapClassLoader載入的類增強時，甚至反射佔用了一個方法呼叫30%以上的CPU事件片。
下圖選中方法中，反射佔用該方法呼叫中的大部分CPU時間片:
但是由於類載入器的限制，有些反射是必須要使用的，我們也可以透過一定的手段進行最佳化，比如快取透過反射獲取的類和方法，在位元組碼增強中，多次觸發增強邏輯時減少反射佔用CPU時間片非常有效。
Method method = METHOD_CACHE.get(methodKey); if (method != null) { return Optional.of(method); } method = clazz.getDeclaredMethod(methodName, paramsType); METHOD_CACHE.put(methodKey, method);
透過上述步驟最佳化後，透過火焰圖來看，效果是非常顯著的：
注意位元組碼增強插樁選擇
在做位元組碼增強時的增強點選擇很重要，位元組碼增強新增Transformer後執行時分為兩種情況：
- transform：針對尚未被類載入器載入的類，如果新增Transformer，在類被載入時就會觸發位元組碼的轉換。
- retransform：針對已經被類載入器載入的類，如果新增了Transformer，則需要被重新載入後再進行位元組碼的轉換。
Java中被BootstrapClassLoader載入的類，如果想要進行位元組碼增強，就需要使用第二種位元組碼轉換的方式，可想而知，如果重新載入類再進行轉換必然沒有在類第一次載入時就進行轉換的效率高。
除上述原因之外，在增強啟動類載入器載入的類時，由於雙親委派機制的限制（只能向上委託，不能向下委託），往往都是需要大量使用反射（用於呼叫其他類載入器載入的類）來實現增強邏輯。
上文中也講到，不加節制的使用反射將會透過Java Agent程式嚴重影響被增強應用的效能，所以在開發Java Agent時，需要謹慎選擇增強的類，非必要不增強被啟動類載入器載入的類。
上述兩點是在Java Agent開發過程中最容易發生的向被增強應用引入的效能陷阱，除此之外，Java Agent也是由Java所開發，在開發過程中也需要注意不要引入常見的效能陷阱。
結束語
Sermant作為專注於服務治理領域的位元組碼增強框架，致力於提供高效能、可擴充套件、易接入的服務治理體驗，並會在每個版本中做好效能、功能、體驗的看護，廣泛歡迎大家的加入。
Sermant官網：https://sermant.io
GitHub倉庫地址：https://github.com/huaweicloud/Sermant