银行电商平台技术解决方案

1 产品技术方案

1.1 技术方案概述
1.1.1 系统功能架构
  在银行电商平台中，包括各总分支行的管理人员、各家合作商户、会员、物流公司、支付平台等主要角色，通过电商平台进行信息流、资金流的交互，并借助物流公司提供的物流服务，来完电商平台的购物活动。
  电商平台从功能架构上来说，可以用如下的功能架构示意图表示：

1.1.2 系统技术架构

  上图可以清晰的了解到整个系统的层次划分，系统从最底部的EIS层（图中为数据库、分布式缓存系统、其他与电子商务交互的系统）开始，经由业务逻辑层（基础组件、产品组件、客户化组件）一层一层的向上提供接口服务，最终实现按业务要求的操作界面和其他系统接口。各层次专注于自身功能的接口实现，整个层次保持相对的稳定。系统各组件之间保持接口稳定性，可在各个层次、各个组件内部进行优化的策略，在不影响整个业务的前提下，不断的完善和改进。

1.2 技术方案设计原则
1.2.1 投资保护性原则
  银行B2C商城技术方案充分考虑目前已实施的业务系统的实际情况，充分利用原系统资源，在实现新系统建设同时保护原有系统的投资。
  任何一个系统的建设，如果不能合理和有效地利用以前的投资，这样的系统应该算不了成功或绝对的成功。因此，在进行该系统建设时，充分考虑如何利用以前的信息系统、网络和其他设备，并对以前实施的应用系统进行整合，一方面保证原有的设备可以重新利用，另一方面保证以前的应用重获新生。在真正意义上做到既完成了新系统的建设又保护了原有设备和系统的投资。

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

1.2.3 先进性原则
  由于IT技术发展的速度惊人，在电子商务项目进行系统总体规划时，我们选择业界到目前为止最为先进和成熟的技术作为整个系统的技术架构，以保证系统有不断发展和扩充的余地。 系统总体设计的先进性原则主要体现在以下几个方面：
  平台的分层架构，本着各层次之间松耦合，各层次内部高内聚的设计原则，使得平台具有良好的扩展性和可移植性。
  平台的设计中利用先进的面向对象技术、设计模式和可插入组件技术来提高软件的通用性、复用性和扩展性。

1.3 技术方案组件
  平台核心组件和应用组件如下图所示：

  下面我们将逐一介绍技术平台的基础技术组件和产品的核心业务组件。

1.3.1 搜索引擎组件
  在电商平台中，商品搜索服务占有举足轻重的位置，直接影响客户购物体验，产品提供了专业的商品搜索服务引擎，支持多维搜索。
  搜索可以按照各种方式进行排序：按产品最终提供者,按产品类别,按产品期限,按产品风险级别（金融类产品）等。
  支持搜索过滤：按产品最终提供者,按产品类别,按产品期限,按产品风险级别。
  支持分面搜索，客户根据自己的需要选取不同的分面（如：商品品牌, 商品类别, 商品价格）进行筛选；构建自己的搜索路径，并且可以随时扩大和缩小结果范围；避免了无搜索结果的情况，在搜索选项内包含的结果数量，给用户良好的操作前提示，增加用户体验。
  搜索支持关键字模糊匹配和智能提示，支持组合关键词搜索。
向客户推荐搜索最多的商品，关注最多的商品，购买最多的商品等，为客户消费购物决策提供支持。
  平台支持中文全文检索，支持主流格式文档（PDF、WORD、HTML等）。
  支持分面搜索，基于标准的开放接口，高速建立索引，高性能搜索，支持分布式搜索，处理海量数据 ，易管理。
  多种文档格式：
     Plain text
     Rich Text Format
     XML
     HTML
     Microsoft Word / Excel / Powerpoint
     Adobe PDF
  特性：
   给特定的自定义结构内容置顶索引,可以自定义搜索的Field,进行定义和配置。
   集成了 snowball stemmer 包,可以对多种拉丁语进行分词。
   可以对生成的内容片断进行关键词高亮显示。
   提供商品比价功能：通过授权后对第三方电子商务网站进行爬虫，根据设定的分类、品牌、名字设定权重进行页面分析，然后再调用搜索引擎创建索引。

1.3.2 工作流引擎组件
  在电子商务平台中，涉及到多种业务流程的管理，如商品发布流程、资讯/公告等信息发布流程等。在产品中，这些业务流程都纳入到统一的电子商务工作流引擎中进行统一管理。工作流引擎提供工作流的配置定义功能，使得工作流程可依据银行电商平台的需求进行灵活的定义。

  在工作流引擎的使用中首先需要业务人员定义好业务流程（如：vsd格式的流程图），再由技术人员通过流程设计器设计出相应的流程定义文件（.bpmn20.xml），及生成对应的流程定义图片(.jpg)。
  在工作流引擎的内部实例对象中，一个流程实例（InstProcess）由一个流程实例变量（InstProcessVariable）、1个或多个活动实例（InstActivity）、1个或多个转移实例（InstTransition）组成，而一个活动实例包括一个活动实例变量（InstActivityVariable）和1个或多个工作项实例（Workitem）组成。
  启动工作流引擎，成功部署流程定义文件，由操作人员触发并启动流程，此时一个流程定义的实例便以生成，流程启动需将启动流程的操作人员（Initiator）放入流程实例中，该变量在流程中的任何环节都可获取，直至流程结束后才失效；流程启动也可将业务数据、角色等信息存放在流程变量中（Map）。
  在流程实例中任务主要分为用户任务（UserTask）和服务任务（ServiceTask），二者主要责任为：用户任务需要操作员参与才可完成，主要包括4种状态：未签收、办理中、运行中、已完成；服务任务则无需人工参与，当流程走到该节点时由引擎调用业务系统的服务组件完成任务。
  工作流引擎存储库（Repository）:存放流程定义、流程的资源（图片、规则等）。
  工作流引擎运行库（Runtime）:这个运行时的库存储着流程变量、用户任务、变量、作业等内的运行时的数据，运行时的库存储流程实例执行期间的运行时数据，当流程实例结束时，将删除这些记录。这就保持了这些运行时库小且快。
  工作流引擎历史库（History）: 包含着历史的相关数据，如：结束的流程实例、变量、任务、等等。
  工作流引擎的历史归档级别分为四种：None、Acitivity、Audit、Full；

