【摘要】針對(duì)電商交易接入平臺(tái)的需求，結(jié)合平臺(tái)的高性能與高可靠性特點(diǎn)，提出了采用J2EE分布式技術(shù)進(jìn)行系統(tǒng)實(shí)施的方案，對(duì)電商交易接入平臺(tái)的架構(gòu)進(jìn)行了設(shè)計(jì)，并分析和討論關(guān)鍵技術(shù)點(diǎn)。最后還對(duì)系統(tǒng)進(jìn)行了性能壓力測試，以保證系統(tǒng)的安全穩(wěn)定運(yùn)行。

【關(guān)鍵詞】J2EE分布式電子商務(wù)接入平臺(tái)高性能高可靠性

中圖分類號(hào)：TP311.1文獻(xiàn)標(biāo)識(shí)碼：A文章編號(hào)：1006-1010(2014)-10-0090-07

Research and Design of High-Performance E-Commerce Trade Access Platform Based on J2EE Distributed Architecture

ZHANG Wei

(China Mobile (Shenzhen) Co., Ltd., Shenzhen 518048, China)

[Abstract] According to the requirements of e-commerce trade access platform and the high performance and high reliability characteristics of this platform, the solution for system implementation is proposed using J2EE distributed technology. The architecture for e-commerce trade access platform is designed and the key technical points are analyzed and discussed. Finally the performance stress tests of this system are carried out to ensure the operation of the system is stable and safe.

[Key words]J2EEdistributede-commerceaccess platformhigh performance high reliability

1 引言

隨著我國互聯(lián)網(wǎng)的日益普及，通過網(wǎng)絡(luò)進(jìn)行購物、交易和支付等的電子商務(wù)模式發(fā)展迅速。電子商務(wù)憑借其低成本、高效率的優(yōu)勢，對(duì)傳統(tǒng)的實(shí)體經(jīng)營模式與渠道造成巨大沖擊，已成為我國轉(zhuǎn)變發(fā)展方式、優(yōu)化產(chǎn)業(yè)結(jié)構(gòu)的重要?jiǎng)恿?。在電子商?wù)高速發(fā)展的時(shí)機(jī)下，國內(nèi)外誕生了一批優(yōu)秀的電子商務(wù)公司，如eBay、Amazon、淘寶、京東等。同時(shí)，隨著國內(nèi)移動(dòng)通信領(lǐng)域“三足鼎立”的局面形成，移動(dòng)通信業(yè)務(wù)的競爭也日趨激烈，為了更好地服務(wù)用戶，提升服務(wù)質(zhì)量，移動(dòng)運(yùn)營商不斷拓展新的消費(fèi)模式與經(jīng)營渠道，除了借助自身的網(wǎng)上營業(yè)廳作為電子渠道外，還與電商合作，在電商增開旗艦店也是一種有效補(bǔ)充，且市場前景廣闊。

電商旗艦店將主營充值、卡號(hào)、終端和合約四大類產(chǎn)品。用戶在電商旗艦店完成產(chǎn)品選購、支付后，電商平臺(tái)負(fù)責(zé)將生成的訂單提交到運(yùn)營商側(cè)，而運(yùn)營商側(cè)原有的CRM（Customer Relation Management，客戶關(guān)系管理系統(tǒng)）無法直接處理電商平臺(tái)的訂單，同時(shí)運(yùn)營商支撐系統(tǒng)是以省為單位進(jìn)行建設(shè)，存在電商對(duì)省公司CRM一對(duì)多的問題，此時(shí)即需要設(shè)計(jì)電商交易接入平臺(tái)，包含對(duì)訂單進(jìn)行接收轉(zhuǎn)換、訂單處理和路由轉(zhuǎn)發(fā)等功能。接入平臺(tái)需要與電商以及省CRM系統(tǒng)交互。電商側(cè)接口即電商與接入平臺(tái)接口，通常包含充值接口、查詢接口和對(duì)賬接口。其中，充值、查詢接口為實(shí)時(shí)接口，采用HTTP（Hypertext Transfer Protocol，超文本傳輸協(xié)議）協(xié)議承載xml（可擴(kuò)展標(biāo)記語言）報(bào)文的方式進(jìn)行；對(duì)賬接口每天進(jìn)行一次，采用FTP（File Transfer Protocol，文件傳輸協(xié)議）文本文件的方式進(jìn)行。省側(cè)接口即接入平臺(tái)與省CRM間接口，是基于運(yùn)營商內(nèi)部網(wǎng)狀網(wǎng)接口協(xié)議實(shí)現(xiàn)，其適時(shí)接口采用HTTP承載xml報(bào)文，文件接口采用FTP文本文件格式。電商側(cè)接口與省側(cè)接口所采用協(xié)議類似，但具體報(bào)文字段格式不同。對(duì)于適時(shí)接口，根據(jù)系統(tǒng)業(yè)務(wù)量評(píng)估，系統(tǒng)需支持的吞吐量為300TPS，即每秒可處理300條請(qǐng)求，平均事務(wù)響應(yīng)時(shí)間為10秒，最長事務(wù)響應(yīng)時(shí)間為60秒。

本文將對(duì)電商交易接入平臺(tái)進(jìn)行研究分析，并介紹相關(guān)架構(gòu)設(shè)計(jì)與關(guān)鍵技術(shù)設(shè)計(jì)。

2 電商交易接入平臺(tái)架構(gòu)

2.1應(yīng)用架構(gòu)

結(jié)合系統(tǒng)定位以及業(yè)務(wù)功能與非功能性需求特點(diǎn)進(jìn)行總體架構(gòu)設(shè)計(jì)，劃分出整個(gè)平臺(tái)的邏輯應(yīng)用架構(gòu)，如圖1所示：

圖1電商交易接入平臺(tái)應(yīng)用架構(gòu)圖

將電商交易接入平臺(tái)劃分為以下六個(gè)子系統(tǒng)：

（1）電商前置子系統(tǒng)：負(fù)責(zé)與電商平臺(tái)進(jìn)行通信交互，接收與處理電商前置的充值、查詢等請(qǐng)求，實(shí)現(xiàn)協(xié)議轉(zhuǎn)換、驗(yàn)簽、加解密等功能，并負(fù)責(zé)將處理結(jié)果返回給電商平臺(tái)。

（2）省前置子系統(tǒng)：負(fù)責(zé)與省中心BOSS（Business Operations Support System，業(yè)務(wù)運(yùn)營支撐系統(tǒng)）系統(tǒng)進(jìn)行通信交互，接收核心的處理請(qǐng)求，并把交易請(qǐng)求消息通過網(wǎng)狀網(wǎng)節(jié)點(diǎn)發(fā)送給省中心BOSS系統(tǒng)。

（3）文件前置子系統(tǒng)：負(fù)責(zé)接收與電商平臺(tái)以及省中心BOSS的對(duì)賬文件，并轉(zhuǎn)發(fā)給清結(jié)算子系統(tǒng)處理，文件前置子系統(tǒng)主要通過系統(tǒng)的定時(shí)任務(wù)獲取或上傳與外部交互的文件。

（4）加解密子系統(tǒng)：實(shí)現(xiàn)報(bào)文的驗(yàn)簽與加解密算法，并對(duì)前置子系統(tǒng)提供驗(yàn)簽與加解密訪問服務(wù)。

（5）核心交易子系統(tǒng)：主要負(fù)責(zé)整個(gè)平臺(tái)的數(shù)據(jù)校驗(yàn)、業(yè)務(wù)處理、交易查重、交易入庫等功能，與數(shù)據(jù)庫大量交互，是本平臺(tái)建設(shè)的關(guān)鍵子系統(tǒng)。

