面向Spring的熱點代碼在線部署方法研究

萬嘉龍,況立群,熊風光,薛紅新,韓 燮

(中北大學 大數據學院,山西 太原 030051)

0 引 言

隨著業務不斷變更和功能持續迭代,人們對軟件更新方式的要求越來越高。個人的開發經驗、團體的技術積累以及需求的不斷變化,都會增加軟件部署的復雜度和風險。在實際開發中,項目集成以及組件的更新會消耗大量的時間,并且存在眾多潛在風險,往往等到項目開發結束的時候,才可能發現這些問題,最終可能導致項目延期。持續集成與部署可以使項目實施過程透明化,進而完善開發結構,改進開發質量,降低交付風險[1]。隨著國家數字化進程的推進,越來越多的項目采用這種開發方式,持續集成在應用系統中發揮著越來越重要的作用[2]。

傳統上通常使用人工干預的持續化部署模式,通過各種交互式手段完成自動化流程,以此實現對應的代碼部署以及功能上線。Jenkins是一款持續集成和持續交付的開源軟件,常用于項目部署,不僅提供了直觀友好的用戶界面,而且可減少由于人工直接部署導致項目出現的系統兼容和版本沖突等問題[3]。但是這種方式不適用于部署頻繁改動的熱點代碼,因為這將導致頻繁的對整個應用程序進行重新打包以及手工部署,由此產生較高的學習成本,且效率相對較低。

目前主流的部署方式大多采用Docker等虛擬容器,其本質上是一個內部封裝Jenkins或與Jenkins同類插件的系統[4-5]。虛擬化的持續化部署方式可以減少系統開銷,同時增加容器化的可移植性[6-8]。如果直接將應用部署到系統中,一旦系統環境發生變化,會引發應用程序的運行風險。虛擬容器的部署方式降低了部署難度和部署風險,并且在代碼頻繁改動的環境下,可以提高部署效率。但是,該方式仍然需要打包部署全部應用程序,無法僅針對局部熱點代碼進行部分編譯部署,因此沒有從根本上解決熱點代碼部署效率低下的問題。

針對熱點代碼部署效率低下的問題,該文借鑒低代碼設計思想,提出一種面向Spring的熱點代碼在線部署方式,為專業計算機從業人員提供新穎的軟件開發部署模式,提升代碼質量及部署效率[9-10]。該方法根據Bean容器找到對應的算法代碼段進行數據抽取,利用在線部署的方式對代碼進行編譯、注冊及替換等操作,實現局部業務功能的在線更新。該方法應用于新型智慧城市評估系統,通過測試熱點代碼的頻繁更新迭代,驗證了在線部署模式的高效性。

1 在線編譯的容器化加載機制

Java的編譯分兩個部分,首先將源文件編譯成字節碼文件,然后字節碼文件被虛擬機加載以后變成機器碼[11]。對于開發者來講,主要的關注點在第一部分。在Spring的在線編譯中,應用內設置錨點,應用外編譯代碼,再將指定的功能加入到應用程序,這種在線編譯的加載機制可將代碼信息按照自定義格式加載到對應的環境中。而容器化的機制是將編譯好的對應代碼加入到Spring容器管理目錄,其關鍵思想是將新增的功能代碼直接加載到應用,無需拉取所有代碼進行編譯發布[12]。

在線編譯的容器化加載機制如圖 1所示。前臺將代碼與類名稱傳入服務端,構成輸入參數,將其連同程序構建的編譯參數、輸出參數以及程序錯誤輸出參數一起傳入到JavaCompiler編譯工具類。待JavaCompiler執行成功輸出對應類的class文件,如果執行失敗將在程序錯誤輸出中寫入失敗信息。容器化過程將類名稱轉化成相應的Bean名稱并構成Bean定義,連同class文件一起傳入Bean工廠,由Bean工廠生成相應的Bean容器并添加至Spring容器列表。

圖1 在線編譯的容器化加載機制

2 熱點代碼在線部署方法

2.1 在線部署流程

在線部署模塊是由容器配置模塊、熱點代碼編譯模塊和容器裝載模塊組成。用戶按照定義好的格式在容器化管理列表的代碼編輯功能頁面下進行代碼編輯,并通過代碼檢查。前端將代碼信息傳輸至在線部署模塊的服務端,服務端對獲取的信息進行解析,確定符合容器定義規范后,再對代碼進行編譯并生成編譯文件。在線部署模塊將對應的文件傳輸到系統指定的目錄下,通過Spring將文件注冊到Bean列表,并交由Spring進行管理,具體流程如圖 2所示。

