作者 | 凱哥 占峰 李晗等

Sonic是美團內(nèi)部一款用于熱部署的IDEA插件。本文主要講述Sonic的實現(xiàn)細節(jié)以及底層原理，從IDEA插件到自動化部署，再到沉浸式開發(fā)產(chǎn)品閉環(huán)，全方位講述了Sonic在美團的落地與實踐經(jīng)驗。目前業(yè)界對標(biāo)的產(chǎn)品并不多，希望本文能對從事聯(lián)調(diào)/開發(fā)/測試等相關(guān)方向的同學(xué)有所幫助或啟發(fā)。

Sonic是美團內(nèi)部研發(fā)設(shè)計的一款用于熱部署的IDEA插件，本文其實現(xiàn)原理及落地的一些技術(shù)細節(jié)。在閱讀本文之前，建議大家先熟悉一下Spring源碼?、Spring MVC 源碼 、Spring Boot源碼 、Agent字節(jié)碼增強?、Javassist?、Classloader等相關(guān)知識。?

1 前言

1.1 什么是熱部署

所謂熱部署，就是在應(yīng)用正在運行時升級軟件，卻不需要重新啟動應(yīng)用。對于Java應(yīng)用程序來說，熱部署就是在運行時更新Java類文件，同時觸發(fā)Spring以及其他常用第三方框架的一系列重新加載的過程。在這個過程中不需要重新啟動，并且修改的代碼實時生效，好比是戰(zhàn)斗機在空中完成加油，不需要戰(zhàn)斗機熄火降落，一系列操作都在“運行”狀態(tài)來完成。

1.2 為什么我們需要熱部署

據(jù)了解，美團內(nèi)部很多工程師每天本地重啟服務(wù)高達5~12次，單次大概3~8分鐘，每天向Cargo（美團內(nèi)部測試環(huán)境管理工具）部署3~5次，單次時長20~45分鐘，部署頻繁頻次高、耗時長，嚴重影響了系統(tǒng)上線的效率。而插件提供的本地和遠程熱部署功能，可讓將代碼變更“秒級”生效。一般而言，開發(fā)者日常工作主要分為開發(fā)自測和聯(lián)調(diào)兩個場景，下面將分別介紹熱部署在每個場景中發(fā)揮的作用。

圖 1

1.2.1 開發(fā)自測場景

一般來講，在用插件之前，開發(fā)者修改完代碼還需等待3~8分鐘啟動時間，然后手動構(gòu)造請求或協(xié)調(diào)上游發(fā)請求，耗時且費力。在使用完熱部署插件后，修改完代碼可以一鍵增量部署，讓變更“秒級”生效，能夠做到快速自測。而對于那些無法本地啟動項目，也可以通過遠程熱部署功能使代碼變更“秒級”生效。

圖 2

1.2.2 聯(lián)調(diào)場景

通常情況下，在使用插件之前，開發(fā)者修改代碼經(jīng)過20~35分鐘的漫長部署，需要聯(lián)系上游聯(lián)調(diào)開發(fā)者發(fā)起請求，一直要等到遠程服務(wù)器查看日志，才能確認代碼生效。在使用熱部署插件之后，開發(fā)者修改代碼遠程熱部署能夠秒級（2~3s）生效，開發(fā)者直接發(fā)起服務(wù)調(diào)用，可以節(jié)省大量的碎片化時間（熱部署插件還具備流量回放、遠程調(diào)用、遠程反編譯等功能，可配合進行使用）。

圖 3

所以，熱部署插件希望解決的痛點是：在可控的條件內(nèi)，幫助開發(fā)者減少頻繁編譯部署的次數(shù)，節(jié)省碎片化的時間。最終為開發(fā)者每天節(jié)約出一定量的編碼時間。

1.3 熱部署難在哪

