网上银行专升本毕业论文范文和网上银行客户感知监测预警系统方案设计类专升本论文范文-毕业论文网

本论文为您写网上银行毕业论文范文和职称论文提供相关论文参考文献，可免费下载。

网上银行客户感知监测预警系统方案设计

牛率仁

（平顶山市工业学校,河南平顶山 467001）

［摘

要］监测客户感知并及时对异常流量作出预警非常重要,如果银行根本就不知道自己的客户面对的是一个怎样的系统,自己的客户感受到的是怎样一种情况,客户何时在使用系统时遇到了麻烦,那么提高系统性能,改善客户体验,提高服务质量将是一句空谈.文章通过最贴近终端用户的预警系统,灵敏反馈用户感知的每一次波动,使运维人员提前发现并处理系统运行中的隐患,在故障还未发生时就将其扼杀在萌芽状态,减少故障发生频率,有效控制风险,转变被动接收用户反馈为主动监测服务质量,提高故障发现主动性.

［关键词］网上银行；监测预警；方案

doi : 10 . 3969 / j . issn . 1673 - 0194 . 2017. 15. 076

［中图分类号］ TP311

［文献标识码］ A

［文章编号］ 1673 - 0194（2017）15- 0169- 03

前

言

为了获悉网上银行客户在使用网上银行系统时的感知情况,需要部署监测系统监测用户感知数据.分析常用的数据采集方案如下.

主动模拟拨测：适合于网络带来的问题,是采用样本监控分析的方式,更适合互联网应用,是主动监控方式.

页面插入代码：侵入式,需要在浏览器上嵌入代码,是被动监控方式.

客户端插件采集：侵入式,需要开发部门配合,需在页面代码中插入插件,可以实现代码级的监控,效果依赖开发部门的支持.

应用服务器端代理：侵入式,需要开发部门配合,可以实现代码级的监控,效果依赖开发部门的支持.

服务端旁路：非侵入式,运维部门可以推广使用,能获得服务及应用、交易级别的监控.

综上,基于传统银行现存系统多,开发部门和运维部门相对独立,各司其职,运维开发能力相对较弱的现状,服务端旁路的监测方式更适合优先引入解决银行应用系统的性能问题.

１

监测预警系统整体设计

监测预警系统网络流量分析系统主要由网络探针、大数据平台和展现平台三部分共同组成.

1．1 探针设备

主要作用是对获取的数据包信息进行实时分析,并将解析的数据发送大数据平台.

1．2 大数据平台

分布式实时统计、交互式查询平台提供强大计算能力.主要进行实时统计功能,获取网上银行交易性能指标：交易量、交易响应率、交易成功率、交易响应时间,并能快速计算得到动态基线,对客户感知的异常数据流进行快速预警.

1．3 监控系统展现平台

提供企业级的统一管理监控界面,能对多台捕获设备所监测的数据进行统一、关联、对比分析,并提供长期可归档的集中报表.

２

功能模块

通过探针采集到的数据均是二进制原始比特流,解码平台的主要功能是实时捕获原始数据,将其封装为ｐｃａｐ格式数据包并解码成具备可读性的原始交易报文,之后进行解析得到相应的监控数据；将得到的数据发送大数据平台进行统计分析,同时监控数据和原始数据包也会送往存储平台进行存储；最后由数据展现平台对分析结果和监控指标进行可视化的展现.

２．１解码平台架构

解码集群采用分布式架构,主要分三个模块,管理端Ｍａｎａｇｅｒ,服务端Ｓｅｒｖｅｒ,客户端Ｃｌｉｅｎｔ.Ｓｅｒｖｅｒ与Ｃｌｉｅｎｔ都是分布式的程序,每个Ｍａｎａｇｅｒ下挂多个Ｓｅｒｖｅｒ,每个Ｓｅｒｖｅｒ下挂多个Ｃｌｉｅｎｔ.

服务端Ｓｅｒｖｅｒ主要负责网络流量的抓取及原始数据的ｐｃａｐ文件的生成,将业务流量均衡地分发给注册的Ｃｌｉｅｎｔ节点.

客户端Ｃｌｉｅｎｔ主要负责接受绑定Ｓｅｒｖｅｒ发送过来的业务数据,进行ＴＣＰ还原及业务层解码还原.通过对业务数据进行业务层还原,相关工作人员可以看到网上银行客户的每笔交易数据,了解客户交易情况.

２．２解码平台配置

2.2.１硬件环境

ＣＰＵ：２．４ＧＨｚ , １６核

内存：６４Ｇ

网卡：２个１０００ M以太网接口

