基于J2EE分布式架構的高性能電商交易接入平臺研究與設計

【摘要】針對電商交易接入平臺的需求，結合平臺的高性能與高可靠性特點，提出了采用J2EE分布式技術進行系統實施的方案，對電商交易接入平臺的架構進行了設計，并分析和討論關鍵技術點。最后還對系統進行了性能壓力測試，以保證系統的安全穩定運行。

【關鍵詞】J2EE分布式電子商務接入平臺高性能高可靠性

中圖分類號：TP311.1文獻標識碼：A文章編號：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 引言

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

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

本文將對電商交易接入平臺進行研究分析，并介紹相關架構設計與關鍵技術設計。

2 電商交易接入平臺架構

2.1應用架構

結合系統定位以及業務功能與非功能性需求特點進行總體架構設計，劃分出整個平臺的邏輯應用架構，如圖1所示：

圖1電商交易接入平臺應用架構圖

將電商交易接入平臺劃分為以下六個子系統：

（1）電商前置子系統：負責與電商平臺進行通信交互，接收與處理電商前置的充值、查詢等請求，實現協議轉換、驗簽、加解密等功能，并負責將處理結果返回給電商平臺。

（2）省前置子系統：負責與省中心BOSS（Business Operations Support System，業務運營支撐系統）系統進行通信交互，接收核心的處理請求，并把交易請求消息通過網狀網節點發送給省中心BOSS系統。

（3）文件前置子系統：負責接收與電商平臺以及省中心BOSS的對賬文件，并轉發給清結算子系統處理，文件前置子系統主要通過系統的定時任務獲取或上傳與外部交互的文件。

（4）加解密子系統：實現報文的驗簽與加解密算法，并對前置子系統提供驗簽與加解密訪問服務。

（5）核心交易子系統：主要負責整個平臺的數據校驗、業務處理、交易查重、交易入庫等功能，與數據庫大量交互，是本平臺建設的關鍵子系統。

（6）清結算子系統：主要通過定時任務的調度對電商側以及省側的交易記錄進行對賬，完成批量文件的處理，清結算子系統與文件前置間通過FTP文件的方式進行交互。

2.2技術架構

電商交易接入平臺技術架構如圖2所示：

圖2電商交易接入平臺技術架構圖

電商交易接入平臺采用J2EE（Java 2 Enterprise Edition，Java 2企業版）架構進行設計，技術架構邏輯上可劃分為：

（1）業務接入層：負責外層通信交互，采用Apache作為HTTP服務器，Tomcat作為應用服務器。

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

（3）業務處理層：負責關鍵的業務邏輯處理，采用Tomcat作為應用服務器，部署J2EE應用，業務邏輯采用Spring容器進行管理，數據庫訪問操作基于iBatis ORM（Object Relation Mapping，對象關系映射）框架，底層采用c3p0連接池。

（4）數據服務層：負責數據的存儲，提供關系型數據的訪問服務，采用Oracle數據庫。

其中，業務接入層與業務處理層采用JMS消息中間件通信，即可實現交易的異步處理與分布式部署，在高并發與高性能環境中具備良好的擴展性。

endprint

2.3部署架構

電商交易接入平臺部署架構如圖3所示。

總體劃分為接口域和核心域兩個域。接口域部署三個前置子系統，負責與外部接口交互，位于防火墻外；核心域部署消息中間件、核心應用、清結算應用、加解密應用以及數據庫，是整個平臺的處理中心，位于防火墻內，安全級別較高。

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

3 電商交易接入平臺關鍵技術

3.1高性能集群設計

為了滿足高性能與高并發需求，同時應對互聯網上的突發用戶量，如“雙11”促銷、節假日促銷等，電商交易接入平臺需要具備良好的分布式集群能力，在性能不足的情況下能通過增加節點、橫向擴展來擴充處理能力。為此，電商交易接入平臺在各個層次設計了集群方案，具體如下：

（1）電商前置負載均衡

電商前置基于經典的Apache+Tomcat集群部署方案，交易請求以HTTP協議接入，Apache負責在多個電商前置應用節點上進行負載均衡，隨著請求量增大，為了滿足高并發與高性能需求，可以及時增加電商前置處理節點。高峰時段后如果請求量下降，可以減少電商前置處理節點，合理利用機器資源。

