产品方案技术白皮书模板2(含系统架构说明书)

市场部文件

附件二十九：产品方案技术白皮书

一、背景概述 ................................................................................................................................... 2

1、研发背景 ................................................................................................................................. 2

2、产品定位 ................................................................................................................................. 2

二、产品方案功能介绍 ................................................................................................................... 2

1、设计理念 ................................................................................................................................. 2

2、系统拓扑图 ............................................................................................................................. 2

3、系统构架描述 ......................................................................................................................... 2

4、系统功能介绍 ......................................................................................................................... 2

5、产品方案规格 ......................................................................................................................... 2

四、产品方案应用介绍 ................................................................................................................... 3

1、应用模式 ................................................................................................................................. 3

2、应用流程 ................................................................................................................................. 3

3、应用环境 ................................................................................................................................. 3

五、产品方案特性介绍 ................................................................................................................... 3

1、技术特性 ................................................................................................................................. 3

2、应用特性 ................................................................................................................................. 3

3、系统特性 ................................................................................................................................. 3

六、产品方案技术介绍 ................................................................................................................... 3

1、相关技术 ................................................................................................................................. 3

2、技术指标 ................................................................................................................................. 4

七、产品方案测评数据 ................................................................................................................... 4

八、实施运维方式说明 ................................................................................................................... 4

九、售后服务方式说明 ................................................................................................................... 4

1

市场部文件

一、背景概述

1、研发背景

介绍用户需求背景、该产品所在行业信息化建设背景、产品所涉及的相关政策简述等，以说明该产品的研发背景，以及满足的客户需求。

2、产品定位

为了满足客户以上需求，该产品具有什么功能，能够解决什么问题。

二、产品方案功能介绍

1、设计理念

该产品方案的设计思路。

2、系统拓扑图

使用统一的图标，制作系统拓扑图。

3、系统构架描述

按照系统的构成，分类对系统进行描述。

4、系统功能介绍

详细阐述系统的主要功能。

5、产品方案规格

产品方案不同的规格介绍，或者对产品方案技术规格的介绍。

2

市场部文件

四、产品方案应用介绍

1、应用模式

该产品方案包括的应用模式类型，或者针对不同类型客户的解决方案。

2、应用流程

该产品方案的应用流程。

3、应用环境

描述该产品所运行的应用环境。

五、产品方案特性介绍

1、技术特性

主要是性能先进性、功能齐全性、系统兼容性、技术稳定性等。

2、应用特性

主要是部署灵活性、可扩展性、管理方便性、易用性等。

3、系统特性

对系统的主要特性进行描述，根据产品不同和竞争优势的不同而不同。

六、产品方案技术介绍

1、相关技术

主要应用技术的介绍，以及该技术的优势。

3

市场部文件

2、技术指标

针对技术参数进行描述。

七、产品方案测评数据

产品方案主要测评数据，可以是内部测评数据，也可以是第三方的测评数据。

八、实施运维方式说明

该产品方案的实施运营方式，以及实施运营需要注意问题的说明。

九、售后服务方式说明

该产品方案的售后服务方式、服务标准、服务内容说明，以及不同服务方式的报价。

电子商务平台技术架构说明书

目 录

技术性需求分析4

一致的逻辑数据4

优秀的网络环境适应性4

系统的兼容性4

优异的系统性能4

开放的界面和接口4

完备的操作日志管理策略4

高度的安全性4

技术性设计思想和原则5

最小成本原则5

4

市场部文件

安全性、可靠性、先进性原则5

安全性与可靠性原则5

先进性原则：5

实用性、易用性、可扩展性原则5

实用性原则5

统一及一致性原则6

业务引导及易用性原则6

友好及方便性原则6

扩展性和适应性原则6

数据共享原则7

系统技术架构的设计7

技术架构的特点7

系统的架构图7

技术架构图7

系统请求数据处理流程图9

体系结构图10

系统核心功能分布图11

架构层次的说明11

数据库层11

中间件层12

基础服务层16

应用层20

业务表现层和系统接口层21

系统部署环境22

商城平台部署环境22

运行平台22

操作系统22

应用服务器23

Web服务器23

数据库服务器23

缓存服务器23

图片文件服务器23

系统部署拓扑图23

系统部署结构图24

技术性需求分析

一致的逻辑数据

一般来说，平台所有的服务接点都是这个数据库的客户端访问；因此从逻辑上，任意服务网络接入点的数据应该是一致的。

5

市场部文件

优秀的网络环境适应性

从系统的实现角度考虑，要满足各种复杂的网络环境。

系统的兼容性

由于服务结点的数量巨大，其使用的平台和语言各不相同，需要能够容纳所有类型的服务结点；

优异的系统性能

从系统架构设计上需要考虑巨大量数据的处理引擎，从系统本身进行性能上的优化，而不是仅仅凭借于硬件服务器的性能。

开放的界面和接口

不仅个人用户能够方便地通过Web应用查询信息，同时也需要能够预留非GUI的交互界面的接口，以便使其它应用系统也能使用数据管理系统提供的信息服务，同时还需要为第三方软件预留标准的集成接口，使系统具有高度的可扩展性；

完备的操作日志管理策略

需要有完备的操作日志管理引擎，记录系统交互过程中的日志数据。

高度的安全性

利用JAVA所特有的安全性,更多的从系统角度去维护数据的安全，同时需要从数据库和服务器的角度提出安全维护的有效建议。

技术性设计思想和原则

最小成本原则

系统建设充分考虑目前已实施的业务系统的实际情况，充分利用原系统资源，在实现新系统建设同时保护原有系统的资源。

任何一个系统的建设，如果不能合理和有效地利用现有的资源和之前的系统的资源，这样的系统应该算不了绝对的成功。因此，在进行系统重建时，充分考虑如何利用以前的信息系统、网络和其他设备，并对以前实施的应用系统进行整合，一方面保证原有的设备可以重新利用，另一方面保证以前的应用重获新生。在真正意义上做到既完成了新系统的建设又保护了原有设备和系统的资源。