（6）清結(jié)算子系統(tǒng)：主要通過定時(shí)任務(wù)的調(diào)度對(duì)電商側(cè)以及省側(cè)的交易記錄進(jìn)行對(duì)賬，完成批量文件的處理，清結(jié)算子系統(tǒng)與文件前置間通過FTP文件的方式進(jìn)行交互。

2.2技術(shù)架構(gòu)

電商交易接入平臺(tái)技術(shù)架構(gòu)如圖2所示：

圖2電商交易接入平臺(tái)技術(shù)架構(gòu)圖

電商交易接入平臺(tái)采用J2EE（Java 2 Enterprise Edition，Java 2企業(yè)版）架構(gòu)進(jìn)行設(shè)計(jì)，技術(shù)架構(gòu)邏輯上可劃分為：

（1）業(yè)務(wù)接入層：負(fù)責(zé)外層通信交互，采用Apache作為HTTP服務(wù)器，Tomcat作為應(yīng)用服務(wù)器。

（2）數(shù)據(jù)交換層：負(fù)責(zé)接入層與處理層的數(shù)據(jù)交互，采用ActiveMQ作為JMS（Java Message Service，Java消息服務(wù)）消息中間件。

（3）業(yè)務(wù)處理層：負(fù)責(zé)關(guān)鍵的業(yè)務(wù)邏輯處理，采用Tomcat作為應(yīng)用服務(wù)器，部署J2EE應(yīng)用，業(yè)務(wù)邏輯采用Spring容器進(jìn)行管理，數(shù)據(jù)庫訪問操作基于iBatis ORM（Object Relation Mapping，對(duì)象關(guān)系映射）框架，底層采用c3p0連接池。

（4）數(shù)據(jù)服務(wù)層：負(fù)責(zé)數(shù)據(jù)的存儲(chǔ)，提供關(guān)系型數(shù)據(jù)的訪問服務(wù)，采用Oracle數(shù)據(jù)庫。

其中，業(yè)務(wù)接入層與業(yè)務(wù)處理層采用JMS消息中間件通信，即可實(shí)現(xiàn)交易的異步處理與分布式部署，在高并發(fā)與高性能環(huán)境中具備良好的擴(kuò)展性。

endprint

2.3部署架構(gòu)

電商交易接入平臺(tái)部署架構(gòu)如圖3所示。

總體劃分為接口域和核心域兩個(gè)域。接口域部署三個(gè)前置子系統(tǒng)，負(fù)責(zé)與外部接口交互，位于防火墻外；核心域部署消息中間件、核心應(yīng)用、清結(jié)算應(yīng)用、加解密應(yīng)用以及數(shù)據(jù)庫，是整個(gè)平臺(tái)的處理中心，位于防火墻內(nèi)，安全級(jí)別較高。

除核心應(yīng)用以及數(shù)據(jù)庫為AIX小型機(jī)外，其他均為X86服務(wù)器，部署Linux操作系統(tǒng)。部署方案中大量采用集群以提升總體性能，同時(shí)借助于HA（High Availability，高可靠性）技術(shù)保證平臺(tái)的高可靠性，無單點(diǎn)故障。

3 電商交易接入平臺(tái)關(guān)鍵技術(shù)

3.1高性能集群設(shè)計(jì)

為了滿足高性能與高并發(fā)需求，同時(shí)應(yīng)對(duì)互聯(lián)網(wǎng)上的突發(fā)用戶量，如“雙11”促銷、節(jié)假日促銷等，電商交易接入平臺(tái)需要具備良好的分布式集群能力，在性能不足的情況下能通過增加節(jié)點(diǎn)、橫向擴(kuò)展來擴(kuò)充處理能力。為此，電商交易接入平臺(tái)在各個(gè)層次設(shè)計(jì)了集群方案，具體如下：

（1）電商前置負(fù)載均衡

電商前置基于經(jīng)典的Apache+Tomcat集群部署方案，交易請(qǐng)求以HTTP協(xié)議接入，Apache負(fù)責(zé)在多個(gè)電商前置應(yīng)用節(jié)點(diǎn)上進(jìn)行負(fù)載均衡，隨著請(qǐng)求量增大，為了滿足高并發(fā)與高性能需求，可以及時(shí)增加電商前置處理節(jié)點(diǎn)。高峰時(shí)段后如果請(qǐng)求量下降，可以減少電商前置處理節(jié)點(diǎn)，合理利用機(jī)器資源。

（2）ActiveMQ隊(duì)列集群

ActiveMQ支持Network of Brokers特性，此特性可實(shí)現(xiàn)多節(jié)點(diǎn)集群。Network of Brokers可以在多個(gè)Broker之間存儲(chǔ)轉(zhuǎn)發(fā)消息或者說進(jìn)行消息路由，并支持靜態(tài)、動(dòng)態(tài)發(fā)現(xiàn)兩種配置方式，從而實(shí)現(xiàn)一組ActiveMQ Broker節(jié)點(diǎn)組成集群，以提升單個(gè)Broker的處理性能。同時(shí)，ActiveMQ支持HA部署，即Master Slave部署模式，其中Master Broker消息會(huì)被復(fù)制到Slave Broker，因此即使Master Broker遇到了像硬件故障之類的錯(cuò)誤，也可以立即切換到Slave Broker而不丟失任何消息。建議可以將Network of Brokers與Maser Slave兩種部署模式結(jié)合，同時(shí)保證高性能與高可靠性，具體如圖4所示：

圖4ActiveMQ集群原理圖

（3）核心處理集群

核心應(yīng)用作為war包在Tomcat中進(jìn)行部署。核心應(yīng)用與外界交互一側(cè)為電商前置隊(duì)列，另一側(cè)為省前置隊(duì)列，均為異步消息的松耦合方式，可以方便地通過增加節(jié)點(diǎn)的方式擴(kuò)展處理能力。異步入庫目前作為核心的一部分，在集群節(jié)點(diǎn)中設(shè)立單獨(dú)的開關(guān)，集群節(jié)點(diǎn)可以根據(jù)需要考慮是否打開異步入庫服務(wù)，如果異步入庫壓力不大，建議只采用一個(gè)節(jié)點(diǎn)進(jìn)行異步入庫，以免對(duì)數(shù)據(jù)庫造成過大壓力，影響適時(shí)交易處理性能。

（4）省前置處理集群

省前置通過隊(duì)列與核心子系統(tǒng)進(jìn)行交互，JMS消息為異步松耦合訪問，可通過擴(kuò)展節(jié)點(diǎn)增加消息處理能力；同時(shí)，省前置與省CRM通過HTTP方式訪問，此時(shí)省前置是HTTP Client，可方便地支持多節(jié)點(diǎn)集群部署。因此，省前置也可根據(jù)需要進(jìn)行多節(jié)點(diǎn)集群。

（5）數(shù)據(jù)庫集群

基于Oracle RAC（Real Application Clusters，實(shí)時(shí)應(yīng)用集群）技術(shù)構(gòu)建高可用數(shù)據(jù)庫集群，當(dāng)應(yīng)用規(guī)模需要擴(kuò)充時(shí)，可以按需擴(kuò)展數(shù)據(jù)庫服務(wù)節(jié)點(diǎn)，以保證系統(tǒng)的性能。Oracle RAC具有如下特點(diǎn)：

◆支持多節(jié)點(diǎn)負(fù)載均衡；

◆高可用性：故障容錯(cuò)和無縫切換功能，將硬件和軟件錯(cuò)誤造成的影響最小化；

◆通過并行執(zhí)行技術(shù)提高事務(wù)響應(yīng)時(shí)間；

◆通過橫向擴(kuò)展提高每秒交易數(shù)和連接數(shù)；

◆良好可擴(kuò)展性：可以方便添加/刪除節(jié)點(diǎn)，擴(kuò)展硬件資源。

