Java類動態加載機制在鐵路互聯網售票中的設計與實現

王 拓，楊立鵬

（1.中國鐵道科學研究院 電子計算技術研究所，北京 100081；2.北京經緯信息技術公司，北京 100081）

Java類動態加載機制在鐵路互聯網售票中的設計與實現

王 拓1，楊立鵬2

（1.中國鐵道科學研究院 電子計算技術研究所，北京 100081；2.北京經緯信息技術公司，北京 100081）

鐵路互聯網售票系統已經成為重要的售票渠道，部分高并發業務（比如余票查詢、訂單查詢、常用聯系人查詢等）運行在分布式內存數據庫集群中。由于業務邏輯維護優化的需要，業務代碼需要頻繁調整，通過重啟服務的方式部署新代碼新業務，耗時相當長。為提高運維效率，在研究Java類加載機制的基礎上，本文探討了適用于鐵路互聯網售票系統的代碼動態部署模塊的設計和實現過程，進行了測試與分析，并進行了總結。

鐵路互聯網售票系統；分布式內存數據庫集群；Java類動態加載機制；Java虛擬機

鐵路互聯網售票系統自2011年正式上線以來，經過近些年的發展，已經成長為十分重要的鐵路售票渠道。為了使鐵路互聯網售票系統能夠應對超高并發的查詢請求，余票查詢、票價查詢、訂單查詢等業務部署在分布式內存數據庫集群中。集群數據規模達到千萬級，甚至億級。每個集群由數個Java虛擬機（JVM，Java Virtual Machine）組成，一個JVM即一個服務節點（Service Node）[1]。

由于業務邏輯調整維護的需要，部分業務代碼需要頻繁調整。按照以往的方式，需要停止集群服務、更換程序包、啟動集群。余票信息、常用聯系人信息、訂單信息3項關鍵業務在單個集群中數據規模、訪問量龐大，集群重啟耗時較長，亟需實現一個無需重啟集群就能動態部署業務代碼的系統功能支撐模塊，使其滿足以下需求：

（1）能夠適應鐵路互聯網售票系統，在線進行升級維護操作，用戶無感知。

（2）能夠適應分布式的環境，可實現多節點同時部署。

（3）能夠完成支持修改方法內容、局部變量、類變量，支持新增、刪除類。

本文設計并實現了應用動態部署模塊，從整體系統、業務系統、基本目標、具體細節等方面滿足上述需求。

1 Java類加載機制的原理

1.1 Java類加載器的體系結構

從Java虛擬機內部的角度來看，主要有3種類加載器。

1.1.1 啟動類加載器Bootstrap ClassLoader

啟動類加載器由C++語言編寫。默認加載〈JAVA_HOME＞lib目錄中的類庫。在啟動JVM的時候，如果啟動參數中指定了-Xbootclass，啟動類加載器也會加載參數指定路徑中的類庫。

1.1.2 擴展類加載器Extension ClassLoader

擴展類加載器由Java語言編寫。默認加載〈JAVA_HOME＞libext目錄中的類庫，或者加載被java.ext.dirs系統變量所指定的路徑中的所有類庫[2]。

1.1.3 應用程序類加載器Application ClassLoader

應用程序類加載器由Java語言編寫。默認加載用戶類路徑〈CLASSPATH＞上所有目錄中的類庫。如果應用程序中沒有自定義過類加載器，那么它就是程序中默認的類加載器。

1.2 Java類在JVM中的生命周期

類的整個生命周期按順序分如圖1所示的7個階段。

圖1 Java類生命周期的7個階段

這7個階段各自作用如下：

（1）加載

JVM通過類的全限定名來獲取定義此類的二進制字節流，將此字節流所代表的靜態存儲結構轉化為方法區的運行時數據結構，最后在內存中生成一個代表這個類的java.lang.Class對象，作為方法區這個類的各種數據的訪問入口。

（2）驗證

驗證是連接階段的第一步，這一階段的目的是為了確保Class文件的字節流中包含的信息符合當前虛擬機的要求，并且不會危害虛擬機自身的安全。

（3）準備

準備階段是正式為類變量分配內存并設置類變量初始值的階段，這些變量所使用的內存都將在方法區中進行分配。在這一階段中，并不處理實例變量。

（4）解析

解析階段是虛擬機將常量池內的符號引用替換為直接引用的過程。解析階段主要包括：類和接口的解析、字段解析、類方法解析、接口方法解析。

（5）初始化

類初始化階段是類加載過程的最后一步，在這個階段，JVM開始執行類中編寫的Java程序代碼。

（6）使用

使用階段，程序在JVM中運行，完成代碼邏輯含義。

（7）卸載

卸載階段，某個類的對象不再被引用，這個類就會結束生命周期，其在方法區內的數據也會被卸載，從而結束類的整個生命周期。

2 設計與實現

2.1 設計原則

設計適用于鐵路互聯網售票系統的應用動態部署模塊，需要考慮兩個方面的因素。

（1）鐵路互聯網售票系統的特性。