當應用系統新增功能時,應用系統首先要調用API實例化容器,然后提取相應的屬性信息,最后由在線部署模塊將應用數據裝入執行單元,完成功能的調用。系統維護的過程中,如果目標執行功能有變動,需要對目標執行功能進行卸載再由在線部署模塊完成功能的新增。而在執行功能卸載時,應用系統需要通過容器化管理列表查詢Bean容器的信息,在Spring中將該容器卸載,在線部署模塊通過查找元信息中存儲的類名來刪除對應的編譯文件,同時刪除存放的Bean信息和類文件。

2.2 容器配置模塊

容器配置模塊是基于當前流行的React框架并使用NodeJs進行編譯的前端平臺。該平臺使用React語言主要基于兩方面的原因,一方面是React使用虛擬Dom對頁面進行渲染,這種方法比直接操作Dom樹速度更快,另一方面React可以對功能細粒度進行封裝,從而提升組件的復用,且手動優化性能更加便利,所以大型項目往往都會選擇React作為基礎框架[13]。

圖2 熱點代碼在線部署方法

如圖3所示,容器配置模塊是由容器化管理列表與對外提供服務兩個部分組成,其功能是為系統提供應用管理、代碼編輯以及對外服務的API。其中應用管理的功能是為在線部署模塊展示注入的應用功能狀態,以及對應用功能進行基本操作。而代碼編輯模塊為容器化管理列表提供代碼編輯和代碼檢查的功能,方便使用者能夠摒棄繁瑣的配置,專注于指定功能的代碼編輯。為了使系統更加方便地調用容器配置模塊所構建的功能,在容器配置模塊中加入了對外服務的API,使應用系統能夠依靠簡單的配置就可以完成對注入功能的測試,同時也能為容器化管理列表提供對應的功能索引,方便進行應用功能的基本操作。

圖3 容器配置模塊結構

2.3 代碼編譯模塊

代碼編譯模塊使用了Java軟件開發包中自帶的java-tools動態編譯模塊,可以對字符串構成的代碼進行編譯,并能提供豐富的編譯接口。該模塊將從前端傳輸來的代碼和元信息存儲到數據庫,并將數據庫中的對應狀態標記為傳輸完成。隨后,代碼在該模塊進行編譯,如果編譯成功,模塊生成編譯文件,并將生成的文件放到指定位置,然后把編譯成功的狀態傳輸到容器裝載模塊,接著執行后續操作。反之將編譯失敗的信息,連同對應的元信息一起傳輸到數據庫中,并將數據庫中的對應狀態標記為編譯失敗。

常規采用的重新編譯部署方式如圖4的上部分所示,重新編譯部署方式在功能修改時,由用戶開發好相應的功能代碼,并將代碼上傳至代碼管理平臺。用戶要完成應用的部署還需使用持續集成工具Jenkins,將代碼拉取至服務端,Jenkins在服務端對代碼進行編譯,然后編譯生成Jenkins構件,啟動構件即完成部署。該文采用基于在線部署的編譯方式(見圖4下半部分),用戶是在在線部署模塊中進行編碼,服務端僅負責接收和編譯由在線部署模塊傳輸過來的代碼,之后將生成的文件通過Spring的環境直接注入到系統中,進而完成項目的部署。與重新編譯部署方法相比,在線部署編譯方式減少了代碼拉取以及構件啟動的時間。在應用功能未確定時,功能的改變會引發頻繁部署,采用在線部署方法可以節省很多的時間。

圖4 重新編譯部署與在線部署的編譯方式對比

2.4 容器裝載模塊

容器裝載流程如圖5所示。

圖5 容器裝載流程

容器裝載模塊將Spring應用環境的上下文實例化,通過加載具有復合注解的代碼,將應用功能注入到Spring環境。該模塊從編譯模塊獲取編譯成功的文件和元信息并加入到Bean處理單元,然后將新生成的Bean容器注冊到Spring環境。如果注冊成功,則依據元信息在數據庫中找到指定記錄,并將其狀態更新為部署成功,然后把對應的狀態寫入到日志管理器,反之,注冊失敗則標記部署失敗。

容器注冊的核心是將熱點代碼轉化成Bean容器。對所需功能注冊時,將類名與Bean的ID進行綁定,保證在Bean注冊機制下,注冊的容器是唯一有效的。容器是整個Spring環境的重要組成部分,在應用系統中,Bean的實例化獲取與銷毀都由Spring進行管理。如圖6所示,當在線部署某一應用程序時,采用不停機的工作模式,事先定義好該程序的計算接口和數據信息接口,然后在代碼編輯模塊中實現上述兩個接口。其中,計算接口用于實現具體的應用功能,而數據信息接口用于實現容器配置模塊對應用功能的管理。接口代碼完成編譯后,Spring調用Bean管理器將轉化好的容器注冊到容器列表,為代碼無侵入做準備。應用在停機部署時,卸載在線部署模塊不會影響系統的使用。依據不同開發階段的要求,在線部署模塊可以靈活制定相應的部署策略,降低開發與運維的工作難度,保障系統的穩定,降低項目管理成本。