1.3.3 规则引擎组件
  在电商平台的设计实现上需要设计应用很多规则，譬如：商品费率折扣规则、商品组合设置的规则、商品各类排行榜规则等。这些规则在整个运营过程中需要进行动态的调整、设置。
  在银行产品中，以上这些规则的定义和执行都通过规则引擎来执行，规则引擎包含了规则的定义和规则的计算执行两部分内容：
  在银行产品中的规则引擎有以下特点：
     规则参数可配置
     支持预定义的规则模板
     支持基于脚本语言定义的规则定义（可支持二次开发）
电商平台运营管理人员可以通过运营中心提供的配置界面，进行规则的可视化配置。下图是规则引擎的结构示意：

1.3.4 调度引擎组件
  调度引擎主要实现定时任务的自动调度，在电商平台中主要完成批处理任务、定时任务的调度执行如：生成清算报表、日终对账等任务。下图是调度引擎组件的示意图：

  任务调度引擎将任务的定义与任务的调度相分离。调度引擎支持独立的应用部署，可以支持大任务量并发处理。任务的定义支持配置文件方式和数据库方式存储。
  产品的调度服务引擎的结构设计图如下所示：

  由上图可看到，计划任务模块由Schedule Manager统一对任务进行调度，而任务大致分为简单周期（simple）任务和复杂周期（cron）任务。其中复杂周期任务又可能需要辅助有工作日定义。
  定时服务组件主要有以下4个模块组成：
  Schedule Manager
  是整个计划任务的管理员角色，以EMP服务(Service)形式根据外部XML配置对一系列任务进行安排和调度。实质上是一个接口，在其之上采用JDK Timer、commonj、Quartz等具体方式进行实现。
  简单周期任务（simple）
  按照一定周期反复执行任务，可设定周期、延时、重复次数等。
  复杂周期任务（cron）
  在每月、每周或每天的某个时刻执行任务，可设定条件、工作日等。并可根据工作日服务过滤或增加工作日管理。
  常用任务实现
  执行一个类或一个ActionProcess等产品常用任务的实现。
  执行一个类是指可调用任意一个java类中的方法来完成一个任务。
  执行一个ActionProcess是调用一个产品中的业务逻辑处理对象。

1.3.5 内容管理组件
  在电商平台中包括商品管理、营销活动管理、广告等管理等业务都需要涉及内容的制作和发布管理，在产品中，通过内容管理组件实现对电商平台的内容制作和发布管理。
  内容管理基于强大的Velocity作为模板引擎， 把内容（Content）的制作和内容的的展现形式（网页）彻底分离开来。网页的展现表现形式及内容组织方式由模板文件来确定，网页的内容则存储于数据库中。这样的分离方式所带来的好处是很明显的，页面的展现形式可以变的更加灵活，而网站内容可以得到重复的利用，这样将大大降低了电商平台的的运维成本。这样即便网上商城需要对界面改版或升级，也不需要重新构建已有的数据。

  另外通过发布管理，可以轻松将你的网站从内容管理服务器发布到WEB服务器。基本的功能包括：
   支持静态文件发布模式，自动将内容数据通过静态文件进行保存发布到服务器上，减少访问对服务器的压力。
   支持多任务发布；
   一个站点发布到多台服务器；
   发布方式设置（FTP/COPY）；
   不同站点的不同发布任务；
   发布条件过滤；

1.3.6 社会化网络服务组件
   社会化网络是一个可以展示自我（Indentity），维持和拓展人际圈子（relationships），并且有很多事情（activity）可以做的网络服务。社会化网络服务广义上涵盖了博客、微博、WIKI等功能。社会化网络服务组件给电子商务平台客户提供了一个可以展示自我，维持和拓展人际关系的平台，可以起到增加电子商务网站的粘性和推广网站的知名度的作用。社会化网络涵盖了关系、互动机制、用户需求三方面内容，如下图所示：
   如下图所示：社会化网络服务组件设计为核心和非核心两部分，核心部分涉及到个人数据存储、好友关系、好友动态以及包括即时通信等在内的一些通用功能；非核心部分涉及到圈子、群组、论坛、App应用以及开放平台等需要具体定制实现的功能。

  社会化网络服务组件基于通用的推拉结合的方式实现，即好友动态以推送的方式发布给所有关注的人（主体），如下图所示：

                     推拉模式之推
  客户（主体）以拉的方式可以主动查看所有好友的动态，如下图所示：

