網(wǎng)上銀行客戶感知監(jiān)測預警系統(tǒng)方案設計

牛率仁

[摘 要] 監(jiān)測客戶感知并及時對異常流量作出預警非常重要，如果銀行根本就不知道自己的客戶面對的是一個怎樣的系統(tǒng)，自己的客戶感受到的是怎樣一種情況，客戶何時在使用系統(tǒng)時遇到了麻煩，那么提高系統(tǒng)性能，改善客戶體驗，提高服務質(zhì)量將是一句空談。文章通過最貼近終端用戶的預警系統(tǒng)，靈敏反饋用戶感知的每一次波動，使運維人員提前發(fā)現(xiàn)并處理系統(tǒng)運行中的隱患，在故障還未發(fā)生時就將其扼殺在萌芽狀態(tài)，減少故障發(fā)生頻率，有效控制風險，轉(zhuǎn)變被動接收用戶反饋為主動監(jiān)測服務質(zhì)量，提高故障發(fā)現(xiàn)主動性。

[關鍵詞] 網(wǎng)上銀行；監(jiān)測預警；方案

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

[中圖分類號] TP311 [文獻標識碼] A [文章編號] 1673 - 0194（2017）15- 0169- 03

0 前 言

為了獲悉網(wǎng)上銀行客戶在使用網(wǎng)上銀行系統(tǒng)時的感知情況，需要部署監(jiān)測系統(tǒng)監(jiān)測用戶感知數(shù)據(jù)。分析常用的數(shù)據(jù)采集方案如下。

主動模擬撥測：適合于網(wǎng)絡帶來的問題，是采用樣本監(jiān)控分析的方式，更適合互聯(lián)網(wǎng)應用，是主動監(jiān)控方式。

頁面插入代碼：侵入式，需要在瀏覽器上嵌入代碼，是被動監(jiān)控方式。

客戶端插件采集：侵入式，需要開發(fā)部門配合，需在頁面代碼中插入插件，可以實現(xiàn)代碼級的監(jiān)控，效果依賴開發(fā)部門的支持。

應用服務器端代理：侵入式，需要開發(fā)部門配合，可以實現(xiàn)代碼級的監(jiān)控，效果依賴開發(fā)部門的支持。

服務端旁路：非侵入式，運維部門可以推廣使用，能獲得服務及應用、交易級別的監(jiān)控。

綜上，基于傳統(tǒng)銀行現(xiàn)存系統(tǒng)多，開發(fā)部門和運維部門相對獨立，各司其職，運維開發(fā)能力相對較弱的現(xiàn)狀，服務端旁路的監(jiān)測方式更適合優(yōu)先引入解決銀行應用系統(tǒng)的性能問題。

1 監(jiān)測預警系統(tǒng)整體設計

監(jiān)測預警系統(tǒng)網(wǎng)絡流量分析系統(tǒng)主要由網(wǎng)絡探針、大數(shù)據(jù)平臺和展現(xiàn)平臺三部分共同組成。

1.1 探針設備

主要作用是對獲取的數(shù)據(jù)包信息進行實時分析，并將解析的數(shù)據(jù)發(fā)送大數(shù)據(jù)平臺。

1.2 大數(shù)據(jù)平臺

分布式實時統(tǒng)計、交互式查詢平臺提供強大計算能力。主要進行實時統(tǒng)計功能，獲取網(wǎng)上銀行交易性能指標：交易量、交易響應率、交易成功率、交易響應時間，并能快速計算得到動態(tài)基線，對客戶感知的異常數(shù)據(jù)流進行快速預警。

1.3 監(jiān)控系統(tǒng)展現(xiàn)平臺

提供企業(yè)級的統(tǒng)一管理監(jiān)控界面，能對多臺捕獲設備所監(jiān)測的數(shù)據(jù)進行統(tǒng)一、關聯(lián)、對比分析，并提供長期可歸檔的集中報表。

2 功能模塊