為什么業(yè)界目前沒有好用的開源工具？因為熱部署不等同于熱重啟，像Tomcat或者Spring Boot DevTools此類熱重啟模式需要重新加載項目，性能較差。增量熱部署難度較大，需要兼容常用的中間件版本，需要深入啟動銷毀加載流程。以美團為例，我們需要對JPDA（Java Platform Debugger Architecture）、Java Agent、ASM字節(jié)碼增強、Classloader、Spring框架、Spring Boot框架、MyBatis框架、Mtthrift（美團RPC框架）、Zebra（美團持久層框架）、Pigeon（美團RPC框架），MDP（美團快速開發(fā)框架）、XFrame（美團快速開發(fā)腳手架）、Crane（美團分布式任務(wù)調(diào)度框架）等眾多框架和技術(shù)原理深入了解才能做到全面的兼容和支持。另外，還需要IDEA插件開發(fā)能力，形成整體的產(chǎn)品解決方案閉環(huán)，美團的熱部署插件Sonic正是在這種背景下應(yīng)運而生。

圖 4

1.4 Sonic可以做什么

Sonic是美團內(nèi)部研發(fā)設(shè)計的一款I(lǐng)DEA插件，旨在通過低代碼開發(fā)輔助遠程/本地?zé)岵渴穑鉀QCoding、單測編寫執(zhí)行、自測聯(lián)調(diào)等階段的效率問題，提高開發(fā)者的編碼產(chǎn)出效率。數(shù)據(jù)統(tǒng)計表明，開發(fā)者日常大概有35%時間用于編碼的產(chǎn)出。如果想提高研發(fā)效率，要么擴大編碼產(chǎn)出的時間占比，要么提高編碼階段的產(chǎn)出效率，而Sonic則聚焦提高編碼階段的產(chǎn)出效率。目前，使用Sonic熱部署可以解決大部分代碼重復(fù)構(gòu)建的問題。Sonic可以使用戶在本地編寫代碼一鍵部署到遠程環(huán)境，修改代碼、部署、聯(lián)調(diào)請求、查看日志，循環(huán)反復(fù)。如果不考慮代碼修改時間，通常一個循環(huán)需要20~35分鐘，而使用Sonic可以把整個時長縮短至5~10秒，而且能夠給開發(fā)者帶來高效沉浸式的開發(fā)體驗。在實際編碼工作中，多文件修改是家常便飯，Sonic對多文件的熱部署能力尤為突出，它可以通過依賴分析等手段來對多文件批量進行遠程熱部署，并且支持Spring Bean Class、普通Class、Spring XML、MyBatis XML等多類型文件混合熱部署。下面的動圖就演示了多文件復(fù)查場景下的增量熱部署：

那么跟業(yè)界現(xiàn)有的產(chǎn)品相比，Sonic有哪些優(yōu)劣勢呢？下面我們嘗試給出幾種產(chǎn)品的對比，僅供大家參考：

上表未把Sofa-Ark、Osgi、Arthas列舉，此類屬于插件化、模塊化應(yīng)用框架，以及Java在線診斷工具，核心能力非熱部署。值得注意的是，Spring Boot DevTools只能應(yīng)用在Spring Boot項目中，并且它不是增量熱部署，而是通過Classloader迭代的方式重啟項目，對大項目而言，性能上是無法接受的。雖然，JRebel支持三方插件較多，生態(tài)龐大，但是對于國產(chǎn)的插件不支持，例如FastJson等，同時它還存在遠程熱部署配置局限，對于公司內(nèi)部的中間件需要個性化開發(fā)，并且是商業(yè)軟件，整體的使用成本較高。

1.5 Sonic遠程熱部署落地推廣的實踐經(jīng)驗

相信大家都知道，對于技術(shù)產(chǎn)品的推廣，尤其是開發(fā)、測試階段使用的產(chǎn)品，由于遠離線上環(huán)境，推動力、執(zhí)行力、產(chǎn)品功能閉環(huán)能否做好，是決定著該產(chǎn)品是否能在企業(yè)內(nèi)部落地并得到大多數(shù)人認可的重要的一環(huán)。此外，因為很多開發(fā)者在開發(fā)、測試階段已逐漸形成了“固化動作”，如何改變這些用戶的行為，讓他們擁抱新產(chǎn)品，也是Sonic面臨的艱巨挑戰(zhàn)之一。我們從主動溝通、零成本（或極低成本）快速接入、自動化腳本，以及產(chǎn)品自動診斷、收集反饋等方向出發(fā)，踐行出了四條原則。