1.3.7 数据集成/交互/报文处理引擎组件
  在电商平台设计实现上，可能需要对多个外围系统（支付网关、短信平台等）系统进行数据通讯和交易的请求处理，i2Shopping产品基于i2FSP平台提供的多种外围系统的交易适配器，根据不同的交易请求，在交易引擎中定制业务逻辑应该访问的一组后台交易适配器，完成一次系统间的请求交互。

  后台交易适配器包含两部分：交易报文格式化/解析和通讯协议适配器，在产品包中提供了支持多种常用通讯协议的通讯协议适配器。对于交易报文的格式化/解析组件，在产品包中包含了多种标准报文协议的支持，如：定长，XML,JSON,ISO8583报文等。交易适配器封装了对外围系统交易的请求处理。

1.3.8 权限管理组件
  技术平台提供出色的权限管理功能，通过管理角色的添加、权限的设置、权限的继承功能与后台管理人员、后台管理功能结合在一起。权限管理达到了配置灵活，又安全可靠目的，对于全行级别的电子商务平台而言，可以按照总分支行来划分岗位和角色。从控制力度来看，可以将权限管理分为两大类：功能级权限管理和数据级权限管理。技术平台通过不同手段来实现这两类权限管理：
  功能级权限管理技术实现
  技术平台功能权限管理，使用基于角色访问控制技术RBAC（Role Based Access Control），该技术模型如下图示：

  数据级权限管理技术实现
  数据级权限管理涉及到如何给不同的人分配不同的查询数据权限、如何给不同的人分配不同的数据操作权限的问题，i2FSP技术平台通过规则引擎配置来实现数据级权限管理和业务的松耦合。例如：领导查询数据范围和普通员工查询的数据范围不同，客户经理能够查询客户联系方式字段，而其他人不能查看客户联系方式字段等等。

1.3.9 异常处理组件
  技术平台提供了统一的异常处理组件，该模块以面向切面（AOP）的方式植入至系统的应用处理的各个环节，实现了异常处理与业务处理的分离。通过统一的异常处理机制，确保了系统中所有的异常信息均能够被捕获，并根据业务以及审计的需要进行相应的记录和处理。
  异常处理模块对于捕获的异常，通常采用信息记录的方式记录至相应的存储结构中（比如日志文件、数据库表等），平台提供了灵活的异常处理配置，可以在运行时调整异常处理的策略，比如异常信息记录的级别，异常处理的方式等。
  异常处理处理组件如下图所示：

1.3.10 审计日志组件
  审计日志主要用来跟踪功能操作的主体，客体，发生的时间，并定期产生审计报表。平台以面向切面的方式插入到各个业务功能中。通过配置文件或者数据库的方式定义需要审计的功能和要素，通过暴露接口给各个业务功能，由该业务功能实现者产生审计日志的数据并配置审计日志的切面连接点，当业务功能被执行时由审计日志组件产生审计日志时间，相应的审计日志监听器会接收到该时间，并将该事件持久化到数据库中。
  技术平台采用面向切面的设计思想和异步处理的机制，审计日志的处理和业务功能实现了松耦合和并发处理。如下图所示：

1.3.11 缓存组件
  对于对于数据密集型的B2C电子商务类应用，缓存组件可以极大提高系统的吞吐量并减少请求响应时间。技术平台的缓存组件由是本地的Java的分布式缓存和远地的Memecached集中式缓存结合而成。对于只读类型的数据，例如系统中的类似省份城市的相对稳定的数据，产品采用基于Java的本地缓存，具有快速、简单、多种缓存策略（FIFO、LRU、LFU）的特性，通过配置的方式针对接口的方法调用实现内存、硬盘的二级缓存机制，无需考虑担心内存不足导致缓存失效的问题，此外缓存数据还可以在JVM虚拟机重启的过程中持久化到硬盘中以防止缓存数据的意外丢失；对于读写型数据，例如系统中类似于商品描述、商品价格等频繁变动的数据，产品采用基于Memcached的远地集中式缓存，Memecached使用内存管理数据，通过缓存数据库查询或者与其他系统交互返回的结果，减少与数据库或者其他系统交互的次数，减少响应时间，此外Memecached使用客户端实现负载均衡，可支持缓存服务器水平和垂直扩展。技术平台的缓存框架基于AOP实现了对两种缓存的封装，对于业务逻辑实现者可以透明的使用方法调用返回的数据，而无需关心数据本身是否来自缓存。下图为缓存框架的示意图：

1.3.12 通用会话组件
  HTTP协议是无状态的，但通过Session机制，就能把无状态的变成有状态的。Session的功能就是保存HTTP请求之间的状态数据；有了session的支持，就很容易实现诸如用户登录、购物车等网站功能。
  会话保持可以由客户端和服务器端来分别实现，客户端使用Cookie保存会话数据，服务器端使用Session保持会话数据。但使用服务器端保持会话会有诸多限制：如容量限制、会话复制的限制等等。为了确保电商平台良好的伸缩行和可扩展性，i2Shopping提供了同时支持Cookie和Session的会话组件。
  通过精心设计，会话组件良好的伸缩性和可扩展性表现在以下几个方面：
  • 使用标准的HttpSession接口，而不是增加新的API。这样任何WEB应用，都可以轻易在两种不同的session机制之间切换。
  • 应用程序不需要知道session中的对象是被保存到了cookie中还是别的什么地方。
  • Session框架可以把同一个Session中的不同的对象分别保存到不同的地方去，应用程序同样不需要关心这些。例如，把一般信息放到cookie中，关键信息放到DB中。甚至同是cookie，也有持久和临时之分，有生命期长短之分。
  通用会话组件的示意图如下所示：