通過探針采集到的數(shù)據(jù)均是二進制原始比特流，解碼平臺的主要功能是實時捕獲原始數(shù)據(jù)，將其封裝為pcap格式數(shù)據(jù)包并解碼成具備可讀性的原始交易報文，之后進行解析得到相應的監(jiān)控數(shù)據(jù)；將得到的數(shù)據(jù)發(fā)送大數(shù)據(jù)平臺進行統(tǒng)計分析，同時監(jiān)控數(shù)據(jù)和原始數(shù)據(jù)包也會送往存儲平臺進行存儲；最后由數(shù)據(jù)展現(xiàn)平臺對分析結果和監(jiān)控指標進行可視化的展現(xiàn)。

2.1 解碼平臺架構

解碼集群采用分布式架構，主要分三個模塊，管理端Manager，服務端Server，客戶端Client。Server與Client都是分布式的程序，每個Manager下掛多個Server，每個Server下掛多個Client。

服務端Server 主要負責網(wǎng)絡流量的抓取及原始數(shù)據(jù)的pcap文件的生成，將業(yè)務流量均衡地分發(fā)給注冊的Client節(jié)點。

客戶端Client主要負責接受綁定Server發(fā)送過來的業(yè)務數(shù)據(jù)，進行TCP還原及業(yè)務層解碼還原。通過對業(yè)務數(shù)據(jù)進行業(yè)務層還原，相關工作人員可以看到網(wǎng)上銀行客戶的每筆交易數(shù)據(jù)，了解客戶交易情況。

2.2 解碼平臺配置

2.2.1 硬件環(huán)境

CPU：2.4 GHz ， 16核

內(nèi)存：64 G

網(wǎng)卡：2個1 000 M以太網(wǎng)接口

磁盤：3×300 GB

RAID配置：RAID 5

2.2.2 軟件環(huán)境

操作系統(tǒng)：Linux 64位 CentOS 6.5版本

JAVA：jdk 1.7.0_75

Derby數(shù)據(jù)庫：Apache Derby 10.12

Server內(nèi)存分配：10 GB，Client內(nèi)存分配：10 GB

2.2.3 性能指標

吞吐量：1 Gbps，Server個數(shù)：1，Client個數(shù)：4

2.2.4 安全策略

CodeMeter運行時：CodeMeter-6.20.2147-500

程序保護外殼：AxProtector-9.40.2147-500

2.3 HDFS/HBase

存儲選型涉及關鍵問題。

根據(jù)網(wǎng)上銀行客戶感知數(shù)據(jù)分析業(yè)務要求，構建分布式存儲數(shù)據(jù)庫以支撐分布式計算平臺，用來存儲采集的原始數(shù)據(jù)以及運算結果。存儲設備應滿足以下要求。

（1）流數(shù)據(jù)讀寫，實時的讀、寫大規(guī)模數(shù)據(jù)；

（2）擴展性，支持線性擴展，應對數(shù)據(jù)量的持續(xù)增長；

（3）性價比，對集群服務器沒有配置要求，可以使用低廉配置搭建集群；

（4）可靠性，某臺服務器宕機，不影響數(shù)據(jù)的完整性。

數(shù)據(jù)庫HBase是一個基于列模式的映射數(shù)據(jù)庫，它只能表示很簡單的“鍵-數(shù)據(jù)”的映射關系，大大簡化了傳統(tǒng)的關系數(shù)據(jù)庫。它在海量存儲和互聯(lián)網(wǎng)應用需求上更勝一籌。它靈活的分布式架構使其在利用廉價的硬件設備組建大數(shù)據(jù)倉庫上如魚得水。HBase是針對以字符為基礎的應用而開發(fā)出來的數(shù)據(jù)庫，適應互聯(lián)網(wǎng)應用的特點。endprint

2.4 Kafka

