Java類動態(tài)加載機制在鐵路互聯(lián)網(wǎng)售票中的設(shè)計與實現(xiàn)

王 拓，楊立鵬

（1.中國鐵道科學(xué)研究院 電子計算技術(shù)研究所，北京 100081；2.北京經(jīng)緯信息技術(shù)公司，北京 100081）

Java類動態(tài)加載機制在鐵路互聯(lián)網(wǎng)售票中的設(shè)計與實現(xiàn)

王 拓1，楊立鵬2

（1.中國鐵道科學(xué)研究院 電子計算技術(shù)研究所，北京 100081；2.北京經(jīng)緯信息技術(shù)公司，北京 100081）

鐵路互聯(lián)網(wǎng)售票系統(tǒng)已經(jīng)成為重要的售票渠道，部分高并發(fā)業(yè)務(wù)（比如余票查詢、訂單查詢、常用聯(lián)系人查詢等）運行在分布式內(nèi)存數(shù)據(jù)庫集群中。由于業(yè)務(wù)邏輯維護優(yōu)化的需要，業(yè)務(wù)代碼需要頻繁調(diào)整，通過重啟服務(wù)的方式部署新代碼新業(yè)務(wù)，耗時相當(dāng)長。為提高運維效率，在研究Java類加載機制的基礎(chǔ)上，本文探討了適用于鐵路互聯(lián)網(wǎng)售票系統(tǒng)的代碼動態(tài)部署模塊的設(shè)計和實現(xiàn)過程，進行了測試與分析，并進行了總結(jié)。

鐵路互聯(lián)網(wǎng)售票系統(tǒng)；分布式內(nèi)存數(shù)據(jù)庫集群；Java類動態(tài)加載機制；Java虛擬機

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

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

（1）能夠適應(yīng)鐵路互聯(lián)網(wǎng)售票系統(tǒng)，在線進行升級維護操作，用戶無感知。

（2）能夠適應(yīng)分布式的環(huán)境，可實現(xiàn)多節(jié)點同時部署。

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

本文設(shè)計并實現(xiàn)了應(yīng)用動態(tài)部署模塊，從整體系統(tǒng)、業(yè)務(wù)系統(tǒng)、基本目標(biāo)、具體細(xì)節(jié)等方面滿足上述需求。

1 Java類加載機制的原理

1.1 Java類加載器的體系結(jié)構(gòu)

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

1.1.1 啟動類加載器Bootstrap ClassLoader

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

1.1.2 擴展類加載器Extension ClassLoader

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

1.1.3 應(yīng)用程序類加載器Application ClassLoader

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

1.2 Java類在JVM中的生命周期

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

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

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

（1）加載

JVM通過類的全限定名來獲取定義此類的二進制字節(jié)流，將此字節(jié)流所代表的靜態(tài)存儲結(jié)構(gòu)轉(zhuǎn)化為方法區(qū)的運行時數(shù)據(jù)結(jié)構(gòu)，最后在內(nèi)存中生成一個代表這個類的java.lang.Class對象，作為方法區(qū)這個類的各種數(shù)據(jù)的訪問入口。

（2）驗證

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

（3）準(zhǔn)備

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

（4）解析

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

（5）初始化

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

（6）使用

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

（7）卸載

卸載階段，某個類的對象不再被引用，這個類就會結(jié)束生命周期，其在方法區(qū)內(nèi)的數(shù)據(jù)也會被卸載，從而結(jié)束類的整個生命周期。

2 設(shè)計與實現(xiàn)

2.1 設(shè)計原則

設(shè)計適用于鐵路互聯(lián)網(wǎng)售票系統(tǒng)的應(yīng)用動態(tài)部署模塊，需要考慮兩個方面的因素。

（1）鐵路互聯(lián)網(wǎng)售票系統(tǒng)的特性。

鐵路互聯(lián)網(wǎng)售票系統(tǒng)建立在既有的鐵路客票系統(tǒng)之上，整個系統(tǒng)龐大、復(fù)雜，對可靠性和穩(wěn)定性要求極高。

（2）分布式內(nèi)存數(shù)據(jù)庫集群的構(gòu)成

鐵路互聯(lián)網(wǎng)售票系統(tǒng)的余票查詢、票價查詢、常用聯(lián)系人查詢、訂單查詢等業(yè)務(wù)運行在分布式內(nèi)存數(shù)據(jù)庫集群中，集群中既做業(yè)務(wù)數(shù)據(jù)的存儲，也做業(yè)務(wù)邏輯的執(zhí)行。

考慮到以上業(yè)務(wù)和系統(tǒng)層面的因素，在設(shè)計適用于鐵路互聯(lián)網(wǎng)售票系統(tǒng)的應(yīng)用動態(tài)部署模塊時，應(yīng)按照如下原則：

（1）按照C/S模型設(shè)計，客戶端負(fù)責(zé)讀取即將部署的jar包，并發(fā)送請求到服務(wù)端；服務(wù)端執(zhí)行動態(tài)部署操作。

（2）多節(jié)點的分布式系統(tǒng)中，所有服務(wù)節(jié)點盡可能同時完成動態(tài)部署，且不能存在遺漏的節(jié)點。

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

（4）動態(tài)部署操作支持業(yè)務(wù)邏輯以及Listener等代碼。

