王 鵬，從 波，李國杰，匡海燕，劉靜靜

(許繼電氣股份有限公司，河南 許昌 461000)

0 引 言

當(dāng)前，互聯(lián)網(wǎng)和電子行業(yè)正在蓬勃發(fā)展.軟件需要提供更加健壯、 敏捷、 有效的服務(wù)[1].隨著信息技術(shù)的不斷進步，互聯(lián)網(wǎng)技術(shù)的飛速發(fā)展，日常事務(wù)更加依賴于各種各樣的IT系統(tǒng)，促使應(yīng)用系統(tǒng)大量的開發(fā)和部署，這些系統(tǒng)極大地提高了企業(yè)的信息化程度[2].但同時由于各個系統(tǒng)采用的平臺和技術(shù)存在很大的差異，導(dǎo)致這些系統(tǒng)彼此互相獨立和分離，系統(tǒng)之間的通信變得越來越困難，出現(xiàn)了“信息孤島”的現(xiàn)象[3].而網(wǎng)絡(luò)技術(shù)的高速發(fā)展為此提供了更好的解決方案，計算環(huán)境由分布式取代傳統(tǒng)的集中式，由消息中間件[4]來提供各系統(tǒng)間的消息傳遞.

消息總線是一種可以跨越進程的通信機制，用于系統(tǒng)間及上下游的消息傳遞.消息總線承擔(dān)系統(tǒng)內(nèi)實時消息傳輸功能，為上層應(yīng)用屏蔽了繁瑣復(fù)雜的底層通信細(xì)節(jié)[5].消息總線的引入有效降低了各系統(tǒng)或模塊間的耦合程度，但同時消息總線的性能效率也成為影響整個系統(tǒng)性能的關(guān)鍵因素.如何選擇能夠滿足整個系統(tǒng)要求的消息中間件成為系統(tǒng)開發(fā)過程中不可缺少的環(huán)節(jié).

1 基于ActiveMQ的消息總線介紹

ActiveMQ[6]作為消息中間件，被廣泛應(yīng)用于企業(yè)級消息總線的設(shè)計.它是由Apache開發(fā)并發(fā)布的一款開源的消息中間件，具有獨立通用的基本特性，支持集群[7]，支持訂閱-發(fā)布和負(fù)載均衡兩種消息收發(fā)模式[8]，支持持久化和非持久化兩種消息存儲模式，支持持續(xù)和非持續(xù)兩種訂閱模型，具備跨平臺的特性，可以適應(yīng)目前大多數(shù)的企業(yè)級應(yīng)用.

本文旨在對ActiveMQ本身的性能層面開展全面的測試和分析，此節(jié)將主要從應(yīng)用的角度，對以下4個性能影響較大的方面展開描述.

1.1 訂閱-發(fā)布模式

訂閱-發(fā)布模式，即類似于傳統(tǒng)的異步消息收發(fā)模式.在“訂閱-發(fā)布”模式下，所有需要某主題(Topic)的消費者(Consumer)均需要“訂閱”該主題(Topic)，而消息生產(chǎn)者(Message)發(fā)布該消息后，消息總線會將該消息復(fù)制多份，分別發(fā)送給所有“訂閱”的消費者，如圖 1 所示.

圖 1 訂閱-發(fā)布模式消息傳遞圖Fig.1 Sub-pub mode messaging

1.2 負(fù)載均衡模式

負(fù)載均衡模式，即類似于傳統(tǒng)的同步消息收發(fā)模式.在“負(fù)載均衡”模式下，消息消費者和消息生產(chǎn)者進行“點對點”的方式進行通信.消息生產(chǎn)者(Message)僅會發(fā)送消息給一個消息消費者，消息消費者將及時給予回復(fù)，實現(xiàn)兩者之間的點對點有效通信，如圖 2 所示.

圖 2 負(fù)載均衡模式消息傳遞圖Fig.2 Load balance mode messaging

1.3 持久化消息存儲及持續(xù)訂閱模型

持久化和非持久化消息存儲，主要是指消息生產(chǎn)者發(fā)布消息之后，消息中心服務(wù)器是否進行持久化的存儲.

持續(xù)訂閱和非持續(xù)訂閱，主要是針對“訂閱-發(fā)布”模式.即當(dāng)訂閱者注冊為持續(xù)訂閱時，即便訂閱者已經(jīng)下線，“訂閱-發(fā)布”模式下的隊列仍將持續(xù)保存消息的發(fā)布，直到訂閱者獲取該條消息為止，與訂閱者是否在線無關(guān).