1.3.13 安全组件
  安全组件面向Web应用安全中常见的脚本注入（Injection）、跨站脚本攻击（XSS）、跨站请求伪造（CSRF）、不安全的直接对象引用等，构建了一道可定制化、可监控的安全防线。目前保护Web应用安全的两种方式有两种方式：黑名单机制（阻止含有非法内容的请求）和白名单机制（允许含有安全内容的请求）。Web应用安全有两部分组成：Web应用安全检测插件（可插入、易扩展）和Web应用安全威胁处理插件（可追溯、实时性）。

                    Web应用安全有两部分组成

                Web应用安全检查处理流程

1.4 系统高稳定性、高容量、高性能
1.4.1 高稳定性、高容量、高性能方案
  高稳定性、高容量、高性能主要表现在系统的可靠性、吞吐性能、可扩展性、负载均衡能力和系统伸缩能力等方面。本方案电子商务产品进行过全面、大量、严格的性能测试，应用系统的各项性能指标表现优异。
1.4.1.1 高稳定性
  电商平台的高稳定性，能保证网络系统中各主机24小时正常运行，并保证系统在访问高峰期能做到正常工作且快速响应。系统提供数据、进程的备份和恢复机制，防止各种可能的问题而造成损失。
  本方案建议使用标准的J2EE应用服务器以及成熟的i2Shopping 产品，以下几个方面确保了平台系统的高稳定性：
   系统采用成熟的平台，最大程度上保证了系统的稳定性。
   基于的开发流程是成熟稳定的：基于的系统的开发，采用参数化定制的方式，辅以集成开发工具IDE。因此基于i2Shopping的系统的开发是一个规范的开发过程。
  平台自身的会话重建技术，保证了客户信息的不可丢失性，从数据层面保障了系统的稳定性。
λ 支持集群部署，既能充分保证电商平台具有强劲的处理能力，又能在系统关键处理环节上避免单点故障。
   支持7天×24小时不间断平稳运行，系统可用性达到99.999%，生产运行和维护互不影响。
  平台支持横向扩展（增加服务器数量）和纵向扩展（增加单台服务器的硬件配置），并支持联机扩展。
   完善的交易日志处理，保障了交易信息的可恢复性和问题的可定位特性。
   准确的交易定位和监测，通过系统跟踪手段，能够准确、快速的定位和分析问题、解决问题，保证系统的正常运行。
   有效的监控平台，实现对网络节点（设备）和应用系统的实时、全面的监控和预警。
   监控平台实时的在线维护能力，有效促进了对系统问题的处理能力和系统恢复能力。
   严密的安全手段，屏蔽外来干扰。

1.4.1.2 高容量
  系统本身不对注册用户容量进行限制，注册用户容量的增长对应用系统的影响主要集中在当注册用户容量增加后，相关数据表操作的性能降低，因此这种影响的技术解决办法主要集中在数据库处理层面的调整和优化，因此如何保障数据库处理层面的并发读写和可扩展性尤为重要，在多年实施经验中我们积累了对数据库处理层面的调整和优化的最佳实践–数据库切分。
  数据库切分的基本思想就要把一个数据库切分成多个部分放到不同的数据库上，从而缓解单一数据库的性能问题。
  对于海量数据的数据库，如果是因为表多而数据多，这时候适合使用垂直切分，即把关系紧密（比如同一模块）的表切分出来放在一个数据库实例上（如系统配置参数相关表）。如果表并不多，但每张表（如用户表和订单表）的数据非常多，这时候适合水平切分，即把表的数据按某种规则（比如按ID散列）切分到多个数据库实例上。当然，现实中更多是这两种情况混杂在一起，这时候需要根据实际情况做出选择，也可能会综合使用垂直与水平切分，从而将原有数据库切分成类似矩阵一样可以无限扩充的数据库阵列。
  垂直切分的最大特点就是规则简单，实施也更为方便，尤其适合各业务之间的耦合度非常低，相互影响很小，业务逻辑非常清晰的系统。在这种系统中，可以很容易做到将不同业
  务模块所使用的表分拆到不同的数据库中。根据不同的表来进行拆分，对应用程序的影响也更小，拆分规则也会比较简单清晰。水平切分于垂直切分相比，相对来说稍微复杂一些。因为要将同一个表中的不同数据拆分到不同的数据库中，对于应用程序来说，拆分规则本身就较根据表名来拆分更为复杂，后期的数据维护也会更为复杂一些。
  产品对切分后的多个数据库提供了统一的数据访问层（DAL），屏蔽了切分后的数据库访问的复杂性。