（2）ActiveMQ隊列集群

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

圖4ActiveMQ集群原理圖

（3）核心處理集群

核心應用作為war包在Tomcat中進行部署。核心應用與外界交互一側為電商前置隊列，另一側為省前置隊列，均為異步消息的松耦合方式，可以方便地通過增加節點的方式擴展處理能力。異步入庫目前作為核心的一部分，在集群節點中設立單獨的開關，集群節點可以根據需要考慮是否打開異步入庫服務，如果異步入庫壓力不大，建議只采用一個節點進行異步入庫，以免對數據庫造成過大壓力，影響適時交易處理性能。

（4）省前置處理集群

省前置通過隊列與核心子系統進行交互，JMS消息為異步松耦合訪問，可通過擴展節點增加消息處理能力；同時，省前置與省CRM通過HTTP方式訪問，此時省前置是HTTP Client，可方便地支持多節點集群部署。因此，省前置也可根據需要進行多節點集群。

（5）數據庫集群

基于Oracle RAC（Real Application Clusters，實時應用集群）技術構建高可用數據庫集群，當應用規模需要擴充時，可以按需擴展數據庫服務節點，以保證系統的性能。Oracle RAC具有如下特點：

◆支持多節點負載均衡；

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

◆通過并行執行技術提高事務響應時間；

◆通過橫向擴展提高每秒交易數和連接數；

◆良好可擴展性：可以方便添加/刪除節點，擴展硬件資源。

3.2高可靠性設計

電商交易接入平臺提供了完整的高可靠性方案，在部署方案中不會出現因單點故障而造成的服務中斷，具備非常高的可靠性，具體設計方案如下：

（1）電商前置基于Apache集群，電商前置應用節點已無單點故障問題，其中Apache服務器采用基于Linux系統的HA方案，實現Primary-Standby模式的高可靠性。

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

（3）清結算子系統采用基于Linux系統的HA方案，實現Primary-Standby模式的高可靠性，支持主備故障切換，沒有單點故障。

（4）核心子系統、省前置子系統都是基于隊列消息訪問的集群部署方式，集群中某一節點故障就將不再處理消息，消息會自動由其他節點進行處理，無單點故障問題。

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

3.3JMS隊列處理機制

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

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

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

3.4異步批量入庫

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

endprint

4 性能測試與調優

電商交易接入平臺性能需求：吞吐量為300TPS，平均事務響應時間為10秒，最長事務響應時間為60秒。需要對系統進行性能測試與調優，以達到性能要求。

4.1性能測試場景與案例

為了充分測試出系統性能，結合實際應用情況對測試場景與案例進行了設計，具體內容如下：

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

案例1：輕負荷，5個Vuser（Virtual user，虛擬用戶）同時并發發送消息，每個Vuser迭代發送2 000次消息；

案例2：重負荷，100個Vuser同時并發發送消息，每個Vuser迭代發送1 000次消息；

案例3：過負荷，500個Vuser同時并發發送消息，每個Vuser迭代發送200次消息。

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

案例1：輕負荷，5個Vuser同時并發發送消息，每個Vuser迭代發送2 000次消息；

案例2：重負荷，100個Vuser同時并發發送消息，每個Vuser迭代發送1 000次消息；

案例3：過負荷，500個Vuser同時并發發送消息，每個Vuser迭代發送200次消息。

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

4.2性能測試調優

測試初期系統所有配置均采用默認配置，執行性能測試案例時，結果非常不理想，如省端0秒延遲場景的吞吐量僅有50TPS，響應時間都為6~7秒。經過不斷調整配置與代碼，性能取得了較大幅度提升，此處對性能調優過程中比較有代表性的經驗總結如下：

（1）主機系統調優

主要對系統同時打開文件句柄數進行調整，設置為65535，避免系統出現打開過多連接的異常。

（2）JVM調優

對各個子系統的JVM參數進行了調整，主要涉及到堆大小以及GC（Garbage Collection，垃圾回收）參數調整。電商前置、省前置堆大小設置為1G，核心子系統堆大小設置為3G，持久代大小統一設置64M即足夠。GC采用吞吐量優先的并行收集器，即-XX:+UseParallelGC。