6

市场部文件

安全性、可靠性、先进性原则

安全性与可靠性原则：

考虑到电子商务系统工程建设项目安全性、可靠性的需求，在系统设计中，应充分注意系统的安全性和可靠性，采用多种安全防范技术和措施，保障系统的信息安全，保障系统长期稳定可靠运行，同时在系统设计要充分考虑系统运行性能，达到“简便、实用、快捷、安全、准确”的目的。

先进性原则：

由于IT技术发展的速度惊人。因此，在电子商务项目进行系统总体规划时，我们选择业界到目前为止先进和成熟的技术作为整个系统的技术架构，以保证系统有不断发展和扩充的余地。

系统总体设计的先进性原则主要体现在以下几方面：

1）系统结构选择当前先进的SSH架构进行逻辑和业务和展示分层的架构进行系统开发；

2）软件的设计中利用先进的面向对象技术、设计模式、接口技术和组件技术来提高软件的通用性和复用性。

实用性、易用性、可扩展性原则

实用性原则

衡量一个电子商务系统的好坏决不是看它投入了多少、如何的先进，而是看它是否真正满足运营业务需求，是否真的符合真正的运营情况。因此，在进行系统的建设时，我们始终不忘实用性原则，努力保证投资花在实处，保证建设出来的系统切切实实是所需要的，而不是一个富丽堂皇的空架子，光有一个外表而没有实际的内容。

实用性是每个信息系统在建设过程中所必须考虑的，从实际应用的角度来看，这个性能更加重要。为了提高系统的实用性，本系统考虑如下几个方面：

◆设计上充分考虑当前各业务层次、各环节管理中数据处理的便利和可行，把满足用户业务管理作为第一要素进行考虑；

◆采取总体设计、分步实施的技术方案，在总体设计的前提下，系统实施时先进行业务处理层及低层管理，稳步向中高层管理及全面自动化过渡。这样做可以使系统始终与业务实际需求紧密连在一起，不但增加了系统的实用性，而且可使系统建设保持很好的连贯性；

◆全部人机操作设计均充分考虑不同使用者的实际需要；

◆用户接口及界面设计充分考虑人体结构特征及视觉特征进行优化设计，界面尽可能美观大方，操作简便实用。

统一及一致性原则

在统一的用户界面风格前提下，实现各GUI中各类按钮、图标、文字（字体、大小）、热键（快捷键）的统一和一致，达到便于使用、便于学习、交互友好的目的。

人机工程及标准化原则

在保证界面风格统一、一致的基础上，按照人机工程原理，遵循IBM和Microsoft的界面设计标准，将界面的布局（包括按钮、菜单、显示框等）设计成符合操作者习惯的形式，并在界面颜色的搭配上满足操作者长时间工作要求，提供一个人性化的人机操作环境，以保证用户使用的舒适性。

业务引导及易用性原则

充分考虑业务的管理需求，在界面的菜单及功能的组合设计中，将界面的操作顺序按业务归类，以便操作的有效引导，保证软件的易用性。同时，在各功能名称的用词、信息提示文字 7

市场部文件

等方面，使用政府审批业务的规范化、习惯化用词，以保证软件使用者的习惯性，符合现有政府审批管理模式，有利于操作者在较快的时间熟练用好软件。

友好及方便性原则

鼠标、键盘的灵活输入方式；热键的使用，以保证各种业务数据信息的录入界面，更新维护界面和记录增删界面及部门内部信息查询界面和信息统计报表界面等使用的方便性、友好性，确保各种业务信息数据都能通过用户界面方便地、快速录入。

扩展性和适应性原则

扩展性和适应性是系统升级前要考虑的首要元素，为了进一步让客户能够降低成本来完成未来可预见的系统升级开发，系统在设计时就充分考虑到实际系统在今后工作发展而产生的升级需求，尽量保证在原有代码基础上容易适应、容易修改和升级的目标。

数据共享原则

对所有的数据采用合理的数据结构，把它们有效地组织好，进行统一维护管理，避免数据重复，减少冗余，提高准确性和可靠性，保证数据的统一性和完整性。

系统技术架构的设计

技术架构的特点

我们的技术架构有以下特点：

◆采用目前安全性能高，扩展性好，框架技术最为完善JAVA语言作为系统开发的语言。

◆采用SSH框架技术，使系统能够分层开发，各层之间逻辑分明，层与层之间提供接口方式来实现业务和数据的沟通。让系统具有极强的扩展性。

◆基于组件技术，力求将变化封装在组件内部。对应组件可以对外提供API。

◆适应能力强，同步、异步都能处理，既能满足快速反映的业务的需求，又能满足大数据量、复杂的、异步的业务的需求。

◆与OS、中间件平台、数据库系统无关。

◆具有很好的可扩展性。模块化使得系统很容易在纵向和水平两个方向拓展：一方面可以将系统升级为更大、更有力的平台，同时也可以适当增加规模来增强系统的网络应用。在扩充或修改功能时，基本不会破坏原有结构的稳定性。

◆强而可靠的数据库搜索引擎

◆实用且安全的SEO搜索引擎设计

◆支持分布式部署的缓存引擎

系统的架构图

技术架构图

8

市场部文件

系统技术架构图

系统请求数据处理流程图

9

市场部文件

6.输出请求Controllerhtml调用PubActionAction(PubAction)ActionperformMethod3. 设置view中显示数据ViewStruts d到Jspjsp内部方法2. 操作数据库获取数据ModelBO(PubHibernate)5.调用方法UtilFormBean(PubForm)Model(PubBean)Cache(Memcache)HelperManager

体系结构图

10

市场部文件

体系结构图

系统核心功能分布图

11

市场部文件

架构层次的说明

数据库层

对于平台中的所有应用，都存在着各种各样的配置信息、业务数据、系统运行状态等信息。数据库层对这些数据信息本身进行归档，提供快速查询的底层接口，并保证数据的完整性、可靠性。