3.2高可靠性設(shè)計(jì)

電商交易接入平臺(tái)提供了完整的高可靠性方案，在部署方案中不會(huì)出現(xiàn)因單點(diǎn)故障而造成的服務(wù)中斷，具備非常高的可靠性，具體設(shè)計(jì)方案如下：

（1）電商前置基于Apache集群，電商前置應(yīng)用節(jié)點(diǎn)已無單點(diǎn)故障問題，其中Apache服務(wù)器采用基于Linux系統(tǒng)的HA方案，實(shí)現(xiàn)Primary-Standby模式的高可靠性。

（2）ActiveMQ采用Network of Brokers集群與Master-Slave主備結(jié)合的部署方案，其中Master-Slave基于共享文件的方案，集群中Master節(jié)點(diǎn)故障可以無縫切換到Slave節(jié)點(diǎn)，沒有單點(diǎn)故障。

（3）清結(jié)算子系統(tǒng)采用基于Linux系統(tǒng)的HA方案，實(shí)現(xiàn)Primary-Standby模式的高可靠性，支持主備故障切換，沒有單點(diǎn)故障。

（4）核心子系統(tǒng)、省前置子系統(tǒng)都是基于隊(duì)列消息訪問的集群部署方式，集群中某一節(jié)點(diǎn)故障就將不再處理消息，消息會(huì)自動(dòng)由其他節(jié)點(diǎn)進(jìn)行處理，無單點(diǎn)故障問題。

（5）數(shù)據(jù)庫基于Oracle RAC機(jī)制，支持故障容錯(cuò)和無縫切換，具備非常高的可靠性。

3.3JMS隊(duì)列處理機(jī)制

電商前置、省前置與核心系統(tǒng)之間通過隊(duì)列通信，總共設(shè)計(jì)了8條隊(duì)列，所有請(qǐng)求隊(duì)列和響應(yīng)隊(duì)列分開。Producer即消息發(fā)送方，Consumer即消息接收處理方，隊(duì)列發(fā)送者采用多線程方式以線程為單位建立發(fā)送連接，隊(duì)列接收者則需要接收消息并進(jìn)行業(yè)務(wù)邏輯處理，為了提升并發(fā)效率，接收消息后采用線程池進(jìn)行業(yè)務(wù)邏輯處理，一般情況下業(yè)務(wù)處理時(shí)間相對(duì)較長、接收消息時(shí)間很短，因此需要將消息接收連接數(shù)設(shè)置一個(gè)很小的值，如1或者2，而處理線程池可根據(jù)系統(tǒng)硬件情況設(shè)置一個(gè)較大的值，如50到100。

經(jīng)過實(shí)際測試驗(yàn)證，即便是這樣配置，消息接收仍然很快，大約20毫秒/條，但消息處理相對(duì)較慢，大約800毫秒/條，會(huì)導(dǎo)致消息在很短時(shí)間都被從隊(duì)列中取走，但是大量消息積壓等待線程池處理，實(shí)際應(yīng)用過程中如果消息量非常大，可能會(huì)導(dǎo)致JVM（Java Virtual Machine，Java虛擬機(jī)）堆內(nèi)存不夠用，引發(fā)Out of Memory異常；同時(shí)，大量消息從隊(duì)列獲取到內(nèi)存，可靠性也得不到保障，一旦應(yīng)用出現(xiàn)故障，較多數(shù)據(jù)會(huì)丟失?；诖朔N情況，需要在消息接收時(shí)進(jìn)行流量控制，保證消息接收的量不要太大，在保證可靠性的同時(shí)盡量少的影響處理性能。

消息接收與處理流量控制方法原理為：在消息消費(fèi)者處理中增加計(jì)數(shù)器，對(duì)當(dāng)前待處理消息進(jìn)行計(jì)數(shù)，計(jì)數(shù)器閾值可設(shè)置，每取一個(gè)消息則計(jì)數(shù)器加一，線程池中線程每處理完一個(gè)消息則計(jì)數(shù)器減一，一旦計(jì)數(shù)器超過閾值就不再讀取消息，讀取線程休眠一個(gè)時(shí)間周期，當(dāng)下一個(gè)時(shí)間周期到來時(shí)再對(duì)計(jì)數(shù)器進(jìn)行檢查。為了保證高并發(fā)情況下，線程池中線程都不會(huì)因此空閑而沒有消息處理，需要設(shè)置計(jì)數(shù)器閾值大于線程池線程數(shù)，建議計(jì)數(shù)器閾值為線程數(shù)的120%；同時(shí)，在系統(tǒng)性能優(yōu)先的處理場景中，讀取線程休眠時(shí)間不宜過長，建議為5～10毫秒。

3.4異步批量入庫

電商接入平臺(tái)處理模式為：接收電商交易請(qǐng)求→完成處理與入庫→路由轉(zhuǎn)發(fā)請(qǐng)求到省CRM→由省CRM處理完再返回。由于處理路徑較長，為了降低總體流程處理時(shí)間，提升主流程處理性能，可將電商接入平臺(tái)核心處理中比較費(fèi)時(shí)的入庫操作剝離核心流程，采用異步入庫方式實(shí)現(xiàn)，其設(shè)計(jì)原理為：核心子系統(tǒng)主處理流程中將需要入庫數(shù)據(jù)封裝為JMS消息放入異步入庫隊(duì)列，異步入庫處理線程負(fù)責(zé)接收待入庫消息數(shù)據(jù)，并完成入庫動(dòng)作，每條消息中封裝單條數(shù)據(jù)。為了提升入庫效率，減少訪問數(shù)據(jù)庫次數(shù)，異步入庫采用批量入庫而不是每條數(shù)據(jù)入一次庫。批量入庫采用時(shí)間觸發(fā)器與計(jì)數(shù)觸發(fā)器兩種控制方式，當(dāng)其中任意一個(gè)觸發(fā)器滿足條件時(shí)均可執(zhí)行批量入庫。如時(shí)間觸發(fā)配置500毫秒，即每500毫秒執(zhí)行一次入庫；計(jì)數(shù)觸發(fā)配置5 000，即每5 000條數(shù)據(jù)入庫一次。這兩個(gè)條件中任意一個(gè)滿足即執(zhí)行，既保證了低并發(fā)情況下數(shù)據(jù)獲得及時(shí)入庫，又可以保證高并發(fā)情況下不會(huì)過多數(shù)據(jù)積壓。

endprint

4 性能測試與調(diào)優(yōu)

電商交易接入平臺(tái)性能需求：吞吐量為300TPS，平均事務(wù)響應(yīng)時(shí)間為10秒，最長事務(wù)響應(yīng)時(shí)間為60秒。需要對(duì)系統(tǒng)進(jìn)行性能測試與調(diào)優(yōu)，以達(dá)到性能要求。

4.1性能測試場景與案例

為了充分測試出系統(tǒng)性能，結(jié)合實(shí)際應(yīng)用情況對(duì)測試場景與案例進(jìn)行了設(shè)計(jì)，具體內(nèi)容如下：

（1）場景一：省端0秒延遲

案例1：輕負(fù)荷，5個(gè)Vuser（Virtual user，虛擬用戶）同時(shí)并發(fā)發(fā)送消息，每個(gè)Vuser迭代發(fā)送2 000次消息；

案例2：重負(fù)荷，100個(gè)Vuser同時(shí)并發(fā)發(fā)送消息，每個(gè)Vuser迭代發(fā)送1 000次消息；

案例3：過負(fù)荷，500個(gè)Vuser同時(shí)并發(fā)發(fā)送消息，每個(gè)Vuser迭代發(fā)送200次消息。

（2）場景二：省端2秒延遲

