數據卸載和微服務實現BSS信控軌跡管理系統

李 峰

（中國聯合網絡通信有限公司濟南軟件研究院，濟南 250100）

1 引言

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

2 技術概述

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

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

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

3 技術原理及應用

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

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

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

需要注意的點：

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

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

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

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

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

圖4 微服務技術架構

4 結束語

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