【摘要】针对电商交易接入平台的需求，结合平台的高性能与高可靠性特点，提出了采用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