1.4.1.3 高性能
  系统响应时间是指客户端接发起用户请求到客户端接收到服务器发来的数据所需的时间。响应时间直接影响用户的购物体验，从一定程度上决定了用户对于该网站的认可度。系统采用各种技术：分层缓存、压缩传输，集群等提高性能，并大量采用局部刷新、异步加载等，致力于最大程度提高用户购物体验。
  我们从以下两个大的方面降低系统响应时间：
  多维度缓存：从商城整体架构上来说，选择合适的缓存策略能带来性能的极大提升，产品提供两个维度的缓存。
  缓存的位置：从缓存使用者的角度来定义的，本地缓存是进程内缓存，适合于只读数据，远地缓存是进程外缓存，适合于读写数据。
  缓存的内容：从缓存中存放的具体内容来定义的，视图缓存、处理结果缓存、数据缓存分别对应于架构体系的视图层、业务逻辑层和数据访问层。
  基于事件驱动的异步处理: 事件驱动模型可以通过并发提高系统的容量和性能。事件驱动有以下三个要素：事件源：产生事件的源体；监听器：能够接收事件源通知的对象；事件处理程序：用于处理事件的对象。
  产品针对事件驱动模型提供了三种实现：JMS、ActiveMQ、组件容器事件发布器和监听器，商城的发送邮件、手机短信均采用事件驱动的方式实现。此外产品在对系统资源的使用方面（如端口监听和文件读写）采用了非阻塞API，如日终对账文件的读取使用NIO的Channel和Buffer。
  此外，本方案还将采用了以下方式确保系统的高效运行：
   平台化总控改造，规范和简化了交易请求机制，提升了交易的处理能力。
   对现有系统的系统资源的使用进行了调整，规范系统资源的合理调度。
   数据（数据字典和系统参数，以及频繁调度的静态交易数据）高速缓冲技术，有效的减少系统资源的占用，提升系统处理速度。
   系统中交易流程、组件等对象实例的复用，减少了内存的开销和对象创建、销毁的过程，节省了时间，提升了速度。
   系统对有限的系统资源（如数据库资源、通信资源等）采用缓冲池技术管理，保障系统对资源的快速调度。
   多线程处理技术的使用，提升了交易请求的并发度和处理速度。
   系统中，对大部分交易对象和组件实例进行高速缓存处理，大大的减少了在对象创建上浪费的时间和资源。
   配置参数化文件的缓存处理，配置文件仅在系统启动时的访问磁盘，减少系统IO处理，有效的提升了处理速度。
   本系统自有的会话管理，采用可定制管理模式，提升了系统的处理效率。

1.4.2 性能指标
  结合银行电商平台项目的性能需求设计，预计项目投产半年内，运营方根据经验预估注册用户数在200万的情况下，日均访问量120万人次/日；预计未来一年内，注册用户在500万的情况下，日均访问量300万/日；预计未来三年内，注册用户在1000万的情况下，日均访问量600万/日。以下列表为按照需求设计计算出的预期指标：

  指标数据计算说明：
  浏览页面数量=访问人次*8
  订单转化数=访问人次*1%
  最大并发数=会员人数*活跃比例0.03*8*0.8*10000/(5*3600)
  在线人数=5分钟内在线访问的UV数，按照80%的访问量发生在20%时间内计算产品在近期由IBM实施的性能测试的中性能表现良好，下表中为商城首页的部分测试数据，其中：平均响应时间单位为秒，Web服务器集群由4个Web服务器实例构成(Dell R720)，App服务器集群由6个App服务器实例构成(Dell R720 )，DB服务器由2个构成(Dell R720 )，测试过程中忽略思考时间。

  分析对比银行电商平台的性能需求设计与产品性能测试数据可知:在合理的软硬件配置下和应用系统自身优化后,产品可以满足用户600并发响应时间控制在5秒左右，根据项目上线的具体情况有所浮动。
  网络宽带估量

  总用户数活跃用户比例每人人均PV*80%*每个页面大小数*8=峰值时期的bit数
  24小时*20%*60*60=峰值时期的秒数
  峰值时期的bit数/峰值时期的秒数=宽带数
  每个页面不含图片130k
  每个图片74.3K，每个页面平均7个图片 共计520k
  页面大小为：130k+520k=650k
  例如：(1200000*3%*8*80%*650k*8)/（24*20%*60*60）=10400bps = 102Mbps

1.5 系统监控
1.5.1 监控系统的设计目标
  一个系统的运行环境包括网络、硬件和软件三个部分，要保障系统的正常运行，监控系统必须能够从网络节点（包括网络和设备）和应用这两个层次对系统进行全面监控。
  网络节点的监控，是实现对系统运行环境的物理资源的监控，对一个交易系统来说，网络节点的监控，就是实现对交易流程中涉及的各个设备环节的监控，也即交易节点监控。应用监控是对系统运行环境的逻辑资源进行监控。
  监控系统要能够确保系统的正常运行，及时的发现问题，并做出响应，监控系统必须满足以下基本求：
1.5.1.1 网络节点监控
  网络节点监控，可以迅速判定系统架构中的性能故障，而且不需要在被监控的服务器上安装任何软件，从而将监控带来的性能方面的负面影响降到最小，我们可以称为交易节点监控系统。
1.5.1.1.1 硬件级监控
  一个运行系统环境，接入了很多的设备，每一个设备（网络节点）都是一个监控点，要实现对系统的网络进行全面监控，必须达到：
   网络节点间的网络情况监控：是否畅通，网速大小等
   网络节点（设备）与网络节点（设备）之间的畅通性
   支持动态网络节点增减
1.5.1.1.2 系统级监控
  系统级监控就是实现对设备的运行情况监控，如对系统是否在运行，系统内存、CPU、交换区、磁盘空间、系统IO，以及对外服务端口等系统资源情况监控等等。设备监控是从系统级别的监控。
1.5.1.1.3 网路节点监控的特点
  网络节点监控具备如下特点：
   快速方便的实施
   方便的安装、使用和配置
   无代理、非嵌入式结构，不需要在被监控服务器上安装软件，从而将对系统的影响降到最低
   对网络资源和系统、如服务器Cluster的运行持续的进行状态轮询
   收集系统部件的详细性能数据，如CPU、虚存、交换区、进程、服务可用性等
   对其他管理工具提供广泛的支持，如为Microsoft、Citrix、BEA、Sun、Oracle、SAP和Siebel提供API
   对业界标准的广泛支持，如SNMP(v1、v2&v3)、Telent、FTP、News、email、DNS、LDAP、Radius以及其他一些服务
   支持从其他来源收集性能数据，如日志、命令行或批处理文件
   支持动态或静态基线的门限值设定
   故障确定后提供多种方式的告警
   支持监控的网络节点动态增减

