數(shù)據(jù)卸載和微服務實現(xiàn)BSS信控軌跡管理系統(tǒng)

李 峰

（中國聯(lián)合網(wǎng)絡通信有限公司濟南軟件研究院，濟南 250100）

1 引言

電信BSS系統(tǒng)中，信用控制作為高客戶感知模塊，面臨大量客服問題的定位、解釋。客服問題的定位、解釋，需要大量數(shù)據(jù)做支撐，尤其是信控關(guān)鍵要素的變化軌跡數(shù)據(jù)（如余額、欠費、信用度、流量等要素的變化軌跡），以及信控動作發(fā)生時刻的快照信息（如停開機時的余額及欠費情況、是否有逾期欠費等）。在4G時代，用戶每天會產(chǎn)生大量的電信消費行為（以流量為主），導致信控要素變化頻繁，而核心系統(tǒng)的數(shù)據(jù)庫存儲空間有限，無法容納每天將近百億級的軌跡數(shù)據(jù)。為解決軌跡數(shù)據(jù)記錄需求和核心數(shù)據(jù)庫存儲能力不足的矛盾，為信控問題定位、客服解釋留存高價值數(shù)據(jù)，本文給出了可行且經(jīng)過實踐驗證的技術(shù)方案：通過數(shù)據(jù)卸載（涉及技術(shù)包括：數(shù)據(jù)復制如Oracle GoldenGate，簡稱OGG；消息中間件如Kafka；海量數(shù)據(jù)平臺如HBase），借助海量數(shù)據(jù)平臺存放關(guān)鍵要素及快照數(shù)據(jù)，借助微服務提供數(shù)據(jù)訪問接入能力，構(gòu)建完整的信控軌跡管理系統(tǒng)。

2 技術(shù)概述

數(shù)據(jù)復制，是將核心數(shù)據(jù)庫的數(shù)據(jù)通過日志抽取方式，復原數(shù)據(jù)操作步驟，實現(xiàn)數(shù)據(jù)拷貝。電信行業(yè)常用的數(shù)據(jù)復制技術(shù)包括Oracle的OGG、DRDS（阿里云基于MySQL的分布式數(shù)據(jù)庫）的DTS等。其中OGG的應用最為廣泛，本文提及的技術(shù)方案基于OGG技術(shù)。OGG是一種基于日志的結(jié)構(gòu)化數(shù)據(jù)復制軟件，通過捕獲源數(shù)據(jù)庫online redo log（在線重做日志）或archive log（歸檔日志）獲得數(shù)據(jù)變化，形成tail（隊列文件），再將這些tail通過網(wǎng)絡協(xié)議，傳輸?shù)侥繕藬?shù)據(jù)庫，目標端通過解析，插入至目標端數(shù)據(jù)庫，從而實現(xiàn)源端與目標端數(shù)據(jù)同步。

消息中間件也是電信行業(yè)常用技術(shù)解決方案，當前常用的中間件包括Kafka、MQ。本文技術(shù)方案采用Kafka。Kafka是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)，由Apache軟件基金會開發(fā)的一個開源流處理平臺，由Scala和Java編寫。

微服務最早由Martin Fowler與James Lewis于2014年共同提出，微服務架構(gòu)風格是一種使用一套小服務來開發(fā)單個應用的方式途徑，每個服務運行在自己的進程中，并使用輕量級機制通信，通常是HTTP API，這些服務基于業(yè)務能力構(gòu)建，并能夠通過自動化部署機制來獨立部署，這些服務使用不同的編程語言實現(xiàn)，以及不同數(shù)據(jù)存儲技術(shù)，并保持最低限度的集中式管理。本文技術(shù)方案，微服務實現(xiàn)基于spring cloud實現(xiàn)，通過marathon_lb實現(xiàn)服務發(fā)現(xiàn)和負載均衡、采用kong作為API網(wǎng)關(guān)，redis作為緩存服務器。

3 技術(shù)原理及應用