在数据库方面，我们的程序是可以无缝对接主流数据库的包括Oracle，Mysql，和MSSql，但建议采用Oracle或者是MySQL。因为他们和程序一样具备跨平台的特性，但这两种数据库分别有不同的适用环境。

Oracle

◆适合大型的电子商务应用。

12

市场部文件

◆能使用所有的商城平台功能。如访问量排行榜、降价排行榜、销售排行榜、访问量统计等等，就以往的经验来看，这些功能每天要处理的数据都会超过一千万。这种数据量如果使用传统的统计方法，统计一次的时间就可能会以天来计算了。如果使用Oracle，再配合我们专门对Oracle进行优化的高效率的统计程序，那么只需十数秒便可完成。

◆此外，如果只用一台数据库无法应付日益增长的服务器访问量，可以使用Oracle RAC（真正应用集群），通过增加数据库服务器进行集群。

MySQL

◆适合中小型的电子商务应用。

◆无法使用商城平台一些高级应用，如排行榜、统计分析、MIS系统对接等。这是由于MySQL设计上强调访问速度，牺牲了一些数据库的高级功能，虽然用程序也可以实现这些功能，但是在性能上无法满足需求。

◆比较难实现数据库集群。

中间件层

中间件层主要是购通平台使用的J2EE中间件，包括平台使用到的应用服务器和中间件技术。

一、应用服务器

应用服务器为购通提供的整个J2EE平台实现，商城系统基础服务层和应用层、业务层都是建立在应用服务器之上。

购通设计上遵循SUN公司提出的J2EE规范，这样能够尽可能的保证在不同的J2EE应用服务器中进行移植。

经过测试购通平台支持Tomcat、WebLogic、JBoss，webShare这几种J2EE应用服务器。

二、中间件技术

本着重用的设计原则，购通在一些功能中采用了已有的成熟技术，这些都是经过实践考验的中间件。主要以java标准包和开源项目为主，大部分都针对系统作了相应调整，以便适合系统的需要。

1. Apache commons：

著名的开源组织Apache的一个java工具包，提供很多实用的功能。

1) commons-beanutils：

提供对Java反射和自省API的包装。

在平台中用于通用的接口设计。

2) commons-codec：

包含一些通用的编码解码算法。Hex，Base64，以及URL encoder。

平台中主要用来做消息摘要，实现数据加密等功能。

3) commons-collections：

提供一个类包来扩展和增加标准的Java Collection框架。提供了比j2sdk更全面的数据结构，平台中继承并实现了一些特殊的数据结构。

4) commons-pool：

提供了通用对象池接口，一个用于创建模块化对象池的工具包，以及通常的对象池。

我们在原有的基础上进行了优化，在性能和使用性方面有所提高。

5) commons-dbcp：

这是一个基于apache的对象池（apache commons pool）实现的数据库连接池。

13

市场部文件

我们在原有的基础上进行了优化，对数据库连接进行了特别的处理，防止数据库连接泄漏的问题，并提供了监控的功能。

6) commons-discovery：

供工具来定位资源（包括类），通过使用各种模式来映射服务/引用名称和资源名称。

7) commons-el：

提供在JSP2.0规范中定义的EL表达式的解释器。

对平台中的JSP提供EL表达式支持。

8) commons-fileupload：

强大和高性能的文件上传功能。

平台中被用于上传各种图片、Flash、文档等资源，我们在原有的基础上进行了优化。

9) commons-logging：

提供通用的日志操作接口。

主要用于程序调试和服务器日常的日志输出。

10) commons-validator：

提供了一个简单的，可扩展的框架来在一个XML文件中定义校验器（校验方法）和校验规则。支持校验规则的和错误消息的国际化。

平台中用来校验各种xml数据。

2. Dom4j：

Dom4j是一个易用的、开源的库，用于XML，XPath和XSLT。它应用于Java平台，采用了Java集合框架并完全支持DOM，SAX和JAXP。

主要用来处理XML数据。

XML在商城有广泛的应用，主要是作为配置文件使用。由于XML严格的格式要求和层次结构，也有用来作为参数在HTML表单中传递。如组合商品功能，因为组合商品中的商品是由管理员挑选的，参数数量并不确定，如果每从组合商品中添加/删除一个商品都直接更新到数据库话，会对系统造成负荷。所以，在组合商品的管理中，将操作的数据类转换成XML传递，就可以一次进行修改。

3. Hibernate：

Hibernate是一个开放源代码的对象关系映射框架，它对JDBC进行了非常轻量级的对象封装，使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库。Hibernate可以应用在任何使用JDBC的场合，既可以在Java的客户端程序实用，也可以在Servlet/JSP的Web应用中使用，最具革命意义的是，Hibernate可以在应用EJB的J2EE架构中取代CMP，完成数据持久化的重任。

在平台中，我们采用Hibernate进行数据库操作，只有在一些对数据库性能有特别要求的模块，才直接使用jdbc进行连接。

he：

Memcache是一个支持分布式部署的动态缓存引擎。

定时器：

我们主要用Spring定时器管理以下一些定时任务：

1)年排行榜后台更新进程：自动计算年排行榜。

2)月排行榜后台更新进程：自动计算月排行榜。

3)周排行榜后台更新进程：自动计算周排行榜。

4)日排行榜后台更新进程：自动计算日排行榜。

5)更新对象缓存：实现对象缓存的更新，处理那些长期没被再一次访问的对象缓存。

14

市场部文件

6)清页面缓存：当管理员使用的手工刷新页面缓存的功能时，系统会将这些需要刷新的缓存加到一个队列中，由本进程负责刷新。

7)相关产品自动实现间隔：相关产品的计算对系统消耗比较大，所以系统不会对所有几十万个商品进行计算，只有在用户查看单个商品时算出这个商品的相关产品并进行缓存。那么当用户下一次访问这个商品的相关产品时就直接从缓存中读取出来。而这个进程就是为了定时更新这个缓存。

8)自动推荐后台更新进程：进程根据商品推荐规则进行自动推荐。

