解析 Sermant 熱插拔能力：服務運行時動態(tài)掛載 JavaAgent 和插件

一、概述

Sermant 是基于 Java 字節(jié)碼增強技術的無代理服務網格，其利用 Java 字節(jié)碼增強技術，為宿主應用程序提供服務治理功能，以解決大規(guī)模微服務場景中的服務治理問題，通過 Java 字節(jié)碼增強技術，可以非侵入的提供服務治理能力。在以往版本中，Sermant 通過配置 - javaagent 指令在微服務啟動時接入服務治理能力，當需要接入及卸載 Sermant 時都需要通過重新啟動微服務來完成。但從 1.2.0 版本開始，Sermant 實現(xiàn)了在服務不停機狀態(tài)下進行安裝和卸載的能力，為服務治理能力帶來全新接入體驗。本文將會對這種動態(tài)接入的機制，從技術基礎到 Sermant 設計進行一次深入分析。

二、JavaAgent 加載方式

首先介紹一下 JavaAgent 的不同接入方式，這是 Sermant 實現(xiàn)動態(tài)接入能力的技術基礎。Java 中 Instrumentation API 提供了一種修改字節(jié)碼的機制，利用該 API，可以通過修改字節(jié)碼的方式來改變程序的行為，而不用觸及程序的源碼。JavaAgent 為 Instrumentation API 的客戶端，通過 JavaAgent 可以調用 API 進行字節(jié)碼的操作，其提供了兩種加載方式給開發(fā)者重載：

靜態(tài)加載：利用 premain，在應用程序啟動時加載 JavaAgent 稱為靜態(tài)加載，靜態(tài)加載會在啟動時在執(zhí)行任何代碼之前修改字節(jié)碼。

靜態(tài)加載時，字節(jié)碼增強是在類加載時發(fā)生的，當 Java 程序啟動時，類加載過程中所有被加載的類都會經過 JavaAgent 所定義的類文件轉換器的處理。

動態(tài)加載：利用 agentmain 通過 Java Attach API 將 JavaAgent 加載到已運行的 JVM 中，動態(tài)加載可以通過字節(jié)碼重轉換的方式在運行時修改字節(jié)碼。

動態(tài)加載時，和靜態(tài)加載不同的是，此時 JVM 已在運行，目標類已被加載，就不能像靜態(tài)加載時一樣觸發(fā)字節(jié)碼增強過程，在使用動態(tài)加載的過程中，往。往會通過 Instrumentation API 來觸發(fā)目標類（當然也可以指定所有已被加載的類）的重轉換過程，在重轉換過程中就會觸發(fā)到 Agent 構建的類文件轉換器，從而完成字節(jié)碼增強過程。

動態(tài)加載方式為 JavaAgent 提供了在 JVM 運行時接入的能力，但通過類重轉換來觸發(fā)字節(jié)碼增強相對于在類加載時增強有一定的局限性，例如不能在增強時修改類的繼承關系，不能為類添加靜態(tài)代碼塊，不能增強內存中和資源文件中字節(jié)碼不一致的類等，這些也是在使用動態(tài)加載和多 JavaAgent 場景中常見的問題，綜上，兩種加載方式各有利弊，可以在使用時按照業(yè)務場景選擇。

三、Sermant 熱插拔能力關鍵問題剖析

在了解技術基礎后，我們能輕易的想到，理論上基于 JavaAgent 的動態(tài)加載方式，只需要在使用 Sermant 時，將通過 premain 方式啟動改為通過 agentmain 方式啟動，就可以將微服務治理能力動態(tài)的接入到微服務中，做到微服務零侵入、微服務不停機的狀態(tài)下接入服務治理能力，但通往前方的路上總是充滿了障礙：

3.1 如何保證動態(tài)安裝過程中重轉換可順利執(zhí)行？

這個問題的出現(xiàn)，根源在于 JavaAgent 通過 agentmain 方式加載到已運行的 JVM 中時，不同于靜態(tài)加載，會在類初次被加載時完成字節(jié)碼的轉換，動態(tài)加載時一些需要被字節(jié)碼增強類已經完成了類加載過程，這時候需要使用 Instrumentation 提供的類重轉換（retransform classes）能力來修改字節(jié)碼，在 Instrumentation 的 Javadoc 中關于這個能力有這樣一段描述：

“The retransformation must not add, remove or rename fields or methods, change the signatures of methods, or change inheritance.（重轉換過程中，我們不能新增、刪除或者重命名字段和方法，不能更改方法的簽名，不能更改類的繼承。）”

從中可以看出，在引入動態(tài)加載能力前，優(yōu)先要保證字節(jié)碼增強時，不可以有上述內容中所描述的限制操作。

