标题 | 网上银行客户感知监测预警系统方案设计 |
范文 | 牛率仁 [摘 要] 监测客户感知并及时对异常流量作出预警非常重要,如果银行根本就不知道自己的客户面对的是一个怎样的系统,自己的客户感受到的是怎样一种情况,客户何时在使用系统时遇到了麻烦,那么提高系统性能,改善客户体验,提高服务质量将是一句空谈。文章通过最贴近终端用户的预警系统,灵敏反馈用户感知的每一次波动,使运维人员提前发现并处理系统运行中的隐患,在故障还未发生时就将其扼杀在萌芽状态,减少故障发生频率,有效控制风险,转变被动接收用户反馈为主动监测服务质量,提高故障发现主动性。 [关键词] 网上银行;监测预警;方案 doi : 10 . 3969 / j . issn . 1673 - 0194 . 2017. 15. 076 [中图分类号] TP311 [文献标识码] A [文章编号] 1673 - 0194(2017)15- 0169- 03 0 前 言 为了获悉网上银行客户在使用网上银行系统时的感知情况,需要部署监测系统监测用户感知数据。分析常用的数据采集方案如下。 主动模拟拨测:适合于网络带来的问题,是采用样本监控分析的方式,更适合互联网应用,是主动监控方式。 页面插入代码:侵入式,需要在浏览器上嵌入代码,是被动监控方式。 客户端插件采集:侵入式,需要开发部门配合,需在页面代码中插入插件,可以实现代码级的监控,效果依赖开发部门的支持。 应用服务器端代理:侵入式,需要开发部门配合,可以实现代码级的监控,效果依赖开发部门的支持。 服务端旁路:非侵入式,运维部门可以推广使用,能获得服务及应用、交易级别的监控。 综上,基于传统银行现存系统多,开发部门和运维部门相对独立,各司其职,运维开发能力相对较弱的现状,服务端旁路的监测方式更适合优先引入解决银行应用系统的性能问题。 1 监测预警系统整体设计 监测预警系统网络流量分析系统主要由网络探针、大数据平台和展现平台三部分共同组成。 1.1 探针设备 主要作用是对获取的数据包信息进行实时分析,并将解析的数据发送大数据平台。 1.2 大数据平台 分布式实时统计、交互式查询平台提供强大计算能力。主要进行实时统计功能,获取网上银行交易性能指标:交易量、交易响应率、交易成功率、交易响应时间,并能快速计算得到动态基线,对客户感知的异常数据流进行快速预警。 1.3 监控系统展现平台 提供企业級的统一管理监控界面,能对多台捕获设备所监测的数据进行统一、关联、对比分析,并提供长期可归档的集中报表。 2 功能模块 通过探针采集到的数据均是二进制原始比特流,解码平台的主要功能是实时捕获原始数据,将其封装为pcap格式数据包并解码成具备可读性的原始交易报文,之后进行解析得到相应的监控数据;将得到的数据发送大数据平台进行统计分析,同时监控数据和原始数据包也会送往存储平台进行存储;最后由数据展现平台对分析结果和监控指标进行可视化的展现。 2.1 解码平台架构 解码集群采用分布式架构,主要分三个模块,管理端Manager,服务端Server,客户端Client。Server与Client都是分布式的程序,每个Manager下挂多个Server,每个Server下挂多个Client。 服务端Server 主要负责网络流量的抓取及原始数据的pcap文件的生成,将业务流量均衡地分发给注册的Client节点。 客户端Client主要负责接受绑定Server发送过来的业务数据,进行TCP还原及业务层解码还原。通过对业务数据进行业务层还原,相关工作人员可以看到网上银行客户的每笔交易数据,了解客户交易情况。 2.2 解码平台配置 2.2.1 硬件环境 CPU:2.4 GHz , 16核 内存:64 G 网卡:2个1 000 M以太网接口 磁盘:3×300 GB RAID配置:RAID 5 2.2.2 软件环境 操作系统:Linux 64位 CentOS 6.5版本 JAVA:jdk 1.7.0_75 Derby数据库:Apache Derby 10.12 Server内存分配:10 GB,Client内存分配:10 GB 2.2.3 性能指标 吞吐量:1 Gbps,Server个数:1,Client个数:4 2.2.4 安全策略 CodeMeter运行时:CodeMeter-6.20.2147-500 程序保护外壳:AxProtector-9.40.2147-500 2.3 HDFS/HBase 存储选型涉及关键问题。 根据网上银行客户感知数据分析业务要求,构建分布式存储数据库以支撑分布式计算平台,用来存储采集的原始数据以及运算结果。存储设备应满足以下要求。 (1)流数据读写,实时的读、写大规模数据; (2)扩展性,支持线性扩展,应对数据量的持续增长; (3)性价比,对集群服务器没有配置要求,可以使用低廉配置搭建集群; (4)可靠性,某台服务器宕机,不影响数据的完整性。 数据库HBase是一个基于列模式的映射数据库,它只能表示很简单的“键-数据”的映射关系,大大简化了传统的关系数据库。它在海量存储和互联网应用需求上更胜一筹。它灵活的分布式架构使其在利用廉价的硬件设备组建大数据仓库上如鱼得水。HBase是针对以字符为基础的应用而开发出来的数据库,适应互联网应用的特点。 2.4 Kafka 众所周知,在双十一或者春节的时候,因为双十一的秒杀和春节网上购买火车票,会导致大量客户使用网上银行,可是像突发量这样的情况很少见,的确没有必要以突发流量峰值访问为标准来投入资源,因为这样对软硬件来说浪费都是巨大的。但是在访问量剧增的情况下,应用仍然需要继续发挥作用,为了不使关键组件因为突发的超负荷的请求而完全崩溃,使用消息队列也是必须的。Kafka是一种高吞吐量的分布式发布订阅消息系统,它可以处理消费者规模的网站中的所有动作流数据。 选用Kafka的原因: (1)冗余。冗余方式主要是为了避免数据丢失。把一个消息从消息队列中删除之前,要明确消息已被处理完成,否则这个消息将被安全的保存直到使用完毕。 (2)扩展性。在不改变代码、不调节参数的情况下,只需要增加处理过程,就可以增大消息入队和处理的频率,这是因为消息队列解耦了处理过程。 (3)灵活性与峰值处理能力。因为采取消息队列机制,Kafka具有很好的灵活性和峰值处理能力。 (4)可恢复性。可恢复性非常重要,因为这样可以改善用户的使用体验,可恢复性允许重试或者延后处理请求,这样不至于在出现错误时,无法重试或者无法弥补,导致所用操作重新再来,或者给用户造成损失,导致用户情绪崩溃。 (5)送达保证。送达保证能够每个消息能够被处理且只能够被处理一次,这是由消息队列的冗余機制所保证的。 (6)顺序保证。消息将会以通过FIFO(先进先出)的顺序来处理,从队列中检索出的位置就是消息在队列中的位置。 (7)缓冲。缓冲保证在重要的系统中,消息的轻重缓急可以被安排,从而提高任务的执行效率,这是通过缓冲层实现的,而且数据流经过系统的速度的优化和可控都要得益于缓冲层。 (8)异步通信。异步通信使得在向队列中存放消息时,数目不受到限制,因为放入的消息不会立即被处理,而是在需要的时候。 2.5 Spark 作为网上银行客户监测预警的计算平台,它需要承担巨大的计算任务,每天网上银行数以万计的使用者,计算平台需要对大量数据进行数据准备,按照数数据挖掘算法进行建模运算并寻找规律,生成实时动态基线,精准快速预警,这对计算平台的处理能力和可靠性都提出了很高的要求。 Spark体系架构包括如下三个主要组件: (1)数据存储。Spark用HDFS文件系统存储数据。 (2)API。利用API,应用开发者可以用标准的API接口创建基于Spark的应用。 (3)管理框架。Spark既可以部署在一个单独的服务器也可以部署在分布式计算框架之上。 它是一个围绕速度、易用性和复杂分析构建的大数据处理框架,它可以满足我们对大数据的处理请求,能够将Hadoop集群中的应用在内存中的运行速度提升100倍,甚至可以提升10倍应用在磁盘上的运行速度,也可以快速运用某些高级语言编写程序,并且支持交互的查询数据。 主要参考文献 [1]刘泓含.浅谈网上银行服务质量的改进[J].海南金融,2012,18(1):76-80. [2]朱筱兰,席晓乾.浅谈数据挖掘技术在增值业务中的应用[C]//四川省通信学会2012年年会论文集,2012. |
随便看 |
|
科学优质学术资源、百科知识分享平台,免费提供知识科普、生活经验分享、中外学术论文、各类范文、学术文献、教学资料、学术期刊、会议、报纸、杂志、工具书等各类资源检索、在线阅读和软件app下载服务。