9)新闻推荐后台更新进程：进程根据新闻推荐规则进行自动推荐。

10)关键字后台进程：当用户在前台搜索栏中输入一个查询值时，系统并不马上将其统计到关键字，而是放到内存中，由此进程定时统计。

11)保存访问量信息进程：用户每访问一次系统，系统并不马上统计，而是放到内存中，由此进程定时保存到数据库，供统计进程进行统计。

12)年访问量排行计算：计算年访问量排行榜。

13)月访问量排行计算：计算月访问量排行榜。

14)周访问量排行计算：计算周访问量排行榜。

15)日访问量排行计算：计算日访问量排行榜。

16)年降价排行计算：计算年降价排行榜。

17)月降价排行计算：计算月降价排行榜。

18)周降价排行计算：计算周降价排行榜。

19)日降价排行计算：计算日降价排行榜。

20)统计计算：每天对访问量进行统计。

21)生成订阅邮件列表进程：根据用户的订阅设置，生成需要发送的邮件队列。

22)发送订阅邮件进程：根据要发送的邮件队列发送邮件。

23)拍卖自动出价进程：实现拍卖模块中的自动出价功能。

6. Log4j：

Log4j是Apache的一个开放源代码项目，通过使用Log4j，我们可以控制日志信息输送的目的地是控制台、文件、GUI组件、甚至是套接口服务器、NT的事件记录器、UNIX Syslog守护进程等；我们也可以控制每一条日志的输出格式；通过定义每一条日志信息的级别，我们能够更加细致地控制日志的生成过程。最令人感兴趣的就是，这些可以通过一个配置文件来灵活地进行配置，而不需要修改应用的代码。

这是一个可选包，如果不使用Log4j的话，commons-logging会自动使用SUN

J2SDK的日志包，不过我们还是推荐使用Log4j，它的功能非常强大。

s：

Compass是一个开放源程序的搜寻器引擎，利用它可以轻易地为Java软件加入全文搜寻功能。Compass的最主要工作是替文件的每一个字作索引，索引让搜寻的效率比传统的逐字比较大大提高，Compass提供一组解读，过滤，分析文件，编排和使用索引的API，它的强大之处除了高效和简单外，是最重要的是使使用者可以随时应自已需要自订其功能。

我们使用Compass建立索引，并在这基础上实现了全文搜索功能。

8. Ant：

Ant是一个基于Java的自动化脚本引擎，脚本格式为XML。

我们除了用Ant做Java编译相关任务外，还通过插件实现很多应用的调用。包括程序编译、打包、Hibernate配置文件自动生成、部署、以及单元测试等操作。

15

市场部文件

当一个代码项目大了以后，每次重新编译，打包，测试等都会变得非常复杂而且重复，因此c语言中有make脚本来帮助这些工作的批量完成。在Java中应用是平台无关性的，当然不会用平台相关的make脚本来完成这些批处理任务了，Ant本身就是这样一个流程脚本引擎，用于自动化调用程序完成项目的编译，打包，测试等。除了基于JAVA是平台无关的外，脚本的格式是基于XML的，比make脚本来说还要好维护一些。

9. Axis：

Axis是一个SOAP引擎，提供创建服务器端、客户端和网关SOAP操作的基本框架。SOAP是被广泛作为新一代跨平台、跨语言分布计算Web Services的重要部分。

商城平台使用Axis提供WebService支持，广泛应用于通用数据接口，对外系统提供服务等功能。

如：

1)商品查询服务：提供接口让外接系统可以查到平台中的商品信息。

2)新闻发布服务：提供接口让外接系统可以取到各类新闻。

3)订单服务：提供接口让外接系统可以在平台中生成订单，并获取各种订单信息。

注：上述服务都有严格的权限控制。

10. JavaMail：

JavaMail是Sun发布的用来处理email的API。它可以方便地执行一些常用的邮件传输。

我们使用JavaMail实现了平台中邮件发送、群发等相关功能，供业务系统使用。

11. JSTL：

JSP标准标记库（JSP Standard Tag Library，JSTL）是一个实现Web应用程序中常见的通用功能的定制标记库集，这些功能包括迭代和条件判断、数据管理格式化、XML操作以及数据库访问。

我们使用JSTL封装各种业务逻辑。

12. JUnit：

JUnit是由Erich Gamma和Kent Beck编写的一个回归测试框架（regression

testing framework）。Junit测试是程序员测试，即所谓白盒测试，因为程序员知道被测试的软件如何（How）完成功能和完成什么样（What）的功能。

我们主要用JUnit来进行单元测试。

基础服务层

基础服务层构建于J2EE平台之上，借助于中间件的接口服务，提供电子商务平台系统所需要的通用服务接口组件。系统将提供以下主要的服务接口支撑不同业务需求的实现。

◆栏目管理模块：

栏目是一个抽象资源对象，是一种特殊的内容类型。栏目可以表示产品、新闻信息类别、资源节点、导航栏的项、菜单中的项等等。栏目是一种组织管理型的资源。

系统设计上支持多级子栏目，采用虚拟文件系统（Virtual File System）技术以支持直观的树型导航风格，一个栏目节点相当于一个虚拟的文件目录。

对于大型电子商务系统，栏目的节点是个非常大的数字，这对系统栏目树展示的速度和性能有极高要求。考虑到以上原因系统采取了栏目对象缓存策略，同时对于页面节点的呈现通过动态JavaScript输出的技术，从而使系统能很好的支持上万个栏目数据节点操作管理。能平滑、高效的展示树型风格的栏目结构。

◆用户权限管理模块：

16

市场部文件

大型电子商务应用系统有用户多，模块多，权限多的特点，因此必须采用分组的用户管理系统，并设置一个具有最高权限的管理员，负责对整个系统用户设置，为每个用户角色、用户指定不同的权限，依照不同的权限在系统中可以使用不同的功能。