不過 Sermant 不太需要擔心這個問題，因為這種限制不僅僅在動態(tài)加載時會觸發(fā)，在多個 JavaAgent 同時使用時也可能會觸發(fā)，可以參考 Sermant 團隊的另一篇文章：《記一次多個 JavaAgent 同時使用的類增強沖突問題及分析》。為了保證在多 Agent 場景下的兼容性，Sermant 的字節(jié)碼增強模板嚴格遵循 Instrumentation API 的限制，因此 Sermant 在兼容性上的不斷改進過程中無心插柳，幫助動態(tài)加載能力鋪平了路。

3.2 如何保證在服務治理插件安裝和卸載時不互相影響？

Sermant 的設計中，通過字節(jié)碼增強引入的服務治理能力，是通過在目標方法上添加服務治理功能切面來完成的，每一個服務治理插件，通過一系列切面的配合來達成最終的服務治理效果。不同的服務治理功能，可能會對同一個目標方法進行處理。但并不會對同一個方法進行多次字節(jié)碼增強，而是通過一次字節(jié)碼增強織入調度切面（onMethodEnter、onMethodExit 等），通過該切面對相關的服務治理能力（通過攔截器實現(xiàn)，每一個切面會對應一個攔截器的列表）進行調度：

對于服務治理能力的調度邏輯我們在另一篇文章《開發(fā)者能力機制解析，玩轉 Sermant 開發(fā)》有講過，本篇不再贅述。

基于框架的基本設計，就需要考慮兩個問題，當插件在動態(tài)安裝時，如何保證不重復字節(jié)碼增強？當插件卸載時，如何保證不會導致有相同目標方法的插件失效。

安裝時如何保證不重復執(zhí)行字節(jié)碼增強？

在字節(jié)碼增強開發(fā)過程中，類文件轉換器（ClassFileTransformer）是一定會接觸到的概念，開發(fā)者需要基于該轉換器來進行字節(jié)碼的處理。在大多數(shù)的字節(jié)碼增強框架中，都會對其進行封裝，用于降低字節(jié)碼處理的難度。Sermant 基于 ByteBuddy 提供的類文件轉換器實現(xiàn)了一種可重入的類轉換器，在插件動態(tài)安裝時，雖然目標方法已經被已安裝的插件增強過了，但此時還是會觸發(fā)類文件轉換（因為動態(tài)安裝插件的過程是獨立的），當觸發(fā)類文件轉換時，所有相關的類文件轉換器都會被喚醒，再次觸發(fā)類文件轉換過程。每次可重入類轉換器被喚醒時，將發(fā)生以下行為：

在 Sermant 中維護了一個針對目標方法的字節(jié)碼增強鎖（AdviceKey 鎖），即針對每一個目標方法，維護了 1 個信號量當做鎖，用于讓各類文件轉換器來檢查目標方法的字節(jié)碼增強狀態(tài)，當目標方法對應的類被類轉換時，就會觸發(fā) Sermant 所提供的類文件轉換器，此時類文件轉換器將嘗試獲取針對目標方法的信號量，如果能獲取信號量，則執(zhí)行對目標方法的字節(jié)碼增強，如果不能獲取，則不執(zhí)行字節(jié)碼增強。

基于字節(jié)碼增強鎖，在轉換器觸發(fā)時，主要有兩條路徑可以走，類文件轉換器會通過目標方法的 AdviceKey(類名 + 方法 hash+ 類加載器組成的一個唯一表示，用于表示字節(jié)碼增強的目標) 來檢查其所關聯(lián)的鎖，判斷當前目標方法是否已被 Sermant 進行過字節(jié)碼增強（織入攔截器調度的切面）：

1.能獲取鎖，說明未被增強：則當前文件轉換器獲取當前 AdviceKey 所關聯(lián)的鎖，將其獲取的鎖通過其對應的插件來維護，并且執(zhí)行字節(jié)碼增強，將服務治理所需的攔截器放入該 AdviceKey 所對應的攔截器列表；

2.不能獲取鎖，說明已被增強：則只將攔截器放入該 AdviceKey 對應的攔截器列表中，不執(zhí)行字節(jié)碼增強。
通過上述機制，就可以保證 Sermant 在安裝不同服務治理插件時，不會進行重復的字節(jié)碼增強，避免無端的性能和資源損耗。

卸載時如何保證不會導致其他插件失效？

當插件需要卸載時，會再次觸發(fā)相關目標類的重轉換，與安裝時不同的是，這次需要被卸載的插件釋放自身已經持有的 AdviceKey 鎖。釋放鎖后，觸發(fā)目標類重轉換時，目標類所對應的各個插件的類文件轉換器將會再次觸發(fā)和安裝時相同的流程：

在這個過程中，未被卸載的插件所提供的對目標類的類文件轉換器，會在目標類重轉換時，再次觸發(fā)，并且只會經歷獲取鎖和字節(jié)碼增強的過程。這樣就保證，如果還有插件需要對該目標方法進行字節(jié)碼增強時，可以獲得目標方法所對應的鎖，不會因為目標方法的交集而導致其他插件能力失效。

審核編輯 黃宇