鐵路互聯網售票系統建立在既有的鐵路客票系統之上，整個系統龐大、復雜，對可靠性和穩定性要求極高。

（2）分布式內存數據庫集群的構成

鐵路互聯網售票系統的余票查詢、票價查詢、常用聯系人查詢、訂單查詢等業務運行在分布式內存數據庫集群中，集群中既做業務數據的存儲，也做業務邏輯的執行。

考慮到以上業務和系統層面的因素，在設計適用于鐵路互聯網售票系統的應用動態部署模塊時，應按照如下原則：

（1）按照C/S模型設計，客戶端負責讀取即將部署的jar包，并發送請求到服務端；服務端執行動態部署操作。

（2）多節點的分布式系統中，所有服務節點盡可能同時完成動態部署，且不能存在遺漏的節點。

（3）執行動態部署操作時，按照先清理舊程序，再加載新程序的步驟進行。

（4）動態部署操作支持業務邏輯以及Listener等代碼。

（5）程序動態部署過程的耗時盡可能短，應在毫秒級內完成，避免對生產應用造成較大影響。

（6）需要動態部署的程序的數量不宜過多。大量的程序變化，甚至是架構的變化將有可能導致不可預知的錯誤。

2.2 實現方法

2.2.1 實現自定義ClassLoader

代碼動態部署模塊的核心是實現自定義的ClassLoader。

考慮到鐵路客票系統中應用分布式內存數據庫集群的業務普遍具有較大的數據規模，需要使模塊的實現方式盡可能簡單可靠，新代碼的部署難度盡可能較低。

URLClassLoader類加載器用于從指向 JAR 文件和目錄的 URL 的搜索路徑加載類和資源。這里假定任何以 '/' 結束的 URL 都是指向目錄的。如果不是以該字符結束，則認為該 URL 指向一個將根據需要打開的 JAR 文件。程序中創建的URLClassLoader實例的AccessControlContext線程將在后續加載類和資源時使用。為加載的類默認授予只能訪問URLClassLoader創建時指定的URL的權限。

代碼動態部署模塊中自定義的ClassLoader需要重寫父類如下方法：findClass(String name)、close()、loadClass(String name, boolean resolve)，這樣就實現了尋找指定類、刪除指定類、加載指定類，完成了代碼替換的功能。

代碼動態部署模塊把每個單獨的類和接口編譯成單獨的一個.class文件，這些文件對于Java運行環境來說就是一個個可以動態加載的單元，這些文件只在需要使用程序代碼時才會被加載。我們可以在不重新編譯其它代碼的情況下，只編譯需要修改的單元，并把修改文件編譯后的.class文件放到Java的路徑當中，等到下次該Java虛擬機重新激活時，這個邏輯上的Java應用程序就會加載新修改的.class文件，從而更新自己的功能。

2.2.2 通過唯一標識來區分新舊class

類的唯一標識是代碼版本準確性的根本。

代碼動態部署機制利用“雙親委派機制”來實現，在Java中，一個類用其完全匹配類名作為標識，這里指的完全匹配類名包括包名和類名。但在JVM中一個類用其全名和一個加載類ClassLoader的實例作為唯一標識。

除此以外，在保證包名、類名一致的前提下，為快速準確地識別類，在代碼動態部署模塊中，將jar包轉換為字節數組，并對此字節數組進行MD5編碼，使用MD5碼串作為當前這個jar包的唯一標識，當檢測到新舊jar的MD5碼相同時，則認為代碼沒有改變，否則用新jar包中的代碼覆蓋舊代碼。

2.2.3 采用“C/S模式”實現熱部署功能

“C/S模式”為完成代碼替換奠定了高效集群部署的基礎。

對于分布式內存數據庫集群而言，代碼的動態部署操作需要在系統的所有節點上準確地、快速地進行操作，不能有遺漏的節點，也不能有不一致的節點。利用分布式內存數據庫的特性，創建當前集群（多個Server服務端）的單一Client客戶端，可以有效地完成代碼動態部署到集群的工作。

在動態部署過程中，新代碼以jar包的形式存放在Client客戶端的某一路徑下，并由Client客戶端發送到各個Server服務端上經過定制的類加載器中。定制的類加載器把class從字節數組恢復成類，實例化并執行。

3 測試與分析

3.1 測試場景說明

3.1.1 測試環境

分布式內存數據庫集群服務器數量：2臺服務器，X86平臺。

每臺服務器上運行2個內存數據庫節點，集群規模共4個節點。應用的熱部署工作在這4個節點上進行。

3.1.2 測試場景

考慮到集群規模、業務數據規模、業務邏輯復雜度等因素，測試工作選取具有代表性的余票查詢業務進行。

選取的測試用例是2015年10月1日北京到上海的所有車次。在測試過程中，將記錄節點（JVM進程）的pid和運行時間，以證明沒有重啟節點。

3.2 測試過程與結果分析

3.2.1 制定程序演化過程

根據測試場景，制定如表1所示的程序版本演化過程：

表1 程序版本演化過程表

（1）程序1.0版本為基礎版本，即測試環境中正在運行的代碼，除去支撐功能模塊、服務模塊等，業務邏輯模塊大概有309個Java類型；