圖 6

2 整體設(shè)計方案

2.1 Sonic結(jié)構(gòu)

Sonic插件由4大部分組成，包括腳本端、插件端、Agent端，以及Sonic服務(wù)端。腳本端負責(zé)自動化構(gòu)建Sonic啟動參數(shù)、服務(wù)啟動等集成工作；IDEA插件端集成環(huán)境為開發(fā)者提供更便捷的熱部署服務(wù)；Agent端隨項目啟動負責(zé)熱部署的功能實現(xiàn)；服務(wù)端則負責(zé)收集熱部署信息、失敗上報等統(tǒng)計工作。如下圖所示：

圖 7

2.2 走進Agent

2.2.1 Instrumentation類常用API

public interface Instrumentation {

    //增加一個Class 文件的轉(zhuǎn)換器，轉(zhuǎn)換器用于改變 Class 二進制流的數(shù)據(jù)，參數(shù) canRetransform 設(shè)置是否允許重新轉(zhuǎn)換。
    void addTransformer(ClassFileTransformer transformer, boolean canRetransform);

    //在類加載之前，重新定義 Class 文件，ClassDefinition 表示對一個類新的定義，
    //如果在類加載之后，需要使用 retransformClasses 方法重新定義。addTransformer方法配置之后，后續(xù)的類加載都會被Transformer攔截。
    //對于已經(jīng)加載過的類，可以執(zhí)行retransformClasses來重新觸發(fā)這個Transformer的攔截。類加載的字節(jié)碼被修改后，除非再次被retransform，否則不會恢復(fù)。
    void addTransformer(ClassFileTransformer transformer);

    //刪除一個類轉(zhuǎn)換器
    boolean removeTransformer(ClassFileTransformer transformer);
    
    //是否允許對class retransform
    boolean isRetransformClassesSupported();

    //在類加載之后，重新定義 Class。這個很重要，該方法是1.6 之后加入的，事實上，該方法是 update 了一個類。
    void retransformClasses(Class<?>... classes) throws UnmodifiableClassException;
   
    //是否允許對class重新定義
    boolean isRedefineClassesSupported();

    //此方法用于替換類的定義，而不引用現(xiàn)有的類文件字節(jié)，就像從源代碼重新編譯以進行修復(fù)和繼續(xù)調(diào)試時所做的那樣。
    //在要轉(zhuǎn)換現(xiàn)有類文件字節(jié)的地方（例如在字節(jié)碼插裝中），應(yīng)該使用retransformClasses。
    //該方法可以修改方法體、常量池和屬性值，但不能新增、刪除、重命名屬性或方法，也不能修改方法的簽名
    void redefineClasses(ClassDefinition... definitions) throws  ClassNotFoundException, UnmodifiableClassException;

    //獲取已經(jīng)被JVM加載的class，有className可能重復(fù)（可能存在多個classloader）
    @SuppressWarnings("rawtypes")
    Class[] getAllLoadedClasses();
}

2.2.2 Instrument簡介

Instrument的底層實現(xiàn)依賴于JVMTI（JVM Tool Interface），它是JVM暴露出來的一些供用戶擴展的接口集合，JVMTI是基于事件驅(qū)動的，JVM每執(zhí)行到一定的邏輯就會調(diào)用一些事件的回調(diào)接口（如果存在），這些接口可以供開發(fā)者去擴展自己的邏輯。JVMTIAgent是一個利用JVMTI暴露出來的接口提供了代理啟動時加載（Agent On Load）、代理通過Attach形式加載（Agent On Attach）和代理卸載（Agent On Unload）功能的動態(tài)庫。而Instrument Agent可以理解為一類JVMTIAgent動態(tài)庫，別名是JPLISAgent（Java Programming Language Instrumentation Services Agent），也就是專門為Java語言編寫的插樁服務(wù)提供支持的代理。