第一步，核心系統(tǒng)收集關(guān)鍵數(shù)據(jù)到Oracle。規(guī)劃需要記錄的要素以及動作快照數(shù)據(jù)。針對每類數(shù)據(jù)設計對應的數(shù)據(jù)表。修改業(yè)務邏輯，收集關(guān)鍵數(shù)據(jù)，寫入Oracle對應表中。需要收集的數(shù)據(jù)分為兩類，一類是關(guān)鍵要素數(shù)據(jù)（余額、欠費、信用度、流量），這些數(shù)據(jù)是業(yè)務判斷的核心維度，這些數(shù)據(jù)的特點是隨著業(yè)務觸發(fā)會不斷更新，且一個用戶一條數(shù)據(jù)。第二類是動作快照類數(shù)據(jù)，當信控動作（如停開機、封頂限速、短信提醒等）發(fā)生時，記錄此類數(shù)據(jù)，作為信控動作解釋依據(jù)，每發(fā)生一次信控動作，記錄一條數(shù)據(jù)。快照數(shù)據(jù)在oracle記錄的特點是日志類特性，只新增不修改，歷史數(shù)據(jù)按月清理，對于一個用戶，隨著對其信控動作的不斷增多，記錄的快照類數(shù)據(jù)也會不斷增加。

第二步，配置核心數(shù)據(jù)表的OGG同步，解析OGG數(shù)據(jù)到Kafka。針對要素表和快照表，配置OGG同步規(guī)則。增加數(shù)據(jù)抽取進程（extract），處理trail文件并按約定格式將消息寫入目標Kafka。根據(jù)要卸載的數(shù)據(jù)量的多少，可以一個表對應一個topic，也可以是多表共用一個topic，為保證數(shù)據(jù)被消費后，仍然可以還原Oracle中的數(shù)據(jù)操作，建議一個topic只有一個分區(qū)，后端只有一個消費進程或線程消費。

第三步，增加Kafka消費進程，卸載數(shù)據(jù)到HBase。增加Kafka消費進程，每個進程并行啟動多個消費線程，每個線程對應一個表的topic。識別Kafka消息的操作標識（insert、update、delete），并對選擇對HBase的響應操作。

需要注意的點：

（1）兩類表的消息類型和HBase操作對應關(guān)系不同。要素類表，需記錄每次要素變化，所以update消息對應到HBase表的insert操作。快照類表，是原表數(shù)據(jù)的拷貝復制，消息類型即是需要對HBase做的操作類型。

（2）需要同時維護HBase數(shù)據(jù)表和索引表，支持非主鍵查詢。HBase數(shù)據(jù)的快速查詢，只支持基于rowkey的單條查詢或者根據(jù)rowkey范圍做scan查詢。且一個表只能有一個rowkey。如果想多維度查詢HBase表，只能借助于異構(gòu)索引。異構(gòu)索引表，是將索引字段作為rowkey，比如用戶標識user_id，而將該用戶標識對應的索引原表記錄的rowkey作為索引記錄的不同列（HBase理論上支持百萬級的列，是列式存儲，不同記錄的列可以不同）。在Kafka消費進程操作HBase時，需要同時維護HBase數(shù)據(jù)表和索引記錄表。

圖2 消息類型與HBase操作對應

圖3 消息類型與HBase操作對應

第四步，借助微服務，實現(xiàn)數(shù)據(jù)能力開放。按照微服務的定義，微服務接口遵循h(huán)ttp的restful，json格式報文。服務應用基于spring cloud開發(fā)，但在整體架構(gòu)上，并未完全采用spring cloud的組件。考慮到項目基于DCOS，所有應用容器化，在Docker容器中運行，而容器化配套技術(shù)方案中的marathon_lb本身具備服務注冊、服務發(fā)現(xiàn)、負載均衡的功能，故采用marathon_lb服務替換spring cloud的eureka。另外鑒于kong是基于ngix實現(xiàn)，使用kong作為api網(wǎng)關(guān)，替換了spring cloud中的zuul。每一個微服務，支持兩種查詢方式，即基于rowkey的直接查詢（單條或scan），以及基于異構(gòu)索引的查詢。針對不同表數(shù)據(jù)量、數(shù)據(jù)特性、使用方式的不同，可以選擇不同的查詢方式。

圖4 微服務技術(shù)架構(gòu)

4 結(jié)束語

以上技術(shù)方案的部分技術(shù)選型，受限于所處BSS系統(tǒng)的整體技術(shù)架構(gòu)。單就要素軌跡管理系統(tǒng)的實現(xiàn)而言，還有其他可選技術(shù)方案。通過要素軌跡的記錄及管理，將信用控制的核心要素數(shù)據(jù)變化及快照數(shù)據(jù)變化完整的記錄下來，通過微服務實現(xiàn)數(shù)據(jù)開放，不論對研發(fā)、運維定位問題，還是外圍自定義查詢，都更為方便、直接。也極大提升了客服人員的問題解釋、數(shù)據(jù)查找的工作效率。