（2）程序1.1版本比上一版本減少一個類型；

（3）程序1.2版本比上一版本增加一個類型，恢復至原狀；

（4）程序1.3版本修改了方法體；

（5）程序1.4版本修改了類結構；

（6）程序1.5版本同時修改了類結構和方法體。

按照子邏輯對代碼進行分類，如圖2所示。

圖2 代碼片段：余票查詢邏輯模塊調用順序

在修改代碼、動態部署之前，先檢查分布式內存數據庫的節點數量，可以看到，在邏輯上，4個節點是一個整體，進程號分別是：16123、16124、10850、10851。

選取16123進程，記錄進程信息，如圖3所示。

圖3 測試過程：原始的16123進程信息

在測試環境中，查詢2015年10月1日北京到上海的動車車次（D字頭車次），結果如圖4所示。

圖4 測試過程：用例的原始效果

3.2.2 更新程序版本

隨后通過對程序版本的更新，實現余票查詢結果的控制。

（1）升級程序至1.1版本

在1.1版本的程序中，刪除“downloadBoardSta tionAssignTickets”子邏輯的對應的Java類，動態部署到集群中，隨后再次進行查詢，結果如圖5所示，無法查詢余票信息。

圖5 測試過程：動態部署程序1.1版本后的效果

（2）升級程序至1.2版本

在1.2版本的程序中，恢復“downloadBoardStati onAssignTickets”子邏輯對應的Java類，代碼恢復至原狀，執行查詢，結果如圖6所示。動態部署程序后，可以查詢出余票了。嘗試預訂3張D71次車的一等座，預訂成功。

圖6 測試過程：動態部署程序1.2版本后的效果

（3）升級程序至1.3版本

在1.3版本的程序中，修改方法體，注釋以下邏輯，使其不再生效：

a.downloadBoardStationAssignTickets

b.shareRuleBean

隨后進行查詢，結果與1.1版本類似，同樣無法查詢余票數量。

（4）升級程序至1.4版本

在1.4版本的程序中，修改類結構，將類變量logicSequence的類型由LinkedHashSet〈String＞改為ArrayList〈String＞，隨后進行動態部署，結果如圖7所示。與1.1和1.3版本類似，同樣無法查詢余票數量。可見，修改類結構并沒有產生影響，程序沒有報錯。

圖7 代碼片段：1.4版本

（5）升級程序至1.5版本

在1.5版本的程序中，同時修改了類結構和方法體，將1.4修改的代碼恢復原狀：

隨后動態加載程序，查詢余票，結果如圖8所示，余票數量能夠正常查詢，并成功預訂車票2張。

圖8 測試過程：動態部署程序1.5版本后的效果

3.2.3 結果分析

綜合以上測試過程，代碼能夠被動態加載。從測試開始到結束，進程id沒有變化，如圖9所示，即沒有重啟集群服務，測試達到預期的結果。

圖9 測試過程：動態部署程序1.5版本后的16123進程信息

4 結束語

在生產環境實踐中，自2014年起，代碼動態部署模塊已經平穩可靠的運行在鐵路互聯網售票余票查詢、票價查詢等業務中。應用效果理想，實現了模塊需求，提高了程序部署效率，降低了維護成本，增強了應用的靈活性和擴展性，為保障應急和業務更新奠定了穩定的基礎。

隨著社會經濟發展速度的加快，用戶總是不斷的提出新的業務需求，軟件系統更新的速度越來越快，同時對軟件靈活性的要求也越來越高，應用動態部署的功能必將得到更加長遠的發展，也會更加完善和穩定。

[1]朱建生,周亮瑾,單杏花,王明哲．新一代客票系統總體架構研究[J]．鐵路技術創新，2012（4）.

[2]周逸勛. Java程序動態更新的研究[D]. 上海：上海交通大學，2010.

責任編輯 王 浩

Java class dynamic loading mechanism in Internet Ticketing and Reservation System

WANG Tuo, YANG Lipeng
( 1.Institute of Computing Technologies, China Academy of Railway Sciences, Beijing 100081, China; 2.Beijing Jingwei Information Technology Co., Beijing 100081, China )

Internet Ticketing and Reservation System has been an important channel that sold railway tickets. Some applications were using distributed in-memory database to solve the concurrent access pressure, such as ticket-queryservice, order-query-service, passenger-query-service, etc. Because some business logic code needed to be modif i ed frequently, all the service nodes had to be restarted to deploy new program, while this operation usually took a long time. To improve the eff i ciency of operation and maintenance, based on Java class dynamic loading mechanism, this paper explained the design and implementation of Java class dynamic loading mechanism which was suitable for Internet Ticketing and Reservation System, tested the system module and analyzed the running results of the modules, given a conclusion and some suggestions.

Internet Ticketing and Reservation System; distributed in-memory data base; Java class dynamic loading mechanism; Java virtual machine

U293.22∶TP39

A

1005-8451（2015）11-0030-05

2015-04-10

王 拓，研究實習員；楊立鵬，工程師。