案例1：輕負(fù)荷，5個(gè)Vuser同時(shí)并發(fā)發(fā)送消息，每個(gè)Vuser迭代發(fā)送2 000次消息；

案例2：重負(fù)荷，100個(gè)Vuser同時(shí)并發(fā)發(fā)送消息，每個(gè)Vuser迭代發(fā)送1 000次消息；

案例3：過負(fù)荷，500個(gè)Vuser同時(shí)并發(fā)發(fā)送消息，每個(gè)Vuser迭代發(fā)送200次消息。

由于省前置調(diào)用省CRM采用HTTP同步方式，因此省CRM的處理效率對(duì)整個(gè)接入平臺(tái)的性能有非常大的影響。此次筆者主要設(shè)計(jì)了兩個(gè)典型的測試場景，即省CRM不延遲和延遲2秒的情況，以觀察此項(xiàng)指標(biāo)對(duì)性能的影響。這次測試采用LoadRunner進(jìn)行模擬壓力測試，每個(gè)場景設(shè)計(jì)了三個(gè)測試案例，分別為5Vuser、100Vuser、500Vuser，代表輕負(fù)荷、重負(fù)荷、過負(fù)荷的不同情形，以獲得在不同壓力情況下的系統(tǒng)性能數(shù)據(jù)。

4.2性能測試調(diào)優(yōu)

測試初期系統(tǒng)所有配置均采用默認(rèn)配置，執(zhí)行性能測試案例時(shí)，結(jié)果非常不理想，如省端0秒延遲場景的吞吐量僅有50TPS，響應(yīng)時(shí)間都為6~7秒。經(jīng)過不斷調(diào)整配置與代碼，性能取得了較大幅度提升，此處對(duì)性能調(diào)優(yōu)過程中比較有代表性的經(jīng)驗(yàn)總結(jié)如下：

（1）主機(jī)系統(tǒng)調(diào)優(yōu)

主要對(duì)系統(tǒng)同時(shí)打開文件句柄數(shù)進(jìn)行調(diào)整，設(shè)置為65535，避免系統(tǒng)出現(xiàn)打開過多連接的異常。

（2）JVM調(diào)優(yōu)

對(duì)各個(gè)子系統(tǒng)的JVM參數(shù)進(jìn)行了調(diào)整，主要涉及到堆大小以及GC（Garbage Collection，垃圾回收）參數(shù)調(diào)整。電商前置、省前置堆大小設(shè)置為1G，核心子系統(tǒng)堆大小設(shè)置為3G，持久代大小統(tǒng)一設(shè)置64M即足夠。GC采用吞吐量優(yōu)先的并行收集器，即-XX:+UseParallelGC。

（3）Tomcat調(diào)優(yōu)

為了提升Tomcat處理效率，建議采用異步IO模式，需要修改HTTP協(xié)議為異步IO協(xié)議，即設(shè)置Connector的Protocol屬性為"org.apache.coyote.http11.Http11NioProtocol"。

對(duì)Tomcat線程池的設(shè)置也是性能調(diào)優(yōu)的關(guān)鍵所在，線程太少則無法充分利用系統(tǒng)處理資源，線程太多也會(huì)增加系統(tǒng)調(diào)度的負(fù)擔(dān)，所以需要合理設(shè)置線程池大小。在省端0秒延遲的場景中，電商前置設(shè)置Tomcat線程最大值為100，核心為100，省前置為70，即可獲得最優(yōu)的系統(tǒng)吞吐量350TPS，各臺(tái)主機(jī)系統(tǒng)CPU消耗也能達(dá)到85%以上，增加或減少線程配置都會(huì)降低系統(tǒng)吞吐量。

（4）ActiveMQ調(diào)優(yōu)

ActiveMQ自身JVM啟動(dòng)參數(shù)也要進(jìn)行調(diào)整，需設(shè)置堆內(nèi)存為合適大小，測試環(huán)境中設(shè)置堆大小為2G。ActiveMQ的持久化模式對(duì)其自身性能影響較大，經(jīng)過測試采用Kaha Persistence存儲(chǔ)方式會(huì)有較好的處理性能。Broker的目標(biāo)策略中設(shè)置隊(duì)列的memoryLimit需要足夠大，systemUsage節(jié)點(diǎn)中對(duì)內(nèi)存空間、存儲(chǔ)空間、臨時(shí)空間的設(shè)置也要足夠，否則可能會(huì)出現(xiàn)空間不足的問題。

（5）連接池

核心子系統(tǒng)所使用的連接池為c3p0，其默認(rèn)連接數(shù)非常少，需要調(diào)整，測試過程中筆者設(shè)置連接池最大值為100。同時(shí)，對(duì)于c3p0中的兩個(gè)參數(shù)testConnectionOnCheckout和testConnectionOnCheckin都需要設(shè)置為false，否則連接池性能非常低。

4.3性能測試結(jié)果與分析

在性能調(diào)優(yōu)之后的環(huán)境中進(jìn)行了性能測試，本次性能測試采用LoadRunner進(jìn)行壓力測試，每個(gè)場景與案例的測試步驟如下：

（1）清理數(shù)據(jù)庫與系統(tǒng)日志；

（2）檢查與啟動(dòng)電商交易接入平臺(tái)各個(gè)子系統(tǒng)；

（3）設(shè)置與啟動(dòng)LoadRunner；

（4）執(zhí)行性能壓力測試；

（5）觀察與記錄壓測過程數(shù)據(jù)；

（6）分析測試數(shù)據(jù)。

通過性能測試案例的執(zhí)行，并對(duì)性能測試數(shù)據(jù)進(jìn)行分析，獲得測試結(jié)果指標(biāo)數(shù)據(jù)如表1和表2所示：

表1性能測試結(jié)果吞吐量場景 案例 平均TPS 最大TPS

省端0秒延遲 輕負(fù)荷 128 293

重負(fù)荷 352 560

過負(fù)荷 271 589

省端2秒延遲 輕負(fù)荷 128 335

重負(fù)荷 265 593

過負(fù)荷 204 441

表2性能測試結(jié)果響應(yīng)時(shí)間

場景 案例 平均響應(yīng)時(shí)間/秒 最大響應(yīng)時(shí)間/秒 最小響應(yīng)時(shí)間/秒

省端0秒延遲 輕負(fù)荷 1.359 2.382 0.056

重負(fù)荷 2.992 4.678 0.138

過負(fù)荷 6.359 8.376 0.126

省端2秒延遲 輕負(fù)荷 4.557 19.812 2.053

重負(fù)荷 7.012 25.377 2.092

過負(fù)荷 13.112 40.801 2.106

綜合分析性能測試情況與測試數(shù)據(jù)，可以得出如下結(jié)論：

（1）系統(tǒng)無延遲吞吐量可達(dá)350TPS，延遲2秒情況下可達(dá)260TPS，實(shí)際生產(chǎn)環(huán)境都是集群，硬件處理能力會(huì)提升一倍，同時(shí)由于網(wǎng)絡(luò)和系統(tǒng)處理等因素會(huì)造成省端處理延遲，采用延遲2秒260TPS作為參考，集群環(huán)境下應(yīng)該能滿足300TPS的需求。

（2）目前測試的最優(yōu)TPS為重負(fù)荷壓力下產(chǎn)生，并發(fā)用戶數(shù)為100Vuser，隨著并發(fā)用戶量的增大，系統(tǒng)進(jìn)入過負(fù)荷，TPS值會(huì)有一定幅度的下降。

（3）系統(tǒng)無延遲的響應(yīng)時(shí)間為2.9秒，延遲2秒情況下的響應(yīng)時(shí)間為7秒，能滿足平均響應(yīng)時(shí)間為10秒的要求。其中，延遲和不延遲的最長響應(yīng)時(shí)間也都在60秒以內(nèi)，可滿足系統(tǒng)需求。

