摘要：為了解決準實時計費系統有較高的欠費風險，智能網系統數據業務支持能力及靈活性不足等問題，提出了一種實時融合計費系統的設計實現方法。采用了可定制規則分揀的預處理引擎、基于適配器模式的批價引擎和嵌入式腳本等方法，滿足了靈活的多種業務融合計費需求；同時，還采用了多級消息分發、共享內存數據庫等方法，保證了系統的實時性。經過測試實驗獲得系統消息平均響應時間99．9％小于400ms，系統單節點支持用戶數由現在的300萬提升到2000萬，混合呼叫處理能力由現在的2400Caps提升到4000Caps；解決了現有計費系統實時性差、對數據業務支持能力不足、不能處理海量數據等問題；具有高實時性、高可擴展性、高靈活性等特點。
　　
　　引言
　　
　　隨著國內運營商紛紛進入全網運營一體化時代，對于具備、寬帶、移動通信等多種網絡業務的運營商來說，融合各種業務為用戶提供具有個性化、多樣化以及差異化的服務是取得競爭優勢的關鍵。計費系統是全業務運營支撐系統之中的核心系統，必須滿足實時性、全業務融合、高擴展性和統一客戶視圖等需求。目前國內外各大電信運營商均在使用傳統的準實時計費系統以及智能網系統，兩套系統獨立運行。準實時計費系統是離線計費系統的一種，其特點是計費系統以聯機方式得到使用記錄后，馬上進行計費，以盡可能縮短用戶使用與計費之間的時間差，但計費系統不參與服務使用過程，而是在服務使用過程結束后根據使用記錄進行計費。經過多年的實踐證明，越來越高的欠費風險是傳統準實時計費系統的致命弱點。智能網系統具備實時計費能力，但業務資費靈活性不夠，對數據業務支持能力不足，新業務開發速度慢，又無法適應市場復雜靈活的變化要求。
　　
　　為了滿足新一代計費系統的需求，3GPP組織提出了在線計費系統（OCS）的參考結構，給出了具有開放性和通用性的實時計費系統框架，支持承載層、會話層和應用層的統一計費。在此參考結構基礎上，本文基于SOA架構，采用可定制規則分揀的預處理引擎、高擴展性的批價引擎以及共享內存數據庫等技術設計實現了一種具有高實時性、高可擴展性和高靈活性的新一代實時融合在線計費系統。
　　
　　1、系統架構
　　
　　在線計費指計費信息可以實時影響業務的提供、帳戶余額可以實時更新的計費機制，可分為基于事件型和基于會話型的在線計費。會話型的典型例子是用戶打，需要持續一段時間；事件型的典型例子是發短信，一次消息觸發一次計費。以會話型計費在線計費為例，用戶通話過程中消息可分為三種：初始化消息，更新消息和結束消息。用戶通話一開始發送初始化消息，然后系統根據事先設定的預留策略（比如3min），定時發送更新消息直至用戶通話結束，之后向在線計費系統發送結束消息，在線計費系統則在線實時采集這些消息進行鑒權、預留、計費、扣費，一旦用戶余額不夠一次預留量，則根據余額反算時長，將時長通知網元，網元在用戶達到時長后停止用戶通話。
　　
　　在線計費系統架構圖如圖1所示。　　
　　由在線采集模塊負責采集話單文件及在線消息，并轉化為統一格式消息進行主機級消息分發。計費消息調度模塊負責消息的接收與發送以及消息的進程級分發。計費控制模塊接收到計費消息后進行協議解析，生成計費事件，并根據計費事件類型及數據庫數據分別由預處理引擎、批價引擎、余額管理和會話管理處理，實現基于會話承載的計費、基于內容事件的計費以及用戶賬戶管理。zui后，系統通過話單生成程序將業務使用記錄和計費結果保存到CDR文件中。　　
　　為了滿足未來海量數據處理的需要以及系統擴容的需求，系統采用主機級消息分發和進程級消息分發兩級分發策略。其中主機級消息分發由運行于IMPDiameterServer上的在線采集模塊負責。如圖2所示，IMPDiameterServer在收到信用控制請求包（CCR）后，會根據CCR中的用戶標識信息以及共享內存數據庫中的路由策略（如用戶、地域、號段、網絡設備等）來決定將這個CCR分發給那一個在線計費系統（OCS）主機進行處理。在OCS主機收到CCR后，計費消息調度模塊中的分發進程會根據CCR的業務類型和OCS進程的負載情況將CCR包指派給某個具體的OCS進程進行處理。
　　
　　2、在線計費控制
　　
　　2．1預處理引擎
　　
　　隨著電信業務的發展，需要越來越靈活的資費套餐，這就需要多種多樣、可靈活配置的擴展計費信息。另一方面，通信網元的多樣化，使得原始計費信息變化較大。怎樣把原始信息靈活轉換成擴展計費信息就成為預處理引擎設計的關鍵。傳統的預處理方法對于新的業務和規則，一般都是通過修改程序代碼來實現的，這樣給程序的管理和維護帶來了很大的困難，而且風險比較高。
　　
　　本文提出了一種基于可定制規則分揀的預處理引擎，該引擎可以根據不同網元的業務需求，靈活地配置并驗證邏輯，規整統一的批價接口，從而實現了全業務的融合。同時，由于不需要修改程序，系統維護方便且風險極小。
　　
　　2．2批價引擎
　　
　　批價引擎是在線計費的核心組件。隨著資費策略越來越復雜，傳統的基于參數表驅動或簡單規則驅動的計費引擎表達起來越來越困難，計費引擎越做越復雜，擴展性也越來越差，維護代價越來越高。為了解決這一問題，采用適配器（Adapter）的設計模式以及嵌入腳本技術實現了一種高可擴展性的通用批價引擎。基于適配器模式的批價引擎分為三層，分別是核心層、適配器層和原始數據層，如圖3所示。　　
　　對一次性費用計算、使用費計算、周期費用計算和優惠計算等提供統一的屬性訪問接口，使得費用計算和數據源的變化無關，實現通用的費用計算引擎。當增加新的業務（新的格式、內容）時，只要增加實現一個適配器就可以被批價引擎接受。傳統的資費模型通常通過用戶資料中的多個屬性，組合運算后得到若干條資費規則，資費規則只有在程序運行時才知道用戶適用的資費。資費配置后是否正確生效具有不確定性。基于適配器模式的批價引擎采用了資費規則包的資費模型，形成可供用戶選擇的資費計劃，這樣用戶所匹配的資費規則可以從用戶資料中直接查詢出來，可靠性更能得到保證。通過對各種話單、事件進行分析，資費配置和對抽象的“事件屬性”進行定義，對新的網絡（業務）計費只要在基礎數據配置表中增加相應的事件屬性描述即可。
　　
　　為了解決基于C／C++語言實現的批價引擎可擴展性差的問題，批價引擎還創新性的采用了嵌入Python腳本技術，利用C++程序運行時的動態解析Python腳本和Python本身強大的表達能力，可以使計費規則的表達無限靈活。Python語言是面向對象的腳本語言，同時也支持傳統的結構化編程，具有很好的動態解釋性。復雜的資費策略可以通過腳本實現。腳本就像插件一樣，可以根據需要任意配置，極大地提高系統的表達能力和擴展性。為運營商提供強大的運營支撐能力，方便運營商的業務快速推出和開展。
　　
　　2．3虛擬余額技術
　　
　　傳統的計費系統沒有虛擬余額的概念，只支持一種余額類型，即金額。其他類型的消費都要轉換為金額才能實現。隨著電信業務的發展，各種各樣的基于時長、次數、流量等消費的方式越來越多，都轉成金額也是一種方式，但不靈活。在余額管理模塊設計中，系統引入了虛擬余額的概念。系統支持用戶的余額可以是除了金額外的其他類型“余額”，如時長、次數、流量等。同時支持虛擬類型的擴充，有效增加用戶消費的方式，方便電信業務的拓展。
　　
　　3、共享內存數據庫
　　
　　計費系統中各種業務程序需要對數據庫中的數據進行頻繁的查詢操作，涉及的數據量非常巨大，訪問數據庫的頻率很高，由此產生過多的數據庫交互導致程序性能降低。使用共享內存技術將數據庫待查詢的數據上載到業務程序所在的系統內存中，結合業務需求建立快速有效的查詢方式，提高查詢速度，減少對數據庫性能的依賴。
　　
　　根據需要查詢的數據量，在系統內存中開辟足夠的共享內存段，用于存放數據記錄。同時根據數據查詢的需求建立對應的查詢方式（即建立索引），創建對應的共享內存段，用于存放索引及輔助維護數據。共享內存數據庫框架如圖4所示。　　
　　守護進程根據預先定義，查詢并獲取數據庫中的原始數據，經過處理形成需要存放的記錄并插入共享內存的數據段，同時根據查詢方式形成對應的索引記錄，插入共享內存的索引段。在數據被批量上載后，業務進程可以連接共享內存，先訪問索引段，然后獲取對應的數據記
　　
　　錄。數據庫數據發生變動時，守護進程根據相應的機制獲取變動的數據，依照前面業務進程查詢數據的方法，如果找到數據就更新，如果沒找到就插入新記錄。
　　
　　4、結語
　　
　　隨著電信技術的不斷發展，傳統的準實時計費系統已不能滿足電信運營商的需求。本文設計了一種實時融合認證在線計費系統，該系統采用可定制規則分揀的預處理引擎、基于適配器模式的批價引擎和嵌入式腳本等技術滿足了靈活的多種業務融合計費需求。同時，該系統還采用了多級消息分發、共享內存數據庫等技術，保證了系統的實時性。該系統消息平均響應時間99．9％小于400ms。系統單節點支持用戶數由現在的300萬提升到2000萬，系統容量提升后，一般的電信企業部署單節點，zui多兩個節點即可滿足容量要求。系統的單節點混合呼叫處理能力由現在的2400CaPs提升到4000Caps。數據處理性能提升后，將能滿足未來海量數據處理的需要。