圖6 運行與停機狀態下的容器注冊方法

3 性能測試與分析

3.1 實驗環境

實驗的硬件環境是Intel(R)Corn(TM)i7-7700HQ CPU @ 2.8 Hz 2.81 GHz,內存為8 GB,軟件環境為windows tomcat idea2022。實驗在Spring官網下生成空白的項目,添加相應的功能構建不同復雜度的系統,以便對比不同部署方式的部署效率。

3.2 評價標準

為了評估應用在不同軟件復雜度下的在線部署方法與重新編譯部署方法的效率,采用不同維度下的軟件復雜度進行實驗,衡量軟件復雜度的常用度量方法,包括代碼行數度量法和Halstead度量法。其具體構建如下:

代碼行數度量法在空白項目中寫入100行代碼形成一個請求單元,標識系統擁有100的復雜度,將代碼請求單元擴增至10個請求單元,可以使代碼行數復雜度增加10倍,變為1 000的復雜度,以此類推,構建10 000、100 000的代碼行數復雜度的測試項目。同理,使用Halstead度量法構建不同復雜度的項目,向空白項目中寫入定義好的度量單位為100的模塊,以此為模板擴增,與代碼行數復雜度一致,分別增加至10 000和100 000的復雜度。度量單個單元復雜度的Halstead公式如下所示:

Mcount=0.05(N+N1)

其中,N為程序詞匯表的長度,N1為程序長度,為了與代碼行數度量法的對比更加直觀,設定了0.05的系數。

3.3 實驗結果

對重新編譯部署與在線部署兩種方法在時間效率上進行對比,從程序開始編譯計時,到實際應用部署為止,得出各自所需的時間。實驗中選擇不同度量法下的不同系統復雜度,在進行10次相對獨立的實驗后取平均值。其中T1表示在線部署的時間,T2表示重新編譯部署的時間,T1/T2是兩種部署模式下的時間比值。

表1 兩種部署方式在代碼行數復雜度下的對比

表2 兩種部署方式在Halstead復雜度下的對比

如表1和圖7所示,隨著代碼行數復雜度的增加,在線部署的時間明顯小于重新編譯部署的時間,并隨著代碼行數復雜度的增加,時間比值在逐漸下降。如表2和圖8所示,Halstead復雜度和代碼行數復雜度的結果基本一致。結果表明,在線部署比重新編譯部署效果更好,推廣到現在大規模、復雜性高的系統中,運用該熱部署方法部署代碼更有利于節約時間和資源。

圖7 兩種部署方式在代碼行數復雜度下的對比

圖8 兩種部署方式在Halstead復雜度下的對比

4 系統應用

該文提出的在線部署方法應用于新型智慧城市評估系統的評估體系構建模塊。隨著城市的不斷發展,城市評價的指標體系也在不斷地進步,指標計算也越來越復雜。在系統業務開發的過程中,對城市評估的評估體系往往考慮得不夠全面,所以在系統運行初期,會不斷地調整指標中的評估算法,與之相對應的測試環境以及預生產環境的應用也需要頻繁地部署。針對這種情況,系統為其設計了可在線編輯的指標計算模塊,該模塊通過在線操作完成新指標的部署。

當用戶對指標計算模塊編輯時,先在指標編輯的模塊中對指標計算的算法進行編輯,之后系統根據算法的名稱和配置構建元信息,將代碼連同元信息一起傳輸到系統后臺,并在后臺對算法進行編譯,然后將編譯后的文件通過Spring注入到容器列表,即可完成對應指標的部署。在對城市評估的時候,評估系統使用元信息查找到對應的算法,完成指標的計算。該在線部署方法為在線評估系統的指標拓展計算提供了思路,同時很好地解決了頻繁部署熱點代碼的問題。

5 結束語

研究了基于Spring的在線熱點代碼部署方法,并在新型智慧城市評估系統進行了驗證。在系統部署的過程中,運維人員會將所有的代碼拉取到服務器中,對應用重新部署。功能應用在頻繁改動的時候,重復拉取代碼后進行部署,很容易導致一些問題出現。該方法能夠使應用系統集成的在線部署模塊在不停機的狀態下,穩定地增加功能,并以較快的速度部署,同時在應用必須停機時,卸載在線部署模塊,零配置重新部署功能 。該文設計的在線部署方法有望在緊急上線、預生產環境調試等環境下發揮作用[14-15]。

同時,該部署方案還有進一步完善的空間。在應用過程中熱點的代碼只能修改單獨的類,只能在線單獨改變其中一個功能,這種方法免去了代碼的整包構建,提升了速率。但是這種方案僅僅只能在熱點代碼中使用,不適合大范圍的修改代碼,此外對于復雜環境的分布式系統,還需要考慮各個層級的依賴問題。