2.2.3 啟動時和運行時加載Instrument Agent過程

圖 8

2.3 那些年JVM和HotSwap之間的“相愛相殺”

圍繞著Method Body的HotSwap JVM一直在進行改進。從1.4版本開始，JPDA引入HotSwap機制（JPDA Enhancements），實現(xiàn)Debug時的Method Body的動態(tài)性。大家可參考文檔：??enhancements1.4???。1.5版本開始通過JVMTI實現(xiàn)的java.lang.instrument（Java Platform SE 8）的Premain方式，實現(xiàn)Agent方式的動態(tài)性（JVM啟動時指定Agent）。大家可參考文檔：??package-summary???。1.6版本又增加Agentmain方式，實現(xiàn)運行時動態(tài)性（通過The Attach API 綁定到具體VM）。大家可參考文檔：??package-summary?? 。基本實現(xiàn)是通過JVMTI的retransformClass/redefineClass進行method、body級的字節(jié)碼更新，ASM、CGLib基本都是圍繞這些在做動態(tài)性。但是針對Class的HotSwap一直沒有動作（比如Class添加method、添加field、修改繼承關(guān)系等等），為什么會這樣呢？因為復(fù)雜度過高，且沒有很高的回報。

2.4 Sonic如何解決Instrumentation的局限性

由于JVM限制，JDK 7和JDK 8都不允許改類結(jié)構(gòu)，比如新增字段，新增方法和修改類的父類等，這對于Spring項目來說是致命的。比如開發(fā)同學(xué)想修改一個Spring Bean，新增一個@Autowired字段，此類場景在實際應(yīng)用時很多，所以Sonic對此類場景的支持必不可少。那么，具體是如何做到的呢？這里要提一下“大名鼎鼎”的Dcevm。Dcevm（DynamicCode Evolution Virtual Machine）是Java Hostspot的補丁（嚴格上來說是修改），允許（并非無限制）在運行環(huán)境下修改加載的類文件。當(dāng)前虛擬機只允許修改方法體（Method，Body），而Decvm可以增加、刪除類屬性、方法，甚至改變一個類的父類，Dcevm是一個開源項目，遵從GPL 2.0協(xié)議。更多關(guān)于Dcevm的介紹，大家可以參考：??Wuerthinger10a???以及??GitHub Decvm???。值得一提的是，在美團內(nèi)部，針對Dcevm的安裝，Sonic已經(jīng)打通??HULK??，集成發(fā)布鏡像即可完成（本地?zé)岵渴鹂山Y(jié)合插件功能實現(xiàn)一鍵安裝熱部署環(huán)境）。

3 Sonic熱部署技術(shù)解析

3.1 Sonic整體架構(gòu)模型

上一章節(jié)我們主要介紹了Sonic的組成。下圖詳細介紹了Sonic在運行期間各個組成部分的工作職責(zé)，由它們形成一整套完備的技術(shù)產(chǎn)品落地閉環(huán)方案：

圖 9

3.2 Sonic功能流轉(zhuǎn)

Sonic通過NIO監(jiān)聽本地文件變更，觸發(fā)文件變更事件，例如Class新增、Class修改、Spring Bean重載等事件流程。下圖展示了一次熱部署單個文件的生命周期：

圖 10

3.3 文件監(jiān)聽

Sonic首先會在本地和遠程預(yù)定義兩個目錄，??/var/tmp/sonic/extraClasspath???和??/var/tmp/sonic/classes??。extraClasspath為Sonic自定義的拓展Classpath URL，classes為Sonic監(jiān)聽的目錄，當(dāng)有文件變更時，通過IDEA插件來部署到遠程/本地，觸發(fā)Agent的監(jiān)聽目錄，來繼續(xù)下面的熱加載邏輯：

圖 11