1.5.1.2 应用监控
  应用监控就是监控设备上运行的应用软件的运行状态。对不同的应用软件，监控功能不一样。
  对应用的监控，除了实现对应用系统的运行情况进行全面监控外，还要对应用流程实现全流程监控：从应用流程的发起点到应用结束点，涵盖所有的流程环节。
1.5.1 监控系统设计

  监控系统的运行要求配置一个监控服务器，实现如下监控模式：
   根据监控系统配置的监控规则（如服务器类型，操作系统类型，采用的协议模式，访问授权信息等），主动获取监控对象的监控数据。
   根据参数配置，启动监控守护线程，被动接收从监控代理发送过来的监控数据信息
   分析监控数据，按照监控规则进行处理，如预警处理，监控信息通知，监控报表生成等
   监控人员通过监控终端，登录监控服务器，查看被监控的系统状态，并对被监控的系统进行实时在线维护。

1.5.2.1 网络节点监控方案设计
  网络节点的监控，需要支持动态的网络检点增减，因此对网络节点的监控主要是针对具体的监控设备或网段，采用主动获取的监控方式，监控网络畅通状态和设备状态，获取监控信息。
  网络节点的监控对所有的应用系统同。

1.5.2.2 应用监控方案设计
  应用监控主要是实现业务的全流程监控，从业务流程的发起点到业务流程的结束，完成对各个应用环节的监控。
  应用监控分主动监控数据获取和被动监控数据获取两种方式，主动获取由监控服务器发起，被动监控数据由部署在各环节上的监控代理获取，然后发送到监控服务器。监控人员通过监控终端登录监控服务器，查看应用状态和业务流程状态，以及各个环节的运行状态，并进行在线实时维护。
  对不同的应用，应用监控要求各不一样，需要针对不同的应用软件环境和硬件环境，进行定制。

1.5.3 电商平台系统监控设计
  对于电商平台系统来说，最为直接和迫切需要的，就是可实时报警和反馈的监控系统。该系统可以7x24不间断访问测试系统，提供最为实时和直接的警告。使系统管理员及时加以处理，减少反应的时间。
  电商平台系统的监控也需要从网络节点（包括网络和设备）和应用这两个层次实现全面监控。

1.5.3.1 网络节点监控
  如网络节点监控设计目标所述，网络节点监控包括网络级监控和系统级监控，在电商平台系统会员中心系统中，将根据接入设备和网络部署情况，进行监控策略定制，实现对系统的各个环节进行有效的监控和维护。
  系统网络节点的监控实现参见上节的监控系统设计。

1.5.3.2 系统应用监控
  电商平台是一个7x24不间断的客户交易系统，通过监控系统进行分析，以确定系统的运行情况和故障环节。就是实现对电商平台的WEB服务器的应用软件、应用服务器的应用软件和数据库服务器的应用软件的运行情况进行监控，尤其是应用服务器的应用软件——电商平台门户的运行情况进行监控。
监控系统对电商平台门户的监控，应该包容如下内容：
   监控：
   系统状态查看
   系统资源情况
   系统登录用户数、并发用户数监控
   系统维护
   监控启动停止操作
   应用系统启动停止操作
   系统资源在线维护
   系统内部组件在线实时调整
   系统参数在线实时维护
   系统耗时对象并发数在线控制
  以上只是部分功能列举，监控系统必须具备灵活的扩展性，可根据具体的应用需要，可进行扩展。
  电商平台会员中心系统的基础平台，符合JMX标准，能通过监控平台Monitor进行全面的应用监控，如系统运行状况、资源状态、耗时对象等等的监控，并能够针对问题，对生产系统进行实时在线调整维护。

1.5.4 监控平台Monitor介绍
1.1.1.1 Monitor的逻辑框架
   应用中，各个组件被包通过配置文件透明地被导出成一个一个的MBean，注册到MBeanServer中。
   用户通过浏览器以HTTP协议向i2FSP Monitor发出监控请求，Monitor MVC接受用户请求，通过调用RMIConnector与被监控端i2FSP应用中的RMIConnectorServer建立连接，调用相应MBean的方法，完成用户监控请求。
在RMI连接中，有以下几类数据流：
   1 从Monitor端发起，获取监控组件属性；
   2 从Monitor端发起，设置监控组件属性；
   3 从Monitor端发起，调用监控组件的监控方法；
   4 从被监控的i2FSP应用端发起，向对应的监听器发送监控报警信息。
   Monitor接收到报警信息后，根据配置，会调用邮件接口或短信接口把报警信息发送到对应的邮件接收者或短信接收者。

1.5.4.2 Monitor的实现原理
   Monitor监控系统采用JMX（Java Management Extensions）技术。
  在应用服务器端，针对一个平台上的应用，应用服务器平台自动提供可配置的JMX管理服务器端，可对外提供基于JMX标准框架的监控服务。
  在平台基础上，建立我们的基于JMX框架的监控应用，平台上的监控应用采用Web框架，同样架构在基础应用平台之上，是一个完全遵循JMX管理框架的监控服务器应用，可以连接标准的JMX MBean Server。并提供应用监控、应用管理和用户管理等功能。在监控平台上，封装了标准的JMX RMI协议支持的JMX访问连接器和基于JMXMP协议支持的访问连接器。
  监控系统的整体设计保证了平台在监控功能上对JMX的完全兼容能力。应用所提供的JMX监控功能能够被所有的基于标准的JMX监控客户端所访问，也保证了基于平台上的监控系统应用能够访问所有的标准的基于JMX监控服务器对象。