系统设置了Administrator用户组，并设置了root这个具有最高权限、不可删除的用户。您可以根据您的需要使用root这一个管理员用户。管理员可以创建、编辑和删除用户组，您可以根据您的需要给每个用户组合理的权限划分，并给每个用户组添加、编辑和删除用户。用户登录系统后，系统会根据该用户的权限提供相应的功能，并对用户的每个操作检查用户的使用权限。

系统采用Window用户权限的思想，将用户、用户组的权限通过各个栏目节点进行绑定，在各个栏目节点上实现继承与非继承的设置管理，从而使管理员可以进行灵活的配置。

◆属性管理模块：

在现实情况中，不同的事物对象存在其特殊的信息描述；比如一个手机，存在“网络类型—GSM”、“外观样式—翻盖”等等；同时这些特殊的信息描述在同类别的数据对象下经常存在共性；比如TCL和联想生产的手机，应该都存在以上两种属性的描述。

针对以上的情况，系统进行了一个数据抽象，定义了一套属性管理组件，可以方便、有效的描述相关的需求情况，同时对于存在共性描述的对象采用继承模式来描述，从而很好的表现一个事物对象的特征。

◆继承性管理模块：

继承是面向对象接口特性之一。考虑到抽象事物的通用性，系统通过一个通用的对象继承模型接口，对所有需要实现继承的功能提供基础的支持。从而提高系统的重用性和降低系统的偶合度。

◆日志服务管理模块：

日志是一个成熟的电子商务应用系统所必备的功能。日志可以用于数据统计，为系统其他功能提供初始数据；用于查看一个对象的修改历史记录，用于方便追踪对象的修改状态和明确事务责任。

通过对系统各种操作数据的分析，根据各操作功能，系统将日志进行类别的划分：

1、系统日志：记录系统各种操作的信息数据。（比如：用户某个时间登陆了系统……）

2、商品日志：记录系统商品数据发生改变的信息。（比如：商品价格发生变化）

3、信息日志：记录系统信息数据发生改变的信息。（比如：某管理员增加了一个新的促销公告……）

4、订单日志：记录系统订单数据发生改变的信息。（比如：某个订单已经进行了送货处理……）

系统通过抽象出一个Log日志接口，采用Abstract Factory模式，通过不同的构造参数来获取不同分类的Log日志实现。系统将各中类别下的日志，又区分不同的操作。日志组件将通过抽象和封装后，给各功能模块提供统一接口服务，方便系统各模块的日志功能的开发和维护。

◆缓存服务管理模块：

页面访问的时候，生成动态Web页会耗用各种各样的系统资源。当Web服务器收到页面请求时，它通常必须从数据库或其他存储系统中实时的检索所请求的信息。对这些资源的访问通常需要通过有限的资源池（如数据库连接、套接字或文件描述符）进行。因为Web服务器通常需要处理很多并发请求，所以对这些 17

市场部文件

共享资源的争夺可能会延迟页面请求，直到资源变为可用。在将请求发送后，仍然必须将结果转换为HTML代码以便进行显示。

使系统速度更快的一种显而易见的方法是购买更多、配置更好的硬件。此方法可能很吸引人，因为硬件便宜，而且不必更改程序，但更多的硬件只能在未达到其物理限制之前才会对性能有所帮助。系统中实施缓存管理，是一个有效的解决方案。

系统中存在两中缓存对象：

1、Java对象缓存：对于一些经常被使用的Java对象保存于规定的内存空间，通过配置的更新规则，同步更新数据库内容。

2、前台页面缓存：对于前台的html页面按不同的块来区分，然后通过一个key对象，通过开源JCS技术存储于内存或磁盘空间。

（请求中的页面对象不在缓存对象中）

18

市场部文件

（请求中的页面对象存在于缓存对象中）

从上边两幅图可以很清晰的看到，对于并发访问的页面请求，通过页面的缓存可以极大的减少对紧缺资源（数据库连接）的调用，减少访问响应的时间，从而提高系统的访问速度和整体性能。

2上传文件的共享

我们采用共性文件形式的文件共享，主要使用磁盘阵列技术，简称RAID(Redundant Arrays of Inexpensive Disks)。磁盘阵列是由一个硬盘控制器来控制多个硬盘的相互连接，使多个硬盘的读写同步，减少错误，增加效率和可靠度的技术。

磁盘阵列有以下优点：

1）传输速率快；

2）储存容量可提升；

3）提升I/O每秒的数量；

4）增加数据安全性及稳定性；

5）大量数据快速及简易管理；

6）增加可用运时间，减少维护；

7）通过磁盘阵列，可以将不同服务器上传的文件统一管理。

图所示：各台服务器共享磁盘阵列，这样所有的上传的文档都放到磁盘阵列之中。

3.高可用性

如 我们建议采用负载平衡器，负载均衡器可以根据实际的响应时间制定优先级交付决策，从而实现高性能、智能化流量管理，达到最佳的服务器群性能。采用第 19

市场部文件

七层应用控制还可以减少通信高峰期的错误讯息，因为差错控制和流量管理技术可以侦测到一些错误信息，并透明地将会话重定向到另一个服务器，使用户顺利地进行使用。例如，服务器A不可用或者数据库出现错误，错误信息将会返回到负载均衡器上，然后会将客户的访问指向服务器B或者将消息重放到其他数据库中去，整个过程对用户是透明的。

将内部的多个私有ＩＰ的服务器，对外映射成一个相同的IP。而且当其中某台服务器Down掉的时候，负载均衡器将不会将这个服务器映射出去。

6.数据库集群

如果数据库是用Oracle的话，数据库集群可以采用Oracle RAC。基于RAC的电子商务应用的用户或者中间层应用服务器客户，可以通过虚拟数据库服务名连接到数据库上。Oracle在集群中多个节点之间自动平衡用户负载。不同节点上的Real Application Clusters数据库实例预订所有数据库服务或者部分子集数据库服务。这使得DBA高度灵活地选定，连接到特定数据库服务的特定应用程序客户是否可以连接到某些或者全部的数据库节点。RAC在工作期间，每个节点可以单独的被使用并且被应用程序负载均衡。如果发生意外，如一个节点的失败，可以实现节点的失败切换，保证数据库24*7的高可用性。