為什么Sonic不直接替換用戶ClassPath下面的資源文件呢？因為考慮到業(yè)務(wù)方WAR包的API項目、Spring Boot、Tomcat項目、Jetty項目等，都是以JAR包來啟動的，這樣是無法直接修改用戶的Class文件的。即使是用戶項目可以修改，直接操作用戶的Class，也會帶來一系列的安全問題。所以，Sonic采用拓展ClassPath URL路徑來實現(xiàn)文件的修改和新增。并且存在這么一種場景，多個業(yè)務(wù)側(cè)的項目引入相同的JAR包，在JAR里面配置MyBatis的XML和注解。在此類情況下，Sonic沒有辦法直接來修改JAR包中源文件，通過拓展路徑的方式可以不需要關(guān)注JAR包，來修改JAR包中某一文件和XML。同理，采用此類方法可以進行整個JAR包的熱替換。下面我們簡單介紹一下Sonic的核心監(jiān)聽器，如下圖所示：

圖 12

3.4 JVM Class Reload

JVM的字節(jié)碼批量重載邏輯，通過新的字節(jié)碼二進制流和舊的Class對象生成ClassDefinition定義，instrumentation.redefineClasses（definitions），來觸發(fā)JVM重載，重載過后將觸發(fā)初始化時Spring插件注冊的Transfrom。接下來，我們簡單講解一下Spring是怎么重載的。新增class Sonic如何保證可以加載到Classloader上下文中？由于項目在遠程執(zhí)行，所以運行環(huán)境復(fù)雜，有可能是JAR包方式啟動（Spring Boot），也有可能是普通項目，也有可能是War Web項目，針對此類情況Sonic做了一層Classloader URL拓展。

圖 13

User ClassLoader是框架自定義的ClassLoader統(tǒng)稱，例如Jetty項目是WebAppclassLoader。其中Urlclasspath為當(dāng)前項目的lib文件件下，例如Spring Boot項目也是從當(dāng)前項目BOOT-INF/lib/路徑中加載CLass等等，不同框架的自定義位置稍有不同。所以針對此類情況，Agent必須拿到用戶的自定義Classloader，如果是常規(guī)方式啟動的，比如普通Spring XML項目，借助Plus（美團內(nèi)部服務(wù)發(fā)布平臺）發(fā)布，此類沒有自定義Classloader，是默認AppClassLoader，所以Agent在用戶項目啟動過程中，借助字節(jié)碼增強的方式來獲取到真正的用戶Classloader。

圖 14

找到用戶使用的子Classloader之后，通過反射的方式來獲取Classloader中的元素Classpath，其中ClassPath中的URL就是當(dāng)前項目加載Class時需要的所有運行時Class環(huán)境，并且包括三方的JAR包依賴等。Sonic獲取到URL數(shù)組，把Sonic自定義的拓展Classpath目錄加入到URL數(shù)組首位，這樣當(dāng)有新增Class時，Sonic只需要將Class文件復(fù)制到拓展Classpath對應(yīng)的包目錄下面即可，當(dāng)有其他Bean依賴新增的Class時，會從當(dāng)前目錄下面查找類文件。為什么不直接對Appclassloader進行加強？而是對框架的自定義Classloader進行加強？

圖 15

考慮這樣一個場景，框架自定義類加載器中有ClassA，此時用戶新增ClassB需要熱加載，B Class里面有A的引用關(guān)系，如果增強AppClassLoader，初始化B實例時ClassLoader。loadclass首先從UserClassLoader開始加載ClassB的字節(jié)碼，依靠雙親委派原則，B被Appclassloader加載，因為B依賴類A，所以當(dāng)前AppClassLoader加載B一定是加載不到的，此時會拋出ClassNotFoundException異常。所以對類加載器拓展，一定要拓展最上層的類加載器，這樣才會達到使用者想要的效果。

3.5 Spring Bean重載

Spring Bean Reload過程中，Bean的銷毀和重啟流程，主要內(nèi)容如下圖展示：

圖 16