（3）Tomcat調優

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

對Tomcat線程池的設置也是性能調優的關鍵所在，線程太少則無法充分利用系統處理資源，線程太多也會增加系統調度的負擔，所以需要合理設置線程池大小。在省端0秒延遲的場景中，電商前置設置Tomcat線程最大值為100，核心為100，省前置為70，即可獲得最優的系統吞吐量350TPS，各臺主機系統CPU消耗也能達到85%以上，增加或減少線程配置都會降低系統吞吐量。

（4）ActiveMQ調優

ActiveMQ自身JVM啟動參數也要進行調整，需設置堆內存為合適大小，測試環境中設置堆大小為2G。ActiveMQ的持久化模式對其自身性能影響較大，經過測試采用Kaha Persistence存儲方式會有較好的處理性能。Broker的目標策略中設置隊列的memoryLimit需要足夠大，systemUsage節點中對內存空間、存儲空間、臨時空間的設置也要足夠，否則可能會出現空間不足的問題。

（5）連接池

核心子系統所使用的連接池為c3p0，其默認連接數非常少，需要調整，測試過程中筆者設置連接池最大值為100。同時，對于c3p0中的兩個參數testConnectionOnCheckout和testConnectionOnCheckin都需要設置為false，否則連接池性能非常低。

4.3性能測試結果與分析

在性能調優之后的環境中進行了性能測試，本次性能測試采用LoadRunner進行壓力測試，每個場景與案例的測試步驟如下：

（1）清理數據庫與系統日志；

（2）檢查與啟動電商交易接入平臺各個子系統；

（3）設置與啟動LoadRunner；

（4）執行性能壓力測試；

（5）觀察與記錄壓測過程數據；

（6）分析測試數據。

通過性能測試案例的執行，并對性能測試數據進行分析，獲得測試結果指標數據如表1和表2所示：

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

省端0秒延遲 輕負荷 128 293

重負荷 352 560

過負荷 271 589

省端2秒延遲 輕負荷 128 335

重負荷 265 593

過負荷 204 441

表2性能測試結果響應時間

場景 案例 平均響應時間/秒 最大響應時間/秒 最小響應時間/秒

省端0秒延遲 輕負荷 1.359 2.382 0.056

重負荷 2.992 4.678 0.138

過負荷 6.359 8.376 0.126

省端2秒延遲 輕負荷 4.557 19.812 2.053

重負荷 7.012 25.377 2.092

過負荷 13.112 40.801 2.106

綜合分析性能測試情況與測試數據，可以得出如下結論：

（1）系統無延遲吞吐量可達350TPS，延遲2秒情況下可達260TPS，實際生產環境都是集群，硬件處理能力會提升一倍，同時由于網絡和系統處理等因素會造成省端處理延遲，采用延遲2秒260TPS作為參考，集群環境下應該能滿足300TPS的需求。

（2）目前測試的最優TPS為重負荷壓力下產生，并發用戶數為100Vuser，隨著并發用戶量的增大，系統進入過負荷，TPS值會有一定幅度的下降。

（3）系統無延遲的響應時間為2.9秒，延遲2秒情況下的響應時間為7秒，能滿足平均響應時間為10秒的要求。其中，延遲和不延遲的最長響應時間也都在60秒以內，可滿足系統需求。

（4）隨著系統并發壓力的增加，響應時間明顯增加，特別是在2秒延遲情況下，過負荷比重負荷的平均響應時間增加了約6秒，系統出現大量請求積壓，測試過程中觀察隊列也會出現明顯積壓。

（5）由于受限于測試環境，實際生產中的集群方式沒有進行測試，因此實際生產中能達到的性能值有待最終驗證。

5 結束語

本文介紹了電商交易接入平臺的建設背景與需求，并對其架構和技術進行了研究與設計，在設計中筆者除了考慮電商接入平臺的業務功能外，還重點針對高性能、高可靠性等非功能需求進行了研究設計。基于這些需求，引入了一套基于J2EE的分布式架構并進行系統設計。由于篇幅有限，本文僅對關鍵技術進行了描述，實施層面的一些技術細節并沒有詳細說明。