（4）隨著系統(tǒng)并發(fā)壓力的增加，響應(yīng)時(shí)間明顯增加，特別是在2秒延遲情況下，過負(fù)荷比重負(fù)荷的平均響應(yīng)時(shí)間增加了約6秒，系統(tǒng)出現(xiàn)大量請(qǐng)求積壓，測試過程中觀察隊(duì)列也會(huì)出現(xiàn)明顯積壓。

（5）由于受限于測試環(huán)境，實(shí)際生產(chǎn)中的集群方式?jīng)]有進(jìn)行測試，因此實(shí)際生產(chǎn)中能達(dá)到的性能值有待最終驗(yàn)證。

5 結(jié)束語

本文介紹了電商交易接入平臺(tái)的建設(shè)背景與需求，并對(duì)其架構(gòu)和技術(shù)進(jìn)行了研究與設(shè)計(jì)，在設(shè)計(jì)中筆者除了考慮電商接入平臺(tái)的業(yè)務(wù)功能外，還重點(diǎn)針對(duì)高性能、高可靠性等非功能需求進(jìn)行了研究設(shè)計(jì)。基于這些需求，引入了一套基于J2EE的分布式架構(gòu)并進(jìn)行系統(tǒng)設(shè)計(jì)。由于篇幅有限，本文僅對(duì)關(guān)鍵技術(shù)進(jìn)行了描述，實(shí)施層面的一些技術(shù)細(xì)節(jié)并沒有詳細(xì)說明。

對(duì)于一個(gè)新建的系統(tǒng)，除了良好的架構(gòu)設(shè)計(jì)外，不斷進(jìn)行系統(tǒng)優(yōu)化也非常重要。在系統(tǒng)運(yùn)行與維護(hù)過程中會(huì)逐漸發(fā)現(xiàn)一些亟待優(yōu)化和改善的地方，例如：系統(tǒng)橫向擴(kuò)展能力存在不足，主要表現(xiàn)為Oracle數(shù)據(jù)庫以及ActiveMQ的擴(kuò)展能力上；系統(tǒng)對(duì)于消息處理異常、重發(fā)等機(jī)制上的考慮不足，一些異常情況需要運(yùn)維人員手工處理；系統(tǒng)處理流程較長，某一環(huán)節(jié)的升級(jí)、宕機(jī)等應(yīng)急機(jī)制考慮不足。諸如此類問題，可在以后的系統(tǒng)維護(hù)和建設(shè)中逐步考慮與優(yōu)化。

參考文獻(xiàn)：

[1] Len Bass, Paul Clements, Rick Kazman. 軟件架構(gòu)實(shí)踐[M]. 孫學(xué)濤,等譯. 北京: 清華大學(xué)出版社, 2002.

[2] 楊傳明. 基于開源J2EE框架的電子商務(wù)實(shí)驗(yàn)平臺(tái)研究[J]. 計(jì)算機(jī)應(yīng)用與軟件, 2009(10): 69-71.

[3] 妙旭華,包理群,李穎. 基于J2EE多層架構(gòu)的重金屬污染監(jiān)管設(shè)計(jì)[J]. 計(jì)算機(jī)應(yīng)用與軟件, 2013(4): 128-130.

[4] 藍(lán)雯飛,陸際光. 基于J2EE技術(shù)的網(wǎng)上外卡交易系統(tǒng)設(shè)計(jì)[J]. 計(jì)算機(jī)應(yīng)用與軟件, 2007(12): 212-214.

[5] 溫昱. 軟件架構(gòu)設(shè)計(jì)[M]. 2版. 北京: 電子工業(yè)出版社, 2012.

[6] 段念. 軟件性能測試過程詳解與案例剖析[M]. 2版. 北京: 清華大學(xué)出版社, 2012.

[7] 林昊. 分布式Java應(yīng)用：基礎(chǔ)與實(shí)踐[M]. 北京: 電子工業(yè)出版社, 2010.★

作者簡介

張煒：高級(jí)工程師，學(xué)士，現(xiàn)任職于中國移動(dòng)（深圳）有限公司系統(tǒng)管理部，主要研究方向?yàn)镴2EE架構(gòu)、分布式架構(gòu)和大數(shù)據(jù)技術(shù)。

endprint

4 性能測試與調(diào)優(yōu)

電商交易接入平臺(tái)性能需求：吞吐量為300TPS，平均事務(wù)響應(yīng)時(shí)間為10秒，最長事務(wù)響應(yīng)時(shí)間為60秒。需要對(duì)系統(tǒng)進(jìn)行性能測試與調(diào)優(yōu)，以達(dá)到性能要求。

4.1性能測試場景與案例

為了充分測試出系統(tǒng)性能，結(jié)合實(shí)際應(yīng)用情況對(duì)測試場景與案例進(jìn)行了設(shè)計(jì)，具體內(nèi)容如下：

（1）場景一：省端0秒延遲

案例1：輕負(fù)荷，5個(gè)Vuser（Virtual user，虛擬用戶）同時(shí)并發(fā)發(fā)送消息，每個(gè)Vuser迭代發(fā)送2 000次消息；

案例2：重負(fù)荷，100個(gè)Vuser同時(shí)并發(fā)發(fā)送消息，每個(gè)Vuser迭代發(fā)送1 000次消息；

案例3：過負(fù)荷，500個(gè)Vuser同時(shí)并發(fā)發(fā)送消息，每個(gè)Vuser迭代發(fā)送200次消息。

（2）場景二：省端2秒延遲

案例1：輕負(fù)荷，5個(gè)Vuser同時(shí)并發(fā)發(fā)送消息，每個(gè)Vuser迭代發(fā)送2 000次消息；

案例2：重負(fù)荷，100個(gè)Vuser同時(shí)并發(fā)發(fā)送消息，每個(gè)Vuser迭代發(fā)送1 000次消息；

案例3：過負(fù)荷，500個(gè)Vuser同時(shí)并發(fā)發(fā)送消息，每個(gè)Vuser迭代發(fā)送200次消息。

由于省前置調(diào)用省CRM采用HTTP同步方式，因此省CRM的處理效率對(duì)整個(gè)接入平臺(tái)的性能有非常大的影響。此次筆者主要設(shè)計(jì)了兩個(gè)典型的測試場景，即省CRM不延遲和延遲2秒的情況，以觀察此項(xiàng)指標(biāo)對(duì)性能的影響。這次測試采用LoadRunner進(jìn)行模擬壓力測試，每個(gè)場景設(shè)計(jì)了三個(gè)測試案例，分別為5Vuser、100Vuser、500Vuser，代表輕負(fù)荷、重負(fù)荷、過負(fù)荷的不同情形，以獲得在不同壓力情況下的系統(tǒng)性能數(shù)據(jù)。

4.2性能測試調(diào)優(yōu)

測試初期系統(tǒng)所有配置均采用默認(rèn)配置，執(zhí)行性能測試案例時(shí)，結(jié)果非常不理想，如省端0秒延遲場景的吞吐量僅有50TPS，響應(yīng)時(shí)間都為6~7秒。經(jīng)過不斷調(diào)整配置與代碼，性能取得了較大幅度提升，此處對(duì)性能調(diào)優(yōu)過程中比較有代表性的經(jīng)驗(yàn)總結(jié)如下：

（1）主機(jī)系統(tǒng)調(diào)優(yōu)

主要對(duì)系統(tǒng)同時(shí)打開文件句柄數(shù)進(jìn)行調(diào)整，設(shè)置為65535，避免系統(tǒng)出現(xiàn)打開過多連接的異常。

（2）JVM調(diào)優(yōu)