虽然每一个节点有一个不同的物理IP地址时，应用客户仍可以在一个逻辑数据库服务名的水平上进行连接。因此客户端对于不相关的事情如多服务器的多个地址可以毫不关心。

◆任务调度模块：

对于电子大型的成熟的电子商务平台系统，每天都有很多特定的数据需要进行分析或处理（比如：每天都有大量的邮件需要发送）。对于大数据量、高数据运算的处理功能，往往不希望在系统繁忙的时间进行处理。

针对这种状况，系统采用Spring定时器提供的基础服务，通过Spring定时器接口的扩展，实现对系统自动执行的任务灵活的、人性化的配置。管理员可以根据系统的实际情况，配置相应的系统任务来执行。

应用层

20

市场部文件

应用层提供各种业务实体的操作，使用商城平台基础服务进行搭建。

应用层的基本设计都是建立在商城平台基础服务层之上。就是栏目——属性/权限——业务实体。所有业务都可以在栏目中统一管理，从而使用统一的权限配置，使用分层的动态属性这些基础功能。

这样做的好处是，当业务实体发生改变或者是有新的业务时，系统的基础架构都不需要做出任何调整，直接就可以使用原有的功能。比如说订单系统，订单系统可以处理的就是一个业务实体，如果平台现在要加上网上购买服务的功能，那么只需要新加一个订单类型，就可以好像处理一般的商品订单那样处理这种购买服务的订单。

一商品管理

二订单系统

三评论管理

四内容管理

五会员管理

六促销管理

七统计报表

八推广渠道

九商户管理

十系统管理

十一客服系统

业务表现层和系统接口层

业务表现层

业务表现层就是商城最终对客户的接口，平台以网页的方式提供各种业务供客户使用。相当于View（视图），与应用层（Model）、Servlet（Controller）组成Model

/ View / Controller（MVC)结构。

系统接口层

系统接口层是商城对外部系统的接口。提供各种数据导入导出，数据查询等功能。

商城平台主要使用WebService提供系统接口。

实际上，Web Service的主要目标是跨平台的可互操作性。为了达到这一目标，Web Service完全基于XML（可扩展标记语言）、XSD（XML Schema）等独立于平台、独立于软件供应商的标准，是创建可互操作的、分布式应用程序的新平台。使用Web Service有以下优点：

1.跨防火墙的通信

出于安全性考虑，服务器通常只对公网开放80（HTTP）端口，WebService使用Http协议进行传输，正好能自由穿越防火墙。

2.应用程序集成

在企业中会有其他的应用程序，比如说MIS、CRM等，这些应用可能是建立在不同的平台之上，比如说.Net。那么商城和这些平台集成的话就会存在很大的问题，因为我们采用的是J2EE。解决这应用程序集成的最佳方案就是WebService了。通过Web Service，应用程序可以用标准的方法把功能和数据“暴露”出来，供其它应用程序使用。

3. B2B的集成

同样的，将上面的一个问题扩充到企业和企业之间，跨公司的商务交易集成通常叫做B2B集成。不同企业所采用的平台就更加五花八门了。

21

市场部文件

Web Service是B2B集成成功的关键。通过Web Service，公司可以把关键的商务应用“暴露”给指定的供应商和客户。

用Web Service来实现B2B集成的最大好处在于可以轻易实现互操作性。只要把商务逻辑“暴露”出来，成为Web Service，就可以让任何指定的合作伙伴调用这些商务逻辑，而不管他们的系统在什么平台上运行，使用什么开发语言。这样就大大减少了花在B2B集成上的时间和成本。

4.软件和数据重用

软件重用是一个很大的主题，重用的形式很多，重用的程度有大有小。最基本的形式是源代码模块或者类一级的重用，另一种形式是二进制形式的组件重用。Web Service在允许重用代码的同时，还可以重用代码背后的数据。

系统部署环境

商城平台部署环境

运行平台

JDK1.5.12以上所有版本

操作系统

支持所有系统

建议采用LinuxAS4或Linux AS5操作系统。

应用服务器

Tomcat5.0.28以上或JBOSS4.2

Web服务器

Nginx或Apache

数据库服务器

Oracle9i以上

缓存服务器

缓存服务器部署Memcache服务

图片文件服务器

用Nginx发布

系统部署拓扑图

22

市场部文件

系统部署结构图

23

市场部文件

（二）

1.1. 系统技术架构

1.1.1. 总体架构

广东网通BSS系统重构项目的主要技术目标包括提高应用系统的可重用性和流程的可配置性，以解决在业务快速变化的市场环境下，如何保证业务支撑软件及时交付高质量的软件版本，同时尽量降低业务软件的重复性开发工作量。

为了满足日益复杂的业务需求，确保能够在第一时间里推出市场所需的服务、并且业务支撑系统的改动量最小，我们建议在系统中采用SOA架构。

SOA是从企业的需求开始，把IT系统和商业流程连合在一起，以服务集成形式实现新的而又灵活的应用功能。SOA简化了IT，让IT变得更有弹性，以便更好地发展和优化业务流程，从而促进企业与合作伙伴的业务需要，也使供应商和客户之间动作流程的端到端整合，让企业可以快速灵敏地响应客户和市场不断变化的需求。

SOA能够加强对整个企业架构的控制能力；并且由于具有高级别的重用性，有助于提升开发效率，加快开发速度；采用只需少量改动的核心企业级IT应用，让运营企业和厂商只需优化基于标准技术的IT技能，从而降低了在客户化和人员技能方面的投入，从而节约了成本。

以SOA在基础，结合功能和非功能性需求的考虑，我们对广东网通BSS系统给出如下的系统架构：

24

市场部文件

在系统架构中，不同的功能可以被分为纵横几个不同的层次，基于底部的是服务的提供者，上面则是服务的消费者：

● 资源层

指系统已经存在的程序资源，例如网元操作平台、银行系统等外部系统，以及BSS系统自身的数据等。