對于一個新建的系統，除了良好的架構設計外，不斷進行系統優化也非常重要。在系統運行與維護過程中會逐漸發現一些亟待優化和改善的地方，例如：系統橫向擴展能力存在不足，主要表現為Oracle數據庫以及ActiveMQ的擴展能力上；系統對于消息處理異常、重發等機制上的考慮不足，一些異常情況需要運維人員手工處理；系統處理流程較長，某一環節的升級、宕機等應急機制考慮不足。諸如此類問題，可在以后的系統維護和建設中逐步考慮與優化。

參考文獻：

[1] Len Bass, Paul Clements, Rick Kazman. 軟件架構實踐[M]. 孫學濤,等譯. 北京: 清華大學出版社, 2002.

[2] 楊傳明. 基于開源J2EE框架的電子商務實驗平臺研究[J]. 計算機應用與軟件, 2009(10): 69-71.

[3] 妙旭華,包理群,李穎. 基于J2EE多層架構的重金屬污染監管設計[J]. 計算機應用與軟件, 2013(4): 128-130.

[4] 藍雯飛,陸際光. 基于J2EE技術的網上外卡交易系統設計[J]. 計算機應用與軟件, 2007(12): 212-214.

[5] 溫昱. 軟件架構設計[M]. 2版. 北京: 電子工業出版社, 2012.

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

[7] 林昊. 分布式Java應用：基礎與實踐[M]. 北京: 電子工業出版社, 2010.★

作者簡介

張煒：高級工程師，學士，現任職于中國移動（深圳）有限公司系統管理部，主要研究方向為J2EE架構、分布式架構和大數據技術。

endprint

4 性能測試與調優

電商交易接入平臺性能需求：吞吐量為300TPS，平均事務響應時間為10秒，最長事務響應時間為60秒。需要對系統進行性能測試與調優，以達到性能要求。

4.1性能測試場景與案例

為了充分測試出系統性能，結合實際應用情況對測試場景與案例進行了設計，具體內容如下：

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

案例1：輕負荷，5個Vuser（Virtual user，虛擬用戶）同時并發發送消息，每個Vuser迭代發送2 000次消息；

案例2：重負荷，100個Vuser同時并發發送消息，每個Vuser迭代發送1 000次消息；

案例3：過負荷，500個Vuser同時并發發送消息，每個Vuser迭代發送200次消息。

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

案例1：輕負荷，5個Vuser同時并發發送消息，每個Vuser迭代發送2 000次消息；

案例2：重負荷，100個Vuser同時并發發送消息，每個Vuser迭代發送1 000次消息；

案例3：過負荷，500個Vuser同時并發發送消息，每個Vuser迭代發送200次消息。

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

4.2性能測試調優

測試初期系統所有配置均采用默認配置，執行性能測試案例時，結果非常不理想，如省端0秒延遲場景的吞吐量僅有50TPS，響應時間都為6~7秒。經過不斷調整配置與代碼，性能取得了較大幅度提升，此處對性能調優過程中比較有代表性的經驗總結如下：

（1）主機系統調優

主要對系統同時打開文件句柄數進行調整，設置為65535，避免系統出現打開過多連接的異常。

（2）JVM調優

對各個子系統的JVM參數進行了調整，主要涉及到堆大小以及GC（Garbage Collection，垃圾回收）參數調整。電商前置、省前置堆大小設置為1G，核心子系統堆大小設置為3G，持久代大小統一設置64M即足夠。GC采用吞吐量優先的并行收集器，即-XX:+UseParallelGC。

（3）Tomcat調優

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

對Tomcat線程池的設置也是性能調優的關鍵所在，線程太少則無法充分利用系統處理資源，線程太多也會增加系統調度的負擔，所以需要合理設置線程池大小。在省端0秒延遲的場景中，電商前置設置Tomcat線程最大值為100，核心為100，省前置為70，即可獲得最優的系統吞吐量350TPS，各臺主機系統CPU消耗也能達到85%以上，增加或減少線程配置都會降低系統吞吐量。

（4）ActiveMQ調優