磁盘：３×３００ＧＢ

ＲＡＩＤ配置：ＲＡＩＤ５

2.2.２软件环境

操作系统：Ｌｉｎｕｘ６４位

ＣｅｎｔＯＳ６．５版本

ＪＡＶＡ：ｊｄｋ１．７．０＿７５

Ｄｅｒｂｙ数据库：ＡｐａｃｈｅＤｅｒｂｙ１０．１２

Ｓｅｒｖｅｒ内存分配：１０ＧＢ,Ｃｌｉｅｎｔ内存分配：１０ＧＢ

2.2.３性能指标

吞吐量：１Ｇｂｐｓ,Ｓｅｒｖｅｒ个数：１,Ｃｌｉｅｎｔ个数：４

2.2.４安全策略

ＣｏｄｅＭｅｔｅｒ运行时：ＣｏｄｅＭｅｔｅｒ－６．２０．２１４７－５００

程序保护外壳：ＡｘＰｒｏｔｅｃｔｏｒ－９．４０．２１４７－５００

２．３ＨＤＦＳ／ＨＢａｓｅ

存储选型涉及关键问题.

根据网上银行客户感知数据分析业务要求,构建分布式存储数据库以支撑分布式计算平台,用来存储采集的原始数据以及运算结果.存储设备应满足以下要求.

（１）流数据读写,实时的读、写大规模数据；

（２）扩展性,支持线性扩展,应对数据量的持续增长；

（３）性价比,对集群服务器没有配置要求,可以使用低廉配置搭建集群；

（４）可靠性,某台服务器宕机,不影响数据的完整性.

数据库ＨＢａｓｅ是一个基于列模式的映射数据库,它只能表示很简单的“键－数据”的映射关系,大大简化了传统的关系数据库.它在海量存储和互联网应用需求上更胜一筹.它灵活的分布式架构使其在利用廉价的硬件设备组建大数据仓库上如鱼得水.ＨＢａｓｅ是针对以字符为基础的应用而开发出来的数据库,适应互联网应用的特点.

２．４Ｋａｆｋａ

众所周知,在双十一或者春节的时候,因为双十一的秒杀和春节网上购买,会导致大量客户使用网上银行,可是像突发量这样的情况很少见,的确没有必要以突发流量峰值访问为标准来投入资源,因为这样对软硬件来说浪费都是巨大的.但是在访问量剧增的情况下,应用仍然需要继续发挥作用,为了不使关键组件因为突发的超负荷的请求而完全崩溃,使用消息队列也是必须的.Ｋａｆｋａ是一种高吞吐量的分布式发布订阅消息系统,它可以处理消费者规模的网站中的所有动作流数据.

选用Ｋａｆｋａ的原因：

（１）冗余.冗余方式主要是为了避免数据丢失.把一个消息从消息队列中删除之前,要明确消息已被处理完成,否则这个消息将被安全的保存直到使用完毕.

（２）扩展性.在不改变代码、不调节参数的情况下,只需要增加处理过程,就可以增大消息入队和处理的频率,这是因为消息队列解耦了处理过程.

（３）灵活性与峰值处理能力.因为采取消息队列机制,Ｋａｆｋａ具有很好的灵活性和峰值处理能力.

（４）可恢复性.可恢复性非常重要,因为这样可以改善用户的使用体验,可恢复性允许重试或者延后处理请求,这样不至于在出现错误时,无法重试或者无法弥补,导致所用操作重新再来,或者给用户造成损失,导致用户情绪崩溃.

（５）送达保证.送达保证能够每个消息能够被处理且只能够被处理一次,这是由消息队列的冗余机制所保证的.

（６）顺序保证.消息将会以通过ＦＩＦＯ（先进先出）的顺序来处理,从队列中检索出的位置就是消息在队列中的位置.

（７）缓冲.缓冲保证在重要的系统中,消息的轻重缓急可以被安排,从而提高任务的执行效率,这是通过缓冲层实现的,而且数据流经过系统的速度的优化和可控都要得益于缓冲层.

（８）异步通信.异步通信使得在向队列中存放消息时,数目不受到限制,因为放入的消息不会立即被处理,而是在需要的时候.

２．５Ｓｐａｒｋ

作为网上银行客户监测预警的计算平台,它需要承担巨大的计算任务,每天网上银行数以万计的使用者,计算平台需要对大量数据进行数据准备,按照数数据挖掘算法进行建模运算并寻找规律,生成实时动态基线,精准快速预警,这对计算平台的处理能力和可靠性都提出了很高的要求.

Ｓｐａｒｋ体系架构包括如下三个主要组件：