● 组件层

在这一层中用不同的组件把底层系统的资源封装起来。

● 服务层

在这层中用底层功能组件来构建所需要的不同功能的服务。

● 商业流程层

在服务层之上为商业流程层，在这一层中我们利用已经封装好的各种服务来构建 25

市场部文件

商业系统中的商业流程。流程是可以组合的，一个流程可以作为另一个流程的子流程使用，更好地提供了流程的重用性及灵活性。

纵向贯穿系统的是集成架构和基础架构，集成架构的核心为企业服务总线（ESB）；而基础架构则为整个 SOA 系统提供一些辅助的功能，例如服务质量管理，安全管理这一类的辅助功能。

将体系架构映射到J2EE的技术平台上面，可以得出如下的模型：

26

市场部文件

这是一个扩展的J2EE架构实现，表示层的内容可以运行在WEB容器之上，商业流程、服务层、组件层的内容则会运行在EJB容器之上，基础架构的安全，管理及监控也会实现成EJB容器之上的服务，而一般来说，现有的应用服务器都可以提供企业服务总线的功能。

这个实现除了支持Web应用之外，还支持J2EE的远程客户，具有远程EJB的分布式应用，以及其它类型的客户端。该体系结构在WEB层（或者是其他远程客户）与业务对象之间使用RMI，WEB层通过业务接口和业务委托来远程访问业务逻辑会话EJB，业务逻辑处理数据，然后业务逻辑会话EJB通过DAO访问数据存储，也就是把数据持久化。这种架构的最大好处是通过一个中间层来支持所有的J2EE客户类型；还允许各种构件在不同的物理服务器上分布；这样给应用实现最大的可伸缩性，EJB容器为远程客户提供一个综合性接口。

1.1.2. 表示层——Web界面及Web服务接口

这一层用来与用户交互，并把来自系统的信息显示给用户。J2EE使用JSP/Servlet技术支完成这一层的任务。这里，我们引入JSF、JSP标准标记库和AJAX技术，应用框架采用改进过的Struts2。

Web服务接口标准（比如SOAP）不再要求使用RMI和EJB来支持远程客户，从而使客户的远程访问不必使用EJB接口。传统的Web服务接口运行在同一个Web容器中。使用SOAP基于XML，并且是自描述的，这样的服务标准具有跨平台性，支持J2EE客户之外的客户，比如日后的电话语音订货系统与互联网系统等应用。Web服务传输协议运行在HTTP上面。

1.1.3. 接入服务——统一接入平台

对于其它类型的客户端，BSS系统构建统一接入平台，为其提供服务。建统一接入平台包含了接口连接管理、接口逻辑管理和接口服务三部分：

● 接口连接管理：提供接口接入处理完整的管理功能，在接口连接管理中包含了传输管理、通讯服务、负载均衡、动态配置管理、网络调度等功能；

● 接口逻辑管理：提供了和接口业务相关的数据管理、优先级管理、交换分发和完整性管理等功能；

● 接口服务：是对BSS系统服务层提供的商业流程封装后提供给对端系统的相应服务，以阻断对端系统和业务层的直接通讯，同时安全 27

市场部文件

高效的支持外围接入服务。

1.1.4. 表示层——业务接口

业务对象对外暴露为EJB，在Web组件层与业务对象之间使用RMI（远程方法调用，当然，远程方法调用的通信细节由容器来实现并隐藏），为了减少远程调用的性能开销，系统架构采用常用的设计模式—业务接口和接口实现—业务委托来处理对远程EJB的访问。另一方面，由于EJB对象的查找及实例化是相当消耗系统资源的，业务接口可以缓存EJB对象的远程句柄，这样节省了查找和实例化的时间，从而提高系统的性能。

1.1.5. 逻辑层——业务逻辑EJB

这一层处理应用的核心业务逻辑。所有的业务组件都实现为EJB容器内的Stateless Session Bean组件。EJB容器提供了业务组件生命周期管理、多线程调度、同步处理、事务管理和资源分配等，这样业务组件只需要专注于业务需求的实现即可。由于业务逻辑都集中在EJB组件实现，而客户端只用来与用户的交互，这样保证了业务逻辑的统一。

如上所述，J2EE结构中的逻辑层，对应于我们系统架构中组件模型的组件层、服务层及流程层，也就是说，我们将使用EJB去实现组件、服务及流程。

首先，我们使用EJB去封装后台数据库的数据对象（通过DAO去访问数据库），由于系统涉及到多个数据库，这样可以使上层的应用忽略了数据的来源，并且提供了基本的事务功能。

在封装数据对象之后，我们同样使用EJB去实现一些基本的服务功能，这些EJB的粒度将会比较细，只完成单一的功能，如客户资料查询等。

最后，我们再使用EJB，将细粒度的服务组件按商业流程连合在一起，完成更完整的流程。在设计的理念上，流程是可以组合的，一个流程可以作为另一个流程的子流程使用，更好地提供了流程的重用性及灵活性。甚至在发展到一定的程度后，可以引入工作流引擎，如BPEL，通过描述的方式去定义一个工作流程，从而使整个商业过程灵活可配置，面向业务人员。

1.1.6. 逻辑层——规则引擎

使用规则引擎（如：ILOG），可以在原有的业务逻辑层中抽取出业务规则层，一方面实现应用逻辑与业务逻辑松散耦合，使系统能够在用户期望的时间规定内完成业务需求功能；另一方面从体系架构上保证业务规则层能够在BSS系统的各个 28

市场部文件

功能模块中具备业务编辑配置能力。

规则管理系统功能主要包括一下模块:

1.

规则的设计与编辑模块

2.

规则调试分析模块

3.

规则管理模块

4.

规则执行模块

如下图所示，

使用ILOG规则引擎，可以较大程度的提高系统的灵活性，不过，使用ILOG规则引擎也会导致程序性能有一定成都下降，这是因为程序每次执行前都需要访问规则库，并进行规则比较。另外，使用ILOG规则引擎也会在一定程度上增加操作复杂性，这是因为要进行规则配置。