ActiveMQ自身JVM啟動參數也要進行調整，需設置堆內存為合適大小，測試環境中設置堆大小為2G。ActiveMQ的持久化模式對其自身性能影響較大，經過測試采用Kaha Persistence存儲方式會有較好的處理性能。Broker的目標策略中設置隊列的memoryLimit需要足夠大，systemUsage節點中對內存空間、存儲空間、臨時空間的設置也要足夠，否則可能會出現空間不足的問題。

（5）連接池

核心子系統所使用的連接池為c3p0，其默認連接數非常少，需要調整，測試過程中筆者設置連接池最大值為100。同時，對于c3p0中的兩個參數testConnectionOnCheckout和testConnectionOnCheckin都需要設置為false，否則連接池性能非常低。

4.3性能測試結果與分析

在性能調優之后的環境中進行了性能測試，本次性能測試采用LoadRunner進行壓力測試，每個場景與案例的測試步驟如下：

（1）清理數據庫與系統日志；

（2）檢查與啟動電商交易接入平臺各個子系統；

（3）設置與啟動LoadRunner；

（4）執行性能壓力測試；

（5）觀察與記錄壓測過程數據；

（6）分析測試數據。

通過性能測試案例的執行，并對性能測試數據進行分析，獲得測試結果指標數據如表1和表2所示：

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

省端0秒延遲 輕負荷 128 293

重負荷 352 560

過負荷 271 589

省端2秒延遲 輕負荷 128 335

重負荷 265 593

過負荷 204 441

表2性能測試結果響應時間

場景 案例 平均響應時間/秒 最大響應時間/秒 最小響應時間/秒

省端0秒延遲 輕負荷 1.359 2.382 0.056

重負荷 2.992 4.678 0.138

過負荷 6.359 8.376 0.126

省端2秒延遲 輕負荷 4.557 19.812 2.053

重負荷 7.012 25.377 2.092

過負荷 13.112 40.801 2.106

綜合分析性能測試情況與測試數據，可以得出如下結論：

（1）系統無延遲吞吐量可達350TPS，延遲2秒情況下可達260TPS，實際生產環境都是集群，硬件處理能力會提升一倍，同時由于網絡和系統處理等因素會造成省端處理延遲，采用延遲2秒260TPS作為參考，集群環境下應該能滿足300TPS的需求。

（2）目前測試的最優TPS為重負荷壓力下產生，并發用戶數為100Vuser，隨著并發用戶量的增大，系統進入過負荷，TPS值會有一定幅度的下降。

（3）系統無延遲的響應時間為2.9秒，延遲2秒情況下的響應時間為7秒，能滿足平均響應時間為10秒的要求。其中，延遲和不延遲的最長響應時間也都在60秒以內，可滿足系統需求。

（4）隨著系統并發壓力的增加，響應時間明顯增加，特別是在2秒延遲情況下，過負荷比重負荷的平均響應時間增加了約6秒，系統出現大量請求積壓，測試過程中觀察隊列也會出現明顯積壓。

（5）由于受限于測試環境，實際生產中的集群方式沒有進行測試，因此實際生產中能達到的性能值有待最終驗證。

5 結束語

本文介紹了電商交易接入平臺的建設背景與需求，并對其架構和技術進行了研究與設計，在設計中筆者除了考慮電商接入平臺的業務功能外，還重點針對高性能、高可靠性等非功能需求進行了研究設計。基于這些需求，引入了一套基于J2EE的分布式架構并進行系統設計。由于篇幅有限，本文僅對關鍵技術進行了描述，實施層面的一些技術細節并沒有詳細說明。

對于一個新建的系統，除了良好的架構設計外，不斷進行系統優化也非常重要。在系統運行與維護過程中會逐漸發現一些亟待優化和改善的地方，例如：系統橫向擴展能力存在不足，主要表現為Oracle數據庫以及ActiveMQ的擴展能力上；系統對于消息處理異常、重發等機制上的考慮不足，一些異常情況需要運維人員手工處理；系統處理流程較長，某一環節的升級、宕機等應急機制考慮不足。諸如此類問題，可在以后的系統維護和建設中逐步考慮與優化。

參考文獻：

[1] Len Bass, Paul Clements, Rick Kazman. 軟件架構實踐[M]. 孫學濤,等譯. 北京: 清華大學出版社, 2002.

[2] 楊傳明. 基于開源J2EE框架的電子商務實驗平臺研究[J]. 計算機應用與軟件, 2009(10): 69-71.