對(duì)各個(gè)子系統(tǒng)的JVM參數(shù)進(jìn)行了調(diào)整，主要涉及到堆大小以及GC（Garbage Collection，垃圾回收）參數(shù)調(diào)整。電商前置、省前置堆大小設(shè)置為1G，核心子系統(tǒng)堆大小設(shè)置為3G，持久代大小統(tǒng)一設(shè)置64M即足夠。GC采用吞吐量優(yōu)先的并行收集器，即-XX:+UseParallelGC。

（3）Tomcat調(diào)優(yōu)

為了提升Tomcat處理效率，建議采用異步IO模式，需要修改HTTP協(xié)議為異步IO協(xié)議，即設(shè)置Connector的Protocol屬性為"org.apache.coyote.http11.Http11NioProtocol"。

對(duì)Tomcat線程池的設(shè)置也是性能調(diào)優(yōu)的關(guān)鍵所在，線程太少則無法充分利用系統(tǒng)處理資源，線程太多也會(huì)增加系統(tǒng)調(diào)度的負(fù)擔(dān)，所以需要合理設(shè)置線程池大小。在省端0秒延遲的場景中，電商前置設(shè)置Tomcat線程最大值為100，核心為100，省前置為70，即可獲得最優(yōu)的系統(tǒng)吞吐量350TPS，各臺(tái)主機(jī)系統(tǒng)CPU消耗也能達(dá)到85%以上，增加或減少線程配置都會(huì)降低系統(tǒng)吞吐量。

（4）ActiveMQ調(diào)優(yōu)

ActiveMQ自身JVM啟動(dòng)參數(shù)也要進(jìn)行調(diào)整，需設(shè)置堆內(nèi)存為合適大小，測試環(huán)境中設(shè)置堆大小為2G。ActiveMQ的持久化模式對(duì)其自身性能影響較大，經(jīng)過測試采用Kaha Persistence存儲(chǔ)方式會(huì)有較好的處理性能。Broker的目標(biāo)策略中設(shè)置隊(duì)列的memoryLimit需要足夠大，systemUsage節(jié)點(diǎn)中對(duì)內(nèi)存空間、存儲(chǔ)空間、臨時(shí)空間的設(shè)置也要足夠，否則可能會(huì)出現(xiàn)空間不足的問題。

（5）連接池

核心子系統(tǒng)所使用的連接池為c3p0，其默認(rèn)連接數(shù)非常少，需要調(diào)整，測試過程中筆者設(shè)置連接池最大值為100。同時(shí)，對(duì)于c3p0中的兩個(gè)參數(shù)testConnectionOnCheckout和testConnectionOnCheckin都需要設(shè)置為false，否則連接池性能非常低。

4.3性能測試結(jié)果與分析

在性能調(diào)優(yōu)之后的環(huán)境中進(jìn)行了性能測試，本次性能測試采用LoadRunner進(jìn)行壓力測試，每個(gè)場景與案例的測試步驟如下：

（1）清理數(shù)據(jù)庫與系統(tǒng)日志；

（2）檢查與啟動(dòng)電商交易接入平臺(tái)各個(gè)子系統(tǒng)；

（3）設(shè)置與啟動(dòng)LoadRunner；

（4）執(zhí)行性能壓力測試；

（5）觀察與記錄壓測過程數(shù)據(jù)；

（6）分析測試數(shù)據(jù)。

通過性能測試案例的執(zhí)行，并對(duì)性能測試數(shù)據(jù)進(jìn)行分析，獲得測試結(jié)果指標(biāo)數(shù)據(jù)如表1和表2所示：

表1性能測試結(jié)果吞吐量場景 案例 平均TPS 最大TPS

省端0秒延遲 輕負(fù)荷 128 293

重負(fù)荷 352 560

過負(fù)荷 271 589

省端2秒延遲 輕負(fù)荷 128 335

重負(fù)荷 265 593

過負(fù)荷 204 441

表2性能測試結(jié)果響應(yīng)時(shí)間

場景 案例 平均響應(yīng)時(shí)間/秒 最大響應(yīng)時(shí)間/秒 最小響應(yīng)時(shí)間/秒

省端0秒延遲 輕負(fù)荷 1.359 2.382 0.056

重負(fù)荷 2.992 4.678 0.138

過負(fù)荷 6.359 8.376 0.126

省端2秒延遲 輕負(fù)荷 4.557 19.812 2.053

重負(fù)荷 7.012 25.377 2.092

過負(fù)荷 13.112 40.801 2.106

綜合分析性能測試情況與測試數(shù)據(jù)，可以得出如下結(jié)論：

（1）系統(tǒng)無延遲吞吐量可達(dá)350TPS，延遲2秒情況下可達(dá)260TPS，實(shí)際生產(chǎn)環(huán)境都是集群，硬件處理能力會(huì)提升一倍，同時(shí)由于網(wǎng)絡(luò)和系統(tǒng)處理等因素會(huì)造成省端處理延遲，采用延遲2秒260TPS作為參考，集群環(huán)境下應(yīng)該能滿足300TPS的需求。

（2）目前測試的最優(yōu)TPS為重負(fù)荷壓力下產(chǎn)生，并發(fā)用戶數(shù)為100Vuser，隨著并發(fā)用戶量的增大，系統(tǒng)進(jìn)入過負(fù)荷，TPS值會(huì)有一定幅度的下降。

（3）系統(tǒng)無延遲的響應(yīng)時(shí)間為2.9秒，延遲2秒情況下的響應(yīng)時(shí)間為7秒，能滿足平均響應(yīng)時(shí)間為10秒的要求。其中，延遲和不延遲的最長響應(yīng)時(shí)間也都在60秒以內(nèi)，可滿足系統(tǒng)需求。

（4）隨著系統(tǒng)并發(fā)壓力的增加，響應(yīng)時(shí)間明顯增加，特別是在2秒延遲情況下，過負(fù)荷比重負(fù)荷的平均響應(yīng)時(shí)間增加了約6秒，系統(tǒng)出現(xiàn)大量請(qǐng)求積壓，測試過程中觀察隊(duì)列也會(huì)出現(xiàn)明顯積壓。

（5）由于受限于測試環(huán)境，實(shí)際生產(chǎn)中的集群方式?jīng)]有進(jìn)行測試，因此實(shí)際生產(chǎn)中能達(dá)到的性能值有待最終驗(yàn)證。

5 結(jié)束語

本文介紹了電商交易接入平臺(tái)的建設(shè)背景與需求，并對(duì)其架構(gòu)和技術(shù)進(jìn)行了研究與設(shè)計(jì)，在設(shè)計(jì)中筆者除了考慮電商接入平臺(tái)的業(yè)務(wù)功能外，還重點(diǎn)針對(duì)高性能、高可靠性等非功能需求進(jìn)行了研究設(shè)計(jì)?；谶@些需求，引入了一套基于J2EE的分布式架構(gòu)并進(jìn)行系統(tǒng)設(shè)計(jì)。由于篇幅有限，本文僅對(duì)關(guān)鍵技術(shù)進(jìn)行了描述，實(shí)施層面的一些技術(shù)細(xì)節(jié)并沒有詳細(xì)說明。

對(duì)于一個(gè)新建的系統(tǒng)，除了良好的架構(gòu)設(shè)計(jì)外，不斷進(jìn)行系統(tǒng)優(yōu)化也非常重要。在系統(tǒng)運(yùn)行與維護(hù)過程中會(huì)逐漸發(fā)現(xiàn)一些亟待優(yōu)化和改善的地方，例如：系統(tǒng)橫向擴(kuò)展能力存在不足，主要表現(xiàn)為Oracle數(shù)據(jù)庫以及ActiveMQ的擴(kuò)展能力上；系統(tǒng)對(duì)于消息處理異常、重發(fā)等機(jī)制上的考慮不足，一些異常情況需要運(yùn)維人員手工處理；系統(tǒng)處理流程較長，某一環(huán)節(jié)的升級(jí)、宕機(jī)等應(yīng)急機(jī)制考慮不足。諸如此類問題，可在以后的系統(tǒng)維護(hù)和建設(shè)中逐步考慮與優(yōu)化。