因此，ILOG建议应用在规则变动较频繁，而且可以通过灵活配置而不修改程序可以实现的模块。

ILOG建议应用在规则变动较频繁，而且可以通过灵活配置而不修改程序可以实现的模块。

1.1.7. 商业流程——工作流引擎

29

市场部文件

流程做为SOA世界中重要的概念，有个方面的问题可以关注，一是业务流程的建模，是指使用流程进行建模反应业务需求。二是工作流的应用，其实工作流是前者的一个子集，强调人机交互，人工干预流程(通常是长流程)。而业务流程中是可以没有人工干预的，其中一种观点就是，将商业逻辑用规则引擎管理，这样人干预的节点越少，做为企业来讲，流程的效率越高，从中获取的商业利益也越大。

在这个领域，工作流管理的概念在前，其标准WFMC也经历了很长时间，但一直没有得到很好的应用和推广。

而是近几年随着SOA概念的推广，OASIS的BPEL越来越多的被关注，现在版本是2。0。BPEL的全称是WS-BPEL。这个标准是基于WebService的。

所采用的引擎是否一定要实现某某规范和标准值得探讨，因为当前流程这方面的标准规范存在的太多，也没有一个强势的标准(最强势的现在来看也是bpel了)。但从功能上，流程引擎(或者扩展后的流程系统)需要支持下面几种要求：

✓

图形化的流程定义。能够

✓ API灵活易用。流程容易开发。

✓ 清晰的流程概念和运作方式，一定要具有人机交互能力。(角色，权限相关联)

✓

支持流程的热部署。

✓ 提供灵活的扩展方式，良好的和外部系统/模块的交互能力(本地代码交互和分布式的系统的交互)。如果做为模块，能够易集成。

✓

完备的文档及其他可寻求的帮助方式

以上几点依次从流程分析定义，流程开发，流程部署，流程运行期和外部的交互，如何集成等几个方面进行考虑。

大概比较一下基于BPEL的引擎和JBPM

●

BPEL

优势

✓

✓

✓

✓

劣势

符合最流行的流程标准规范。

适于大规模编程，集成特性好。

良好的图形设计工具。

是SOA重要的组成部分。

✓ 比较复杂，或者说很复杂。需要非常了解BPEL标准。(如何利用bpel设计流程)

✓ 一定要熟悉webservice的开发和其相关的标准。

注意:以上两项如果有现成的封装并且团队中已经有人熟悉问题也不大。

30

市场部文件

✓ 依赖特定引擎实现本地代码交互。

✓

依赖于特定的引擎实现人机交互。

●

JBMP

优势

✓

简单易用的编程模型。做为模块容易集成。也可设计成子系统。

其概念模型也很清晰。

✓

✓

✓

✓

良好的基于eclipse的图形设计工具。(易用性强)

很灵活。可以方便的测试流程设计(脱离数据库运行)。

易于扩展。

内部已有比较好的研究。相关社区比较活跃。

劣势

✓ 不是标准(jbpm有一个子项目支持bpel)

✓ 在大规模集成方面不如BEPL相关实现。

无论是采用哪种实现方式，最好都能了解流程设计的pattern，process design

pattern是流程设计中常用的一些场景，可做为原子组合成复杂的场景。对日后快速建模提供相应支持。

1.1.8. 资源层——DAO

这一组件用于处理存贮系统的数据。业务组件通过调用DAO组件实现对数据库的操作。DAO实现了用来操作数据源的访问机制。数据源可以时RDBMS，LDAP，File等。依赖于DAO的业务组件为其客户端使用DAO提供更简单的接口。DAO完全向客户端隐藏了数据源实现细节。由于当低层数据源实现变化时，DAO向客户端提供的接口不会变化，所有该模式允许DAO调整到不同的存储模式，而不会影响其客户端或者业务组件。重要的是，DAO充当组件和数据源之间的适配器。

使用数据访问服务层之后，BSS系统实现了几个重要的效果：

●

透明性

业务对象可以是使用数据源，而无须了解该数据源实现的具体细节。访问是透明 31

市场部文件

的，原因是实现被隐藏在DAO的内部。

●

更容易的迁移

DAO层使应用程序更加容易地迁移到一个不同的数据库实现。业务对象不了解低层数据实现。因而，该迁移只涉及对DAO层的变化。更进一步说，如果使用工厂策略，则有可能为每一个低层存储实现提供一个具体工厂实现。在这种情况下，迁移到不同的迁移实现意味着给应用程序提供一个新的工厂实现。

●

减少业务对象中代码复杂度

由于DAO管理所有的数据访问复杂性，它可以简化业务对象和其他使用DAO的客户端中的代码。所有与实现有关的代码(比如sql语句)都被包含在DAO中，而不是包含在业务对象中。这样做提高了代码的可读性，已经代码生产效率。

●

把所有的数据访问集中到一个独立的层。

因为所有的数据访问操作现在被委托给DAO,所有单独的数据访问层可以被看作把数据访问实现与应用程序中的其他代码相隔离的。这种集中化使应用程序更容易地维护和管理。

这里，我们使用了一个第三方的LIB——Hibernate。Hibernate相对于Entity Bean来说，性能高了不少。还有一点的是，Hibernate将会是EJB 3.0的CMP底层实现机制，那意味着Hibernate是一个很好的产品，并且会发展下去。

1.1.9. 资源层——外部后台系统接口

外部后台系统接口负责管理与外部后台系统的连接，访问外部系统数据，调用外部系统的功能。外部系统接口组件提炼、封装了对外部系统的访问，向使用者——业务逻辑组件，提供统一的API，那么，一方面将外部系统的访问细节，如系统登录、语法语意的转换、日志记录等，完全隐藏起来，使得业务逻辑组件有一个很简单的调用；另一方面，外部系统的改动将不会影响到本系统的业务逻辑，只需要适当修改外部系统接口组件就可以了，从而降低外部系统和核心业务组件的耦合。

32