1.5.4.3 Monitor的功能
1.5.4.3.1 对基于平台的系统监控
   系统资源状态
  查看i2FSP系统服务器负载情况，如：登录人数、交易并发人数、数据库最大连接数、数据库当前连接数、MQ最大连接数、MQ连接数、TCP/IP连接数等应用指标参数进行查询。
  JVM属性配置查询
  查看应用服务器部署的系统环境参数，如语言，应用路径等信息。
  JVM进程运行状况
查看当前JAVA进程的线程堆栈，了解JVM的运行状况。
  后台系统状态
  查看i2FSP平台所连接的后台系统信息（如地址端口设定）和连接状态（如连接数、连接处理时间）。
  内部公共组件的状态
  查看渠道整合系统的内部公共组件状态（如数据库连接服务连接数等）；该功能实现对对被监控应用系统中重要的系统组件，如：数据库连接缓冲池、通信缓冲持、对象池等，进行参数信息在线实时调整，以及资源释放和分配、可用性控制等维护。
  交易异常的跟踪
  查看渠道整合系统内交易执行情况，及查看交易异常记录、查看交易异常文件跟踪或交易日志等。
  交易对象监控
  监控某个交易的执行情况，如并发数、用户分布情况等信息。
  交易日志的统计
  该功能用于对被监控应用系统中交易日志进行查询、分析操作。

1.5.4.3.2 对基于平台的系统控制
   监控启动或停止
  为了最小化监控对应用系统性能的影响，系统的监控并非是7x24小时必需的，只有在需要的情况下才启动监控。
通过监控系统，可以对被监控的系统是否启动监控进行动态维护。
   公共资源的控制
  通过监控系统，对中的一些公共资源参数在运行状态中进行重新设定，例如重新设定数据访问服务连接最大数、会话超时时间等等。
   内存资源回收
  通过监控系统，对被监控应用系统内存资源执行主动回收动作，并展示相应内存使用情况列表：系统内存数、剩余内存数和已使用的内存数。
  系统参数在线维护
  通过监控系统，对被监控的、基于实现的系统参数文件或数据表，进行重新读取或更新操作。
  交易参数配置文件维护
  该功能用于对被监控应用系统中，交易参数配置文件进行交易列表展示，并对选定交易配置信息进行在线初始化操作。
   受限交易列表维护
该功能用于对被监控应用系统中,需要控制并发数的受限交易列表进行展示展示，并对选下受限交易最大交易数进行修改操作，或禁用改交易的操作。
   即时消息推送
  该功能用于对被监控应用系统中产生的异常信息及时的进行提示和告警，便于维护人员及时处理。

1.5.5 完善的监控体系所产生的效益
   实施以上建议的监控体系，可以产生的效益是比较明显的，主要有：
   提供从业务出发的、7x24的实时业务性能视图
   提供服务水平和故障诊断报告
   对能够影响业务系统运作的潜在故障进行主动定位和告警
   将测试阶段使用的生产环境中加以利用，监视故障的响应时间
   增强系统的稳定性和正常工作时间
   降低对服务台的支持请求次数
   改善用户体验，提高用户满意度，从而提高在争取用户方面的竞争力
   通过数据分析得到趋势报表，进而反映业务系统中存在的问题并主动进行解决

1.6 系统部署架构
1.6.1 系统部署拓扑

  整个应用系统按照不同的业务功能和安全等级使用防火墙划分为不同的区域，包括Internet区域、DMZ区域、应用服务区域、Intranet（OA）办公区域。
   Internet区域是商城客户、商户操作员、第三方应用使用网络环境区域。
   DMZ区域指上图中第一道防火墙和第二道防火墙之间的部分，主要放置需要对外提供服务的Web服务器（含购物中心、商户中心等外网应用）。
   应用服务区域是商城应用系统和北农商银行其他外围渠道系统，主要包括电商平台应用服务器、数据库服务器、支付平台、短信平台、邮件平台、ODS、在线客服系统等。
   Intranet区域是北农商银行内部的办公或者业务区域，运营中心操作员在此区域访问银行电商平台的运营中心。

防火墙：
   防火墙是Internet与银行之间的路由选择，同时对流到北农商银行的数据流进行过滤的功能，也就是对北农商银行内部网起安全保护的作用，它只允许被开放的协议数据包被传送到北农商银行内部网络。系统共设有两道防火墙，组成系统的停火区。
   电商平台WEB服务器：
   电子商务平台WEB服务器主要有以下的几个功能和作用：
   负责提供电子商务平台应用系统静态资源，比如：html、图片、JavaScript脚本文件等。对于静态资源的处理，WEB服务器比J2EE应用服务器的效率要高的多，使用WEB服务器处理这类请求将大大提高应用系统的响应速度。
   转发商户或商城客户通过Internet提交的请求到后端应用服务器上进行处理，比如：JSP、Servlet。
   通过Web服务器将应用系统的应用服务器隔离在第二层防火墙之后,提高应用系统的安全等级。商城门户/商户服务WEB服务器既可以分开不同的硬件部署，也可以放置在一台服务器上，通过使用虚拟主机技术进行配置。为了避免单点故障，建议部署两台WEB服务器集群。（随业务发展需要，可以进行集群横向的扩展。譬如：如果业务压力过大，可以采用负载均衡来增加系统处理吞吐量、提高系统可用性）。