[3] 妙旭華,包理群,李穎. 基于J2EE多層架構的重金屬污染監管設計[J]. 計算機應用與軟件, 2013(4): 128-130.

[4] 藍雯飛,陸際光. 基于J2EE技術的網上外卡交易系統設計[J]. 計算機應用與軟件, 2007(12): 212-214.

[5] 溫昱. 軟件架構設計[M]. 2版. 北京: 電子工業出版社, 2012.

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

[7] 林昊. 分布式Java應用：基礎與實踐[M]. 北京: 電子工業出版社, 2010.★

作者簡介

張煒：高級工程師，學士，現任職于中國移動（深圳）有限公司系統管理部，主要研究方向為J2EE架構、分布式架構和大數據技術。

endprint

4 性能測試與調優

電商交易接入平臺性能需求：吞吐量為300TPS，平均事務響應時間為10秒，最長事務響應時間為60秒。需要對系統進行性能測試與調優，以達到性能要求。

4.1性能測試場景與案例

為了充分測試出系統性能，結合實際應用情況對測試場景與案例進行了設計，具體內容如下：

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

案例1：輕負荷，5個Vuser（Virtual user，虛擬用戶）同時并發發送消息，每個Vuser迭代發送2 000次消息；

案例2：重負荷，100個Vuser同時并發發送消息，每個Vuser迭代發送1 000次消息；

案例3：過負荷，500個Vuser同時并發發送消息，每個Vuser迭代發送200次消息。

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

案例1：輕負荷，5個Vuser同時并發發送消息，每個Vuser迭代發送2 000次消息；

案例2：重負荷，100個Vuser同時并發發送消息，每個Vuser迭代發送1 000次消息；

案例3：過負荷，500個Vuser同時并發發送消息，每個Vuser迭代發送200次消息。

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

4.2性能測試調優

測試初期系統所有配置均采用默認配置，執行性能測試案例時，結果非常不理想，如省端0秒延遲場景的吞吐量僅有50TPS，響應時間都為6~7秒。經過不斷調整配置與代碼，性能取得了較大幅度提升，此處對性能調優過程中比較有代表性的經驗總結如下：

（1）主機系統調優

主要對系統同時打開文件句柄數進行調整，設置為65535，避免系統出現打開過多連接的異常。

（2）JVM調優

對各個子系統的JVM參數進行了調整，主要涉及到堆大小以及GC（Garbage Collection，垃圾回收）參數調整。電商前置、省前置堆大小設置為1G，核心子系統堆大小設置為3G，持久代大小統一設置64M即足夠。GC采用吞吐量優先的并行收集器，即-XX:+UseParallelGC。

（3）Tomcat調優

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

對Tomcat線程池的設置也是性能調優的關鍵所在，線程太少則無法充分利用系統處理資源，線程太多也會增加系統調度的負擔，所以需要合理設置線程池大小。在省端0秒延遲的場景中，電商前置設置Tomcat線程最大值為100，核心為100，省前置為70，即可獲得最優的系統吞吐量350TPS，各臺主機系統CPU消耗也能達到85%以上，增加或減少線程配置都會降低系統吞吐量。

（4）ActiveMQ調優

ActiveMQ自身JVM啟動參數也要進行調整，需設置堆內存為合適大小，測試環境中設置堆大小為2G。ActiveMQ的持久化模式對其自身性能影響較大，經過測試采用Kaha Persistence存儲方式會有較好的處理性能。Broker的目標策略中設置隊列的memoryLimit需要足夠大，systemUsage節點中對內存空間、存儲空間、臨時空間的設置也要足夠，否則可能會出現空間不足的問題。

（5）連接池

核心子系統所使用的連接池為c3p0，其默認連接數非常少，需要調整，測試過程中筆者設置連接池最大值為100。同時，對于c3p0中的兩個參數testConnectionOnCheckout和testConnectionOnCheckin都需要設置為false，否則連接池性能非常低。

4.3性能測試結果與分析

在性能調優之后的環境中進行了性能測試，本次性能測試采用LoadRunner進行壓力測試，每個場景與案例的測試步驟如下：

（1）清理數據庫與系統日志；

（2）檢查與啟動電商交易接入平臺各個子系統；