首先當(dāng)修改Java Class D時，通過Spring ClasspathScan掃描校驗當(dāng)前修改的Bean是否Sprin Bean（注解校驗），然后觸發(fā)銷毀流程（BeanDefinitionRegistry.removeBeanDefinition），此方法會將當(dāng)前Spring上下文中的Bean D和依賴Spring Bean D的Bean C一并銷毀，但是作用范圍僅僅在當(dāng)前Spring上下文。如果C被子上下文中的Bean B依賴，就無法更新子上下文中的依賴關(guān)系，當(dāng)有系統(tǒng)請求時，Bean B中關(guān)聯(lián)的Bean C還是熱部署之前的對象，所以熱部署失敗。因此，在Spring初始化過程中，需要維護父子上下文的對應(yīng)關(guān)系，當(dāng)子上下文變時若變更范圍涉及到Bean B時，需要重新更新子上下文中的依賴關(guān)系，當(dāng)有多上下文關(guān)聯(lián)時需要維護多上下文環(huán)境，且當(dāng)前上下文環(huán)境入口需要Reload。這里的入口是指：Spring MVC Controller、Mthrift和Pigeon，對不同的流量入口，采用不同的Reload策略。RPC框架入口主要操作為解綁注冊中心、重新注冊、重新加載啟動流程等等，對Spring MVC Controller，主要是解綁和注冊URL Mappping來實現(xiàn)流量入口類的變化切換。

3.6 Spring XML重載

當(dāng)用戶修改/新增Spring XML時，需要對XML中所有Bean進行重載。

圖 17

重新Reload之后，將Spring銷毀后重啟。需要注意的是：XML修改方式改動較大，可能涉及到全局的AOP的配置以及前置和后置處理器相關(guān)的內(nèi)容，影響范圍為全局，所以目前只放開普通的XML Bean標(biāo)簽的新增/修改，其他能力酌情逐步放開。

3.7 MyBatis 熱部署

Spring MyBatis熱部署的主要處理流程是在啟動期間獲取所有Configuration路徑，并維護它和Spring Context的對應(yīng)關(guān)系，在熱部署Class、XML時去匹配Configuration，從而重新加載Configuration以達到熱部署的目的。

圖 18

4 總結(jié)

4.1 熱部署功能一覽

上一章節(jié)主要講述了Spring Bean、Spring MVC、MyBatis的重載流程，Sonic還支持其它常用的開發(fā)框架，豐富的框架支持和兼容能力是Sonic的基石，下面列舉一些Sonic支持的常用的第三方框架：

圖19

美團內(nèi)部框架以及常用開源框架截止目前，Sonic已經(jīng)支持絕大部分常用第三方框架的熱加載，常規(guī)業(yè)務(wù)開發(fā)幾乎無需重啟服務(wù)。并且在美團內(nèi)部的成功率已經(jīng)高達99.9%以上，真正地讓熱部署來代替常規(guī)部署構(gòu)建成為一種可能。

4.2 IDE插件集成

Sonic也提供了功能強大的IDEA插件，讓用戶進行沉浸式開發(fā)，遠程熱部署也變得更加便利。

圖 20

4.3 推廣使用情況

截止到發(fā)稿時，Sonic在美團使用人數(shù)3000+，應(yīng)用項目數(shù)量2000+。該項目還獲得了美團內(nèi)部2020年下半年到家研發(fā)平臺“最佳效率團隊”獎。

5 作者簡介

凱哥、占峰、李晗、龔炎、程驍、玉龍等，均來自美團/到家研發(fā)平臺。

6 參考文章

?[1] 基于Javassist和Javaagent實現(xiàn)動態(tài)切面[2] Spring MVC 源碼解析[3] Spring IOC源碼解析[4] MyBatis源碼解析[5] Spring Boot源碼解析[6] Spring AOP源碼解析[7] Spring事務(wù)源碼解析[8] Cglib源碼解析[9] JDK Proxy源碼解析[10] Dcevm簡介[11] 字節(jié)碼增強技術(shù)探索[12] Javassist API