应用服务器：
   应用服务区用于部署了电商平台应用系统，包括面向商城客户的商城门户应用系统，面向商户服务和商城内部管理的商城管理应用系统（商户和商城内部管理可以集成也可分离进行部署），搜索引擎服务器，电子邮件服务器。
   应用服务器，可以通过应用服务器的群集功能，采用多台服务器组成负载均衡模式下的应用服务器集群系统，以达到最大的高可用性。

数据库服务器：
   电商平台数据库服务器存放电商平台相关的数据，由多台数据库服务器组成水平集群。

支付平台
   对电子商务平台而言，网上支付平台主要提供两个方面的功能：一.接收客户的支付请求，并将支付结果返回给客户：支付平台将Internet传来的数据包解密，并按照银行系统内部的通信协议将数据重新打包；接收银行系统内部的传回来的响应消息，将数据转换为Internet传送的数据格式，并对其进行加密。即支付网关主要完成通信、协议转换和数据加解密功能，以保护银行内部网络。
   二.接收银行电子商务平台运营中心发起的对支付订单的管理类请求，如订单退款、对账等。

短信平台
   短信平台主要用来发送短信给通知反馈客户其操作行为和结果，起到了预警和确认的作用，譬如：客户注册、购买商品时，电子商务平台通过调用短信平台的相关接口，发送相应的短信到客户预留的手机中。

邮件平台
   邮件平台主要用来发邮件通知反馈客户其操作行为和结果，起到了预警和确认的作用，譬如：客户注册、购买商品时，电子商务平台通过调用邮件平台的相关接口，发送相应的邮件到客户预留的Email邮箱中。

在线客服
   在线客户通过即时通讯的方式为电商平台提供与访问者对话的平台，起到了增加营销渠道、增加销售机会、降低运营成本、巩固客户关系等的作用。

统一身份认证平台
   统一身份认证平台通过多个异构系统统一在一个验证体系进行用户验证，保障了用户及其权限的一致性，简化客户的操作流程，增加客户对电商平台及相关网站的粘滞性。

互联网SNS
  通过在浏览器端调用其他互联网服务提供商的开放API接口，可以实现商品的分享和推荐。

1.6.2 系统拓扑结构特点
   本系统网络拓扑具有以下特点：
   采用两层防火墙结构，具有较高的安全性，能有效地抵御来自内部、外部、中间部分的入侵；建议外防火墙采用双机热备份方式，以保证系统稳定性；
   使用防火墙，将网络划分为不同安全级别的区域：限制DMZ、核心业务区、Intranet；
   内外防火墙不直接相连，在限制DMZ区的服务器均有两张网卡，分别跨接在内外防火墙的网段上，并且取消路由转发；即便外层防火墙被攻破，入侵者也无法直接抵达内部防火墙，增强了系统安全性。

  Internet区
  Internet区域不是用户自主的区域，该区域通过专线接入到用户的边缘路由器，边缘路由器再与外层防火墙连接。路由器和防火墙是防范外部入侵的第一道防线，配置上应格外小心。
   边缘路由器应选用带有防火墙过滤功能的路由器；
   边缘路由器与防火墙之间不宜再添加交换机，一方面可以减少设备的投入，另一方面也减少了入侵的立足点；
   边缘路由器和防火墙之间的网络地址应使用Internet保留的私有地址，如10.0.0.0/8，这样可以保证从Internet不可以直接访问到路由器的对内网络和防火墙的对外网口；
   在防火墙的安全规则中应禁止来自边缘路由器各端口对内、外层防火墙各端口的访问，万一边缘路由器被攻破，该规则可以防止来自边缘路由器的攻击。

  双防火墙热备份结构
  内、外层防火墙采用的是双机的结构，通过防火墙软件自身的HA功能或系统级的HA功能，可以实现防火墙的热备份功能，同一时刻，内层和外层防火墙都只能有一个防火墙处于工作状态（Active），另一个处于等待状态（Standby），两个防火墙之间建立私有的心跳网络并通过该网络相互检测对方的可用性，处于等待状态的主机一旦检测到处于工作状态的主机失效时，会自动从等待状态转到工作状态并将服务接管过来。

  DMZ区域
  该区域是整个网络拓扑对外服务的核心部分，拥有最高的安全级别，用户对外的主要服务器一般放置在该区域：
   该区使用Internet合法地址，因此防火墙相应的网口必须使用Internet合法地址；
   该区域的服务器对内访问时，只可以访问核心业务区；
   该区服务器必须配置两个网口，一个网口连接到对外的独立交换机，一个连接到对内的独立交换机；
   由于服务器对内对外使用不同的网络接口，可以提高服务器的网络流量；
   由于外层防火墙和内层防火墙未直接连接，万一外层防火墙被入侵，入侵者仍无法直接攻击内层防火墙；

  应用服务区域
   应用服务器需要与DMZ区的Web服务器和核心业务区系统进行通讯；
   应用服务器需要与核心业务区、通过内部网的交易通讯网关或者直接与后端核心业务系统通讯。

  Intranet
  该区域是银行管理人员的内部网络

1.7 系统软硬件配置
  下表罗列的软、硬件配置参照交行信用卡商城生产环境编写，实际部署情况可能会有改动，此仅供参考。
所有服务器暂时在同一个机房部署，等以后再进行划分。
1.7.1 Web服务器

1.7.1 应用服务器

1.7.3 数据库服务器