（5）程序動態(tài)部署過程的耗時盡可能短，應(yīng)在毫秒級內(nèi)完成，避免對生產(chǎn)應(yīng)用造成較大影響。

（6）需要動態(tài)部署的程序的數(shù)量不宜過多。大量的程序變化，甚至是架構(gòu)的變化將有可能導(dǎo)致不可預(yù)知的錯誤。

2.2 實現(xiàn)方法

2.2.1 實現(xiàn)自定義ClassLoader

代碼動態(tài)部署模塊的核心是實現(xiàn)自定義的ClassLoader。

考慮到鐵路客票系統(tǒng)中應(yīng)用分布式內(nèi)存數(shù)據(jù)庫集群的業(yè)務(wù)普遍具有較大的數(shù)據(jù)規(guī)模，需要使模塊的實現(xiàn)方式盡可能簡單可靠，新代碼的部署難度盡可能較低。

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

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

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

2.2.2 通過唯一標(biāo)識來區(qū)分新舊class

類的唯一標(biāo)識是代碼版本準(zhǔn)確性的根本。

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

除此以外，在保證包名、類名一致的前提下，為快速準(zhǔn)確地識別類，在代碼動態(tài)部署模塊中，將jar包轉(zhuǎn)換為字節(jié)數(shù)組，并對此字節(jié)數(shù)組進行MD5編碼，使用MD5碼串作為當(dāng)前這個jar包的唯一標(biāo)識，當(dāng)檢測到新舊jar的MD5碼相同時，則認(rèn)為代碼沒有改變，否則用新jar包中的代碼覆蓋舊代碼。

2.2.3 采用“C/S模式”實現(xiàn)熱部署功能

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

對于分布式內(nèi)存數(shù)據(jù)庫集群而言，代碼的動態(tài)部署操作需要在系統(tǒng)的所有節(jié)點上準(zhǔn)確地、快速地進行操作，不能有遺漏的節(jié)點，也不能有不一致的節(jié)點。利用分布式內(nèi)存數(shù)據(jù)庫的特性，創(chuàng)建當(dāng)前集群（多個Server服務(wù)端）的單一Client客戶端，可以有效地完成代碼動態(tài)部署到集群的工作。

在動態(tài)部署過程中，新代碼以jar包的形式存放在Client客戶端的某一路徑下，并由Client客戶端發(fā)送到各個Server服務(wù)端上經(jīng)過定制的類加載器中。定制的類加載器把class從字節(jié)數(shù)組恢復(fù)成類，實例化并執(zhí)行。

3 測試與分析

3.1 測試場景說明

3.1.1 測試環(huán)境

分布式內(nèi)存數(shù)據(jù)庫集群服務(wù)器數(shù)量：2臺服務(wù)器，X86平臺。

每臺服務(wù)器上運行2個內(nèi)存數(shù)據(jù)庫節(jié)點，集群規(guī)模共4個節(jié)點。應(yīng)用的熱部署工作在這4個節(jié)點上進行。

3.1.2 測試場景

考慮到集群規(guī)模、業(yè)務(wù)數(shù)據(jù)規(guī)模、業(yè)務(wù)邏輯復(fù)雜度等因素，測試工作選取具有代表性的余票查詢業(yè)務(wù)進行。

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

3.2 測試過程與結(jié)果分析

3.2.1 制定程序演化過程

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

表1 程序版本演化過程表

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

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

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

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

（5）程序1.4版本修改了類結(jié)構(gòu)；

（6）程序1.5版本同時修改了類結(jié)構(gòu)和方法體。

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

圖2 代碼片段：余票查詢邏輯模塊調(diào)用順序

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

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

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

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

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

3.2.2 更新程序版本

隨后通過對程序版本的更新，實現(xiàn)余票查詢結(jié)果的控制。

（1）升級程序至1.1版本

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

圖5 測試過程：動態(tài)部署程序1.1版本后的效果

（2）升級程序至1.2版本

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

圖6 測試過程：動態(tài)部署程序1.2版本后的效果

（3）升級程序至1.3版本

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

a.downloadBoardStationAssignTickets

b.shareRuleBean

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

（4）升級程序至1.4版本

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

圖7 代碼片段：1.4版本

（5）升級程序至1.5版本

在1.5版本的程序中，同時修改了類結(jié)構(gòu)和方法體，將1.4修改的代碼恢復(fù)原狀：

隨后動態(tài)加載程序，查詢余票，結(jié)果如圖8所示，余票數(shù)量能夠正常查詢，并成功預(yù)訂車票2張。

圖8 測試過程：動態(tài)部署程序1.5版本后的效果

3.2.3 結(jié)果分析

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

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

4 結(jié)束語

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

隨著社會經(jīng)濟發(fā)展速度的加快，用戶總是不斷的提出新的業(yè)務(wù)需求，軟件系統(tǒng)更新的速度越來越快，同時對軟件靈活性的要求也越來越高，應(yīng)用動態(tài)部署的功能必將得到更加長遠(yuǎn)的發(fā)展，也會更加完善和穩(wěn)定。

[1]朱建生,周亮瑾,單杏花,王明哲．新一代客票系統(tǒng)總體架構(gòu)研究[J]．鐵路技術(shù)創(chuàng)新，2012（4）.

[2]周逸勛. Java程序動態(tài)更新的研究[D]. 上海：上海交通大學(xué)，2010.

責(zé)任編輯 王 浩

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

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