（3）設置與啟動LoadRunner；

（4）執行性能壓力測試；

（5）觀察與記錄壓測過程數據；

（6）分析測試數據。

通過性能測試案例的執行，并對性能測試數據進行分析，獲得測試結果指標數據如表1和表2所示：

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

省端0秒延遲 輕負荷 128 293

重負荷 352 560

過負荷 271 589

省端2秒延遲 輕負荷 128 335

重負荷 265 593

過負荷 204 441

表2性能測試結果響應時間

場景 案例 平均響應時間/秒 最大響應時間/秒 最小響應時間/秒

省端0秒延遲 輕負荷 1.359 2.382 0.056

重負荷 2.992 4.678 0.138

過負荷 6.359 8.376 0.126

省端2秒延遲 輕負荷 4.557 19.812 2.053

重負荷 7.012 25.377 2.092

過負荷 13.112 40.801 2.106

綜合分析性能測試情況與測試數據，可以得出如下結論：

（1）系統無延遲吞吐量可達350TPS，延遲2秒情況下可達260TPS，實際生產環境都是集群，硬件處理能力會提升一倍，同時由于網絡和系統處理等因素會造成省端處理延遲，采用延遲2秒260TPS作為參考，集群環境下應該能滿足300TPS的需求。

（2）目前測試的最優TPS為重負荷壓力下產生，并發用戶數為100Vuser，隨著并發用戶量的增大，系統進入過負荷，TPS值會有一定幅度的下降。

（3）系統無延遲的響應時間為2.9秒，延遲2秒情況下的響應時間為7秒，能滿足平均響應時間為10秒的要求。其中，延遲和不延遲的最長響應時間也都在60秒以內，可滿足系統需求。

（4）隨著系統并發壓力的增加，響應時間明顯增加，特別是在2秒延遲情況下，過負荷比重負荷的平均響應時間增加了約6秒，系統出現大量請求積壓，測試過程中觀察隊列也會出現明顯積壓。

（5）由于受限于測試環境，實際生產中的集群方式沒有進行測試，因此實際生產中能達到的性能值有待最終驗證。

5 結束語

本文介紹了電商交易接入平臺的建設背景與需求，并對其架構和技術進行了研究與設計，在設計中筆者除了考慮電商接入平臺的業務功能外，還重點針對高性能、高可靠性等非功能需求進行了研究設計。基于這些需求，引入了一套基于J2EE的分布式架構并進行系統設計。由于篇幅有限，本文僅對關鍵技術進行了描述，實施層面的一些技術細節并沒有詳細說明。

對于一個新建的系統，除了良好的架構設計外，不斷進行系統優化也非常重要。在系統運行與維護過程中會逐漸發現一些亟待優化和改善的地方，例如：系統橫向擴展能力存在不足，主要表現為Oracle數據庫以及ActiveMQ的擴展能力上；系統對于消息處理異常、重發等機制上的考慮不足，一些異常情況需要運維人員手工處理；系統處理流程較長，某一環節的升級、宕機等應急機制考慮不足。諸如此類問題，可在以后的系統維護和建設中逐步考慮與優化。

參考文獻：

[1] Len Bass, Paul Clements, Rick Kazman. 軟件架構實踐[M]. 孫學濤,等譯. 北京: 清華大學出版社, 2002.

[2] 楊傳明. 基于開源J2EE框架的電子商務實驗平臺研究[J]. 計算機應用與軟件, 2009(10): 69-71.

[3] 妙旭華,包理群,李穎. 基于J2EE多層架構的重金屬污染監管設計[J]. 計算機應用與軟件, 2013(4): 128-130.

[4] 藍雯飛,陸際光. 基于J2EE技術的網上外卡交易系統設計[J]. 計算機應用與軟件, 2007(12): 212-214.

[5] 溫昱. 軟件架構設計[M]. 2版. 北京: 電子工業出版社, 2012.

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

[7] 林昊. 分布式Java應用：基礎與實踐[M]. 北京: 電子工業出版社, 2010.★

作者簡介

張煒：高級工程師，學士，現任職于中國移動（深圳）有限公司系統管理部，主要研究方向為J2EE架構、分布式架構和大數據技術。

endprint