2 主要性能測試內(nèi)容及方法

在軟件測試過程中，性能測試能夠評測系統(tǒng)的運行性能，然后結(jié)合系統(tǒng)性能來改進軟件對于系統(tǒng)的基本運行要求[9].

目前國內(nèi)外對ActiveMQ消息總線更加關(guān)注其消息傳遞的可靠性，對性能測試研究較少，大多是在形成完整系統(tǒng)后通過黑盒測試方法進行整體驗證，而忽略了消息總線本身的性能瓶頸.本文通過白盒的測試方法，直接對消息總線本身進行性能測試.

消息總線主要性能指標(biāo)將體現(xiàn)在消息的轉(zhuǎn)發(fā)延時及轉(zhuǎn)發(fā)吞吐量等方面.而基于ActiveMQ設(shè)計的消息總線，對其性能測試相關(guān)內(nèi)容的確定，將結(jié)合同步及異步的傳輸模式、 持久化和非持久化存儲及持續(xù)和非持續(xù)訂閱等多重組合情況，考慮對轉(zhuǎn)發(fā)延時和轉(zhuǎn)發(fā)吞吐量的影響.區(qū)別于普通的黑盒性能測試方法，本文主要從源碼的角度探討其更加精確的性能數(shù)據(jù)獲取方法.測試框架如圖 3 所示，各分布式主機通過測試驅(qū)動調(diào)用消息中間件服務(wù)，從而完成對消息的生產(chǎn)和消費.

圖 3 消息中間件測試框架圖Fig.3 Message middleware test framework

結(jié)合以上描述，本節(jié)將從以下幾個方面對基于ActiveMQ的消息總線開展性能測試.

2.1 訂閱-發(fā)布模式轉(zhuǎn)發(fā)延時

圖 4 訂閱-發(fā)布模式轉(zhuǎn)發(fā)延時測試環(huán)境圖Fig.4 Sub-pub mode forwarding time-delay test environment

2.2 訂閱-發(fā)布模式吞吐量

圖 5 訂閱-發(fā)布模式吞吐量測試環(huán)境圖Fig.5 Sub-pub mode throughput test environment

2.3 負(fù)載均衡模式轉(zhuǎn)發(fā)延時

圖 6 負(fù)載均衡模式轉(zhuǎn)發(fā)延時測試環(huán)境圖Fig.6 Load balance mode forwarding time-delay test environmen

2.4 負(fù)載均衡模式吞吐量

圖 7 負(fù)載均衡模式吞吐量測試環(huán)境圖Fig.7 Load balance mode throughput test environment

2.5 測試設(shè)計

以訂閱-發(fā)布模式吞吐量為例，充分利用開源代碼的消息生產(chǎn)函數(shù)，以及消息接收回調(diào)函數(shù)進行消息生產(chǎn)和消費.利用系統(tǒng)納秒時間獲取函數(shù)System::nanoTime()獲取精確時間，從而計算出更加精確的性能數(shù)據(jù).設(shè)計主要考慮以下幾個方面：

1) 消息消費端接收回調(diào)模塊： 等待對應(yīng)消息發(fā)布后進入消息消費回調(diào)模塊，接收到數(shù)據(jù)后，對其進行驗證，并記錄接收消息個數(shù)，當(dāng)接收消息達到設(shè)置的發(fā)送最大條數(shù)時，返回一條消息給消息發(fā)布端.

2) 消息發(fā)布端發(fā)送模塊： 采用循環(huán)調(diào)用的方式進行消息批量生產(chǎn)，記錄發(fā)送初始時鐘，即圖 4 中的TA1，設(shè)置等待消息正確接收標(biāo)記.

3 測試應(yīng)用案例

3.1 測試對象架構(gòu)

由ActiveMQ作為消息中間件[10,11]配置消息中心服務(wù)器，將其開放接口進行封裝供客戶端和控制中心程序使用，基于其訂閱-發(fā)布和負(fù)載均衡兩種消息收發(fā)模式，實現(xiàn)異步和同步兩種通信模式.

異步模式為客戶端向控制中心上送消息.客戶端作為消息生產(chǎn)者，連接到消息總線，向指定主題(Topic)發(fā)送消息，控制中心作為消息消費者，如果訂閱了該主題(Topic)，則可以收到該消息.若其它客戶端或終端軟件對該消息感興趣，也可以訂閱該主題，并會同時收到該消息.