眾所周知，在雙十一或者春節(jié)的時候，因為雙十一的秒殺和春節(jié)網(wǎng)上購買火車票，會導致大量客戶使用網(wǎng)上銀行，可是像突發(fā)量這樣的情況很少見，的確沒有必要以突發(fā)流量峰值訪問為標準來投入資源，因為這樣對軟硬件來說浪費都是巨大的。但是在訪問量劇增的情況下，應用仍然需要繼續(xù)發(fā)揮作用，為了不使關鍵組件因為突發(fā)的超負荷的請求而完全崩潰，使用消息隊列也是必須的。Kafka是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)，它可以處理消費者規(guī)模的網(wǎng)站中的所有動作流數(shù)據(jù)。

選用Kafka的原因：

（1）冗余。冗余方式主要是為了避免數(shù)據(jù)丟失。把一個消息從消息隊列中刪除之前，要明確消息已被處理完成，否則這個消息將被安全的保存直到使用完畢。

（2）擴展性。在不改變代碼、不調(diào)節(jié)參數(shù)的情況下，只需要增加處理過程，就可以增大消息入隊和處理的頻率，這是因為消息隊列解耦了處理過程。

（3）靈活性與峰值處理能力。因為采取消息隊列機制，Kafka具有很好的靈活性和峰值處理能力。

（4）可恢復性?？苫謴托苑浅Ｖ匾?，因為這樣可以改善用戶的使用體驗，可恢復性允許重試或者延后處理請求，這樣不至于在出現(xiàn)錯誤時，無法重試或者無法彌補，導致所用操作重新再來，或者給用戶造成損失，導致用戶情緒崩潰。

（5）送達保證。送達保證能夠每個消息能夠被處理且只能夠被處理一次，這是由消息隊列的冗余機制所保證的。

（6）順序保證。消息將會以通過FIFO（先進先出）的順序來處理，從隊列中檢索出的位置就是消息在隊列中的位置。

（7）緩沖。緩沖保證在重要的系統(tǒng)中，消息的輕重緩急可以被安排，從而提高任務的執(zhí)行效率，這是通過緩沖層實現(xiàn)的，而且數(shù)據(jù)流經(jīng)過系統(tǒng)的速度的優(yōu)化和可控都要得益于緩沖層。

（8）異步通信。異步通信使得在向隊列中存放消息時，數(shù)目不受到限制，因為放入的消息不會立即被處理，而是在需要的時候。

2.5 Spark

作為網(wǎng)上銀行客戶監(jiān)測預警的計算平臺，它需要承擔巨大的計算任務，每天網(wǎng)上銀行數(shù)以萬計的使用者，計算平臺需要對大量數(shù)據(jù)進行數(shù)據(jù)準備，按照數(shù)數(shù)據(jù)挖掘算法進行建模運算并尋找規(guī)律，生成實時動態(tài)基線，精準快速預警，這對計算平臺的處理能力和可靠性都提出了很高的要求。

Spark體系架構包括如下三個主要組件：

（1）數(shù)據(jù)存儲。Spark用HDFS文件系統(tǒng)存儲數(shù)據(jù)。

（2）API。利用API，應用開發(fā)者可以用標準的API接口創(chuàng)建基于Spark的應用。

（3）管理框架。Spark既可以部署在一個單獨的服務器也可以部署在分布式計算框架之上。

它是一個圍繞速度、易用性和復雜分析構建的大數(shù)據(jù)處理框架，它可以滿足我們對大數(shù)據(jù)的處理請求，能夠?qū)adoop集群中的應用在內(nèi)存中的運行速度提升100倍，甚至可以提升10倍應用在磁盤上的運行速度，也可以快速運用某些高級語言編寫程序，并且支持交互的查詢數(shù)據(jù)。

主要參考文獻

[1]劉泓含.淺談網(wǎng)上銀行服務質(zhì)量的改進[J].海南金融，2012，18（1）：76-80.

[2]朱筱蘭，席曉乾.淺談數(shù)據(jù)挖掘技術在增值業(yè)務中的應用[C]//四川省通信學會2012年年會論文集，2012.endprint