參考文獻(xiàn)：

[1] Len Bass, Paul Clements, Rick Kazman. 軟件架構(gòu)實(shí)踐[M]. 孫學(xué)濤,等譯. 北京: 清華大學(xué)出版社, 2002.

[2] 楊傳明. 基于開源J2EE框架的電子商務(wù)實(shí)驗(yàn)平臺(tái)研究[J]. 計(jì)算機(jī)應(yīng)用與軟件, 2009(10): 69-71.

[3] 妙旭華,包理群,李穎. 基于J2EE多層架構(gòu)的重金屬污染監(jiān)管設(shè)計(jì)[J]. 計(jì)算機(jī)應(yīng)用與軟件, 2013(4): 128-130.

[4] 藍(lán)雯飛,陸際光. 基于J2EE技術(shù)的網(wǎng)上外卡交易系統(tǒng)設(shè)計(jì)[J]. 計(jì)算機(jī)應(yīng)用與軟件, 2007(12): 212-214.

[5] 溫昱. 軟件架構(gòu)設(shè)計(jì)[M]. 2版. 北京: 電子工業(yè)出版社, 2012.

[6] 段念. 軟件性能測試過程詳解與案例剖析[M]. 2版. 北京: 清華大學(xué)出版社, 2012.

[7] 林昊. 分布式Java應(yīng)用：基礎(chǔ)與實(shí)踐[M]. 北京: 電子工業(yè)出版社, 2010.★

作者簡介

張煒：高級(jí)工程師，學(xué)士，現(xiàn)任職于中國移動(dòng)（深圳）有限公司系統(tǒng)管理部，主要研究方向?yàn)镴2EE架構(gòu)、分布式架構(gòu)和大數(shù)據(jù)技術(shù)。

endprint

4 性能測試與調(diào)優(yōu)

電商交易接入平臺(tái)性能需求：吞吐量為300TPS，平均事務(wù)響應(yīng)時(shí)間為10秒，最長事務(wù)響應(yīng)時(shí)間為60秒。需要對(duì)系統(tǒng)進(jìn)行性能測試與調(diào)優(yōu)，以達(dá)到性能要求。

4.1性能測試場景與案例

為了充分測試出系統(tǒng)性能，結(jié)合實(shí)際應(yīng)用情況對(duì)測試場景與案例進(jìn)行了設(shè)計(jì)，具體內(nèi)容如下：

（1）場景一：省端0秒延遲

案例1：輕負(fù)荷，5個(gè)Vuser（Virtual user，虛擬用戶）同時(shí)并發(fā)發(fā)送消息，每個(gè)Vuser迭代發(fā)送2 000次消息；

案例2：重負(fù)荷，100個(gè)Vuser同時(shí)并發(fā)發(fā)送消息，每個(gè)Vuser迭代發(fā)送1 000次消息；

案例3：過負(fù)荷，500個(gè)Vuser同時(shí)并發(fā)發(fā)送消息，每個(gè)Vuser迭代發(fā)送200次消息。

（2）場景二：省端2秒延遲

案例1：輕負(fù)荷，5個(gè)Vuser同時(shí)并發(fā)發(fā)送消息，每個(gè)Vuser迭代發(fā)送2 000次消息；

案例2：重負(fù)荷，100個(gè)Vuser同時(shí)并發(fā)發(fā)送消息，每個(gè)Vuser迭代發(fā)送1 000次消息；

案例3：過負(fù)荷，500個(gè)Vuser同時(shí)并發(fā)發(fā)送消息，每個(gè)Vuser迭代發(fā)送200次消息。

由于省前置調(diào)用省CRM采用HTTP同步方式，因此省CRM的處理效率對(duì)整個(gè)接入平臺(tái)的性能有非常大的影響。此次筆者主要設(shè)計(jì)了兩個(gè)典型的測試場景，即省CRM不延遲和延遲2秒的情況，以觀察此項(xiàng)指標(biāo)對(duì)性能的影響。這次測試采用LoadRunner進(jìn)行模擬壓力測試，每個(gè)場景設(shè)計(jì)了三個(gè)測試案例，分別為5Vuser、100Vuser、500Vuser，代表輕負(fù)荷、重負(fù)荷、過負(fù)荷的不同情形，以獲得在不同壓力情況下的系統(tǒng)性能數(shù)據(jù)。

4.2性能測試調(diào)優(yōu)

測試初期系統(tǒng)所有配置均采用默認(rèn)配置，執(zhí)行性能測試案例時(shí)，結(jié)果非常不理想，如省端0秒延遲場景的吞吐量僅有50TPS，響應(yīng)時(shí)間都為6~7秒。經(jīng)過不斷調(diào)整配置與代碼，性能取得了較大幅度提升，此處對(duì)性能調(diào)優(yōu)過程中比較有代表性的經(jīng)驗(yàn)總結(jié)如下：

（1）主機(jī)系統(tǒng)調(diào)優(yōu)

主要對(duì)系統(tǒng)同時(shí)打開文件句柄數(shù)進(jìn)行調(diào)整，設(shè)置為65535，避免系統(tǒng)出現(xiàn)打開過多連接的異常。

（2）JVM調(diào)優(yōu)

對(duì)各個(gè)子系統(tǒng)的JVM參數(shù)進(jìn)行了調(diào)整，主要涉及到堆大小以及GC（Garbage Collection，垃圾回收）參數(shù)調(diào)整。電商前置、省前置堆大小設(shè)置為1G，核心子系統(tǒng)堆大小設(shè)置為3G，持久代大小統(tǒng)一設(shè)置64M即足夠。GC采用吞吐量優(yōu)先的并行收集器，即-XX:+UseParallelGC。

（3）Tomcat調(diào)優(yōu)

為了提升Tomcat處理效率，建議采用異步IO模式，需要修改HTTP協(xié)議為異步IO協(xié)議，即設(shè)置Connector的Protocol屬性為"org.apache.coyote.http11.Http11NioProtocol"。

對(duì)Tomcat線程池的設(shè)置也是性能調(diào)優(yōu)的關(guān)鍵所在，線程太少則無法充分利用系統(tǒng)處理資源，線程太多也會(huì)增加系統(tǒng)調(diào)度的負(fù)擔(dān)，所以需要合理設(shè)置線程池大小。在省端0秒延遲的場景中，電商前置設(shè)置Tomcat線程最大值為100，核心為100，省前置為70，即可獲得最優(yōu)的系統(tǒng)吞吐量350TPS，各臺(tái)主機(jī)系統(tǒng)CPU消耗也能達(dá)到85%以上，增加或減少線程配置都會(huì)降低系統(tǒng)吞吐量。

（4）ActiveMQ調(diào)優(yōu)

ActiveMQ自身JVM啟動(dòng)參數(shù)也要進(jìn)行調(diào)整，需設(shè)置堆內(nèi)存為合適大小，測試環(huán)境中設(shè)置堆大小為2G。ActiveMQ的持久化模式對(duì)其自身性能影響較大，經(jīng)過測試采用Kaha Persistence存儲(chǔ)方式會(huì)有較好的處理性能。Broker的目標(biāo)策略中設(shè)置隊(duì)列的memoryLimit需要足夠大，systemUsage節(jié)點(diǎn)中對(duì)內(nèi)存空間、存儲(chǔ)空間、臨時(shí)空間的設(shè)置也要足夠，否則可能會(huì)出現(xiàn)空間不足的問題。