同步模式為控制中心向客戶端同步請求數(shù)據(jù).控制中心針對某一客戶端發(fā)出同步數(shù)據(jù)請求命令，被請求的客戶端收到消息后需立即對該消息做出響應(yīng)并按照同步數(shù)據(jù)請求命令中指定的目標(biāo)隊列(Queue)返回應(yīng)答結(jié)果.

消息總線性能測試主要架構(gòu)如圖 8 所示.

圖 8 消息總線性能測試環(huán)境架構(gòu)圖Fig.8 Message bus performance testing environment architecture

3.2 測試軟硬件環(huán)境配置

測試用的客戶端、 控制中心以及消息中心服務(wù)器配置如表 1 所示.

表 1 測試軟硬件配置環(huán)境

3.3 測試結(jié)果

結(jié)合以上測試方法，對消息總線同步/異步通信方式，以及持久化和非持久化存儲，持續(xù)和非持續(xù)訂閱等分別開展測試，結(jié)果如下：

1) 異步模式轉(zhuǎn)發(fā)延時及吞吐量

轉(zhuǎn)發(fā)延時測試時，依次發(fā)送100 000條消息，消息長度分別設(shè)置為1, 10, 20 KByte 等，通過計算獲取其平均轉(zhuǎn)發(fā)延時，測試記錄如表 2 所示.

表 2 異步模式轉(zhuǎn)發(fā)延時記錄

吞吐量測試時，一次性發(fā)送100 000條消息，消息長度分別設(shè)置為1, 10, 20 KByte 等，通過計算獲取其轉(zhuǎn)發(fā)吞吐量，測試記錄如表 3 及表 4 所示.

表 3 異步模式轉(zhuǎn)發(fā)消息條數(shù)吞吐量記錄

表 4 異步模式轉(zhuǎn)發(fā)數(shù)據(jù)量吞吐量記錄

2) 同步模式轉(zhuǎn)發(fā)延時及吞吐量

同步模式不必考慮存儲和訂閱方式，一次發(fā)送100 000條消息，消息長度分別設(shè)置為1, 10, 20 KByte等，通過計算獲取其轉(zhuǎn)發(fā)延時及吞吐量，如表 5 所示.

表 5 同步模式轉(zhuǎn)發(fā)延時及吞吐量記錄

3.4 測試分析

通過以上案例應(yīng)用，該測試方法能夠利運用ActiveMQ的開放接口，獲取到單條性能數(shù)據(jù)，同時能夠支撐批量性能測試，能夠成功獲取較為精確的性能數(shù)據(jù)，對基于ActiveMQ的消息總線應(yīng)用有一定的指導(dǎo)意義.測試結(jié)果顯示：

在異步(訂閱-發(fā)布)模式下，在轉(zhuǎn)發(fā)延時方面，選擇持久化存儲或持久化訂閱方案后，實際性能影響并不大，在同一數(shù)量級； 在轉(zhuǎn)發(fā)吞吐量方面，轉(zhuǎn)發(fā)的數(shù)據(jù)量在消息長度為10 KByte左右時，達到峰值約790 Mbit/s，約占用千兆網(wǎng)絡(luò)的80%； 轉(zhuǎn)發(fā)吞吐量在選擇持續(xù)訂閱且持久化存儲模式時，會造成轉(zhuǎn)發(fā)吞吐量的明顯變化，特別是消息長度較小時(1 KByte)，其數(shù)據(jù)吞吐量與其他幾種模式相差30倍以上.

在同步(負(fù)載均衡)模式下，隨著數(shù)據(jù)長度的增加，消息的平均轉(zhuǎn)發(fā)延時略有增加，但整體數(shù)據(jù)吞吐量會明顯增大，為提高傳輸效率，可以適當(dāng)對短消息進行合并，再進行消息發(fā)布.

4 總 結(jié)

本文在充分分析基于ActiveMQ消息總線關(guān)鍵性能指標(biāo)的基礎(chǔ)上，提出了從源碼角度獲取精確性能數(shù)據(jù)的性能測試方法.結(jié)合實際硬件環(huán)境，使用該方法對基于ActiveMQ的消息總線開展了性能測試，從異步(訂閱-發(fā)布)和同步(負(fù)載均衡)不同傳輸模式，持久化和非持久化不同存儲方式，以及持續(xù)和非持續(xù)訂閱等角度進行測試分析.結(jié)果顯示，該方法能夠正確獲取較為精確的性能數(shù)據(jù)，找到各種模式下能夠發(fā)揮最優(yōu)性能的配置，為基于ActiveMQ消息總線的應(yīng)用提供參考及改進思路.