（5）連接池

核心子系統(tǒng)所使用的連接池為c3p0，其默認(rèn)連接數(shù)非常少，需要調(diào)整，測試過程中筆者設(shè)置連接池最大值為100。同時(shí)，對(duì)于c3p0中的兩個(gè)參數(shù)testConnectionOnCheckout和testConnectionOnCheckin都需要設(shè)置為false，否則連接池性能非常低。

4.3性能測試結(jié)果與分析

在性能調(diào)優(yōu)之后的環(huán)境中進(jìn)行了性能測試，本次性能測試采用LoadRunner進(jìn)行壓力測試，每個(gè)場景與案例的測試步驟如下：

（1）清理數(shù)據(jù)庫與系統(tǒng)日志；

（2）檢查與啟動(dòng)電商交易接入平臺(tái)各個(gè)子系統(tǒng)；

（3）設(shè)置與啟動(dòng)LoadRunner；

（4）執(zhí)行性能壓力測試；

（5）觀察與記錄壓測過程數(shù)據(jù)；

（6）分析測試數(shù)據(jù)。

通過性能測試案例的執(zhí)行，并對(duì)性能測試數(shù)據(jù)進(jìn)行分析，獲得測試結(jié)果指標(biāo)數(shù)據(jù)如表1和表2所示：

表1性能測試結(jié)果吞吐量場景 案例 平均TPS 最大TPS

省端0秒延遲 輕負(fù)荷 128 293

重負(fù)荷 352 560

過負(fù)荷 271 589

省端2秒延遲 輕負(fù)荷 128 335

重負(fù)荷 265 593

過負(fù)荷 204 441

表2性能測試結(jié)果響應(yīng)時(shí)間

場景 案例 平均響應(yīng)時(shí)間/秒 最大響應(yīng)時(shí)間/秒 最小響應(yīng)時(shí)間/秒

省端0秒延遲 輕負(fù)荷 1.359 2.382 0.056

重負(fù)荷 2.992 4.678 0.138

過負(fù)荷 6.359 8.376 0.126

省端2秒延遲 輕負(fù)荷 4.557 19.812 2.053

重負(fù)荷 7.012 25.377 2.092

過負(fù)荷 13.112 40.801 2.106

綜合分析性能測試情況與測試數(shù)據(jù)，可以得出如下結(jié)論：

（1）系統(tǒng)無延遲吞吐量可達(dá)350TPS，延遲2秒情況下可達(dá)260TPS，實(shí)際生產(chǎn)環(huán)境都是集群，硬件處理能力會(huì)提升一倍，同時(shí)由于網(wǎng)絡(luò)和系統(tǒng)處理等因素會(huì)造成省端處理延遲，采用延遲2秒260TPS作為參考，集群環(huán)境下應(yīng)該能滿足300TPS的需求。

（2）目前測試的最優(yōu)TPS為重負(fù)荷壓力下產(chǎn)生，并發(fā)用戶數(shù)為100Vuser，隨著并發(fā)用戶量的增大，系統(tǒng)進(jìn)入過負(fù)荷，TPS值會(huì)有一定幅度的下降。

（3）系統(tǒng)無延遲的響應(yīng)時(shí)間為2.9秒，延遲2秒情況下的響應(yīng)時(shí)間為7秒，能滿足平均響應(yīng)時(shí)間為10秒的要求。其中，延遲和不延遲的最長響應(yīng)時(shí)間也都在60秒以內(nèi)，可滿足系統(tǒng)需求。

（4）隨著系統(tǒng)并發(fā)壓力的增加，響應(yīng)時(shí)間明顯增加，特別是在2秒延遲情況下，過負(fù)荷比重負(fù)荷的平均響應(yīng)時(shí)間增加了約6秒，系統(tǒng)出現(xiàn)大量請(qǐng)求積壓，測試過程中觀察隊(duì)列也會(huì)出現(xiàn)明顯積壓。

（5）由于受限于測試環(huán)境，實(shí)際生產(chǎn)中的集群方式?jīng)]有進(jìn)行測試，因此實(shí)際生產(chǎn)中能達(dá)到的性能值有待最終驗(yàn)證。

5 結(jié)束語

本文介紹了電商交易接入平臺(tái)的建設(shè)背景與需求，并對(duì)其架構(gòu)和技術(shù)進(jìn)行了研究與設(shè)計(jì)，在設(shè)計(jì)中筆者除了考慮電商接入平臺(tái)的業(yè)務(wù)功能外，還重點(diǎn)針對(duì)高性能、高可靠性等非功能需求進(jìn)行了研究設(shè)計(jì)。基于這些需求，引入了一套基于J2EE的分布式架構(gòu)并進(jìn)行系統(tǒng)設(shè)計(jì)。由于篇幅有限，本文僅對(duì)關(guān)鍵技術(shù)進(jìn)行了描述，實(shí)施層面的一些技術(shù)細(xì)節(jié)并沒有詳細(xì)說明。

對(duì)于一個(gè)新建的系統(tǒng)，除了良好的架構(gòu)設(shè)計(jì)外，不斷進(jìn)行系統(tǒng)優(yōu)化也非常重要。在系統(tǒng)運(yùn)行與維護(hù)過程中會(huì)逐漸發(fā)現(xiàn)一些亟待優(yōu)化和改善的地方，例如：系統(tǒng)橫向擴(kuò)展能力存在不足，主要表現(xiàn)為Oracle數(shù)據(jù)庫以及ActiveMQ的擴(kuò)展能力上；系統(tǒng)對(duì)于消息處理異常、重發(fā)等機(jī)制上的考慮不足，一些異常情況需要運(yùn)維人員手工處理；系統(tǒng)處理流程較長，某一環(huán)節(jié)的升級(jí)、宕機(jī)等應(yīng)急機(jī)制考慮不足。諸如此類問題，可在以后的系統(tǒng)維護(hù)和建設(shè)中逐步考慮與優(yōu)化。

參考文獻(xiàn)：

[1] Len Bass, Paul Clements, Rick Kazman. 軟件架構(gòu)實(shí)踐[M]. 孫學(xué)濤,等譯. 北京: 清華大學(xué)出版社, 2002.

[2] 楊傳明. 基于開源J2EE框架的電子商務(wù)實(shí)驗(yàn)平臺(tái)研究[J]. 計(jì)算機(jī)應(yīng)用與軟件, 2009(10): 69-71.

[3] 妙旭華,包理群,李穎. 基于J2EE多層架構(gòu)的重金屬污染監(jiān)管設(shè)計(jì)[J]. 計(jì)算機(jī)應(yīng)用與軟件, 2013(4): 128-130.

[4] 藍(lán)雯飛,陸際光. 基于J2EE技術(shù)的網(wǎng)上外卡交易系統(tǒng)設(shè)計(jì)[J]. 計(jì)算機(jī)應(yīng)用與軟件, 2007(12): 212-214.

[5] 溫昱. 軟件架構(gòu)設(shè)計(jì)[M]. 2版. 北京: 電子工業(yè)出版社, 2012.

[6] 段念. 軟件性能測試過程詳解與案例剖析[M]. 2版. 北京: 清華大學(xué)出版社, 2012.

[7] 林昊. 分布式Java應(yīng)用：基礎(chǔ)與實(shí)踐[M]. 北京: 電子工業(yè)出版社, 2010.★

作者簡介

張煒：高級(jí)工程師，學(xué)士，現(xiàn)任職于中國移動(dòng)（深圳）有限公司系統(tǒng)管理部，主要研究方向?yàn)镴2EE架構(gòu)、分布式架構(gòu)和大數(shù)據(jù)技術(shù)。

endprint