基于SOA架構的新一代計費清算系統設計與實現

中國移動（深圳）有限公司 | 肖中卿 鄭錫濤 付兵蘭

新一代計費清算系統引入SOA，打破原有封閉式架構，實現計費清算服務可復用，通過構建統一服務接入框架，降低遺留系統接入新架構的接入成本，為計費清算系統集中化運營運維提供了技術保障。

近年來，互聯網尤其是移動互聯網的迅猛發展給傳統電信業帶來了極大挑戰，業界正式進入無邊界競爭時代。作為業務支撐系統核心的計費清算系統也日益不能滿足大數據、大業務量的支撐要求，迫切需要進行變革升級。

深圳公司承擔著全集團漫游清算業務的集中清結算處理，并對國際運營商提供漫游清算服務。隨著業務的迅速擴張，深圳公司形成了三套清算系統，十多條業務線的運營規模，每條業務線均獨立建設，這種粗放的煙囪式建設，雖然快速地滿足了一段時期內的業務需求，然而隨著系統的增多，系統間依賴越來越多，越來越復雜，同時由于封閉式的架構，造成已有資源復用難度大，運營運維成本高昂。在此背景下，要求新一代計費清算系統架構，具備以下能力：

1.集中化支撐能力。提供統一的公共基礎平臺和通用業務能力，對原有獨立建設的清算業務線進行融合，降低建設與維護成本。

2.分布式云化能力。從傳統集中計算架構向分布式云化架構演進，降低總體成本，提升并發處理能力，適應大數據時代流量經營要求。

3.標準化，集中化運營。打造以客戶感知為中心的界面，改善客戶體驗，通過產品模型構建，實現產品靈活組合，促進標準化，具備個性化定制能力。

4.開放共享能力。從封閉系統向“生態系統”的共享開放平臺轉型，整合價值鏈，提升協同能力。

針對以上服務化、分布式云化的要求，采用SOA技術并結合云計算技術進行架構規劃與設計是可選方案之一。

圖1 新一代計費清算系統應用架構

系統架構

新一代計費清算系統架構規劃過程中，采用TOGAF方法論對現有計費清算系統基線架構進行梳理，并對目標業務架構、應用架構、數據架構技術架構進行規劃。

根據業務架構規劃，按照CBM方法論，結合TMF的eTom模型及集團NGBOSS模型，將業務域劃分為服務支撐域、產品運營域、客戶運營域、運營分析域與運營管理域，相應了為了滿足對業務架構的支撐，應用架構劃分為服務支撐平臺、產品運營平臺、客戶運營平臺、數據分析平臺、運營管理平臺，如圖1所示。

圖2 數據清算一級流程

服務支撐平臺：服務支撐平臺提供可重用的基礎計費清算服務，為產品運營提供可選的計費清算服務，并保證所提供服務滿足服務質量的要求。

產品運營平臺：產品運營平臺以產品為中心組織產品、服務、資源等相關業務過程和業務能力，實現清算服務能力的產品化交付，并實現業務的產品化運營。

客戶運營平臺：客戶運營平臺以客戶為中心組織營銷、服務、收入相關的業務過程和業務能力，將計費清算產品推廣到客戶端，實現面向客戶的運營，快速響應客戶請求，以提升客戶滿意度和貢獻度。

運營管理平臺：面向運營管理人員，實現對服務支撐、產品運營、客戶運營進行管理、評價和改進，實現計費清算流程的運營和管理，為運營管理人員提供統一的管控視圖。

數據分析平臺：基于基礎運營數據為客戶或管理者提供經營分析、運營分析和管理決策，提供統一、專業、智能的分析能力。

圖3 文件預處理子流程

系統設計與實現

新一代計費清算系統SOA架構，采用Oracle SOA Suite 11g進行具體落地實施。本節將從流程、服務、組件的實現不同層面對整體SOA架構的設計與實現進行詳細描述。

設計原則

由于SOA架構與傳統架構在架構理念和風格上都有不同，需要在實施前期明確相應的設計原則，結合SOA設計理論與具體實踐，我們總結的新架構需要遵循的設計原則包括：

1.服務無狀態原則。在無特別需求的情況下，服務不能長期保存當次服務請求的中間處理狀態信息，是服務狀態無關。

2.服務可重用性原則。服務須盡量設計為可重用服務，可重用服務接口設計不能包含特定服務消費者的假設。

3.服務標準化原則。要求對服務的規約進行標準化，保持統一的設計風格。

4.服務松耦合原則。消費者不與具體實現相耦合，服務規約不與具體服務實現相耦合。

5.服務抽象原則。服務規約僅僅暴露消費者需要的信息。

消息定義規范

新一代計費清算系統各平臺遵循SOA規范，采用XML格式進行消息編碼，采用xsd格式進行消息定義。消息文本采用UTF-8進行編碼。統一的消息定義包括消息頭和消息體，消息頭定義各平臺均需要遵守的消息字段。

請求消息頭詳細定義。包含流程上下文協調ID，服務請求編號，服務消費者，業務流水號，業務受理時間，事務性標志，事務ID，客戶代碼，產品代碼，服務名稱，服務調用方法名稱，平臺編號，認證授權碼，消息過期時間，消息生存期。

響應消息頭與請求消息頭內容基本相同，只是在請求消息頭基礎上，新增了響應代碼和詳細相應信息。具體包含流程上下文協調ID，服務請求編號，服務消費者，業務流水號，事務標志，事務ID，客戶代碼，產品代碼，服務名稱，服務調用方法名稱，平臺編號，認證授權碼，響應消息創建時間，消息過期時間，消息生存期，響應代碼，詳細響應信息。

BPEL流程層設計與實現

新一代計費清算系統采用BPEL（Business Process Execution Language）進行流程設計，具體過程遵循SOMA方法論的建模、設計與實現過程。以計費清算核心的數據清算流程為例，一級BPEL流程如圖2所示。

數據清算總流程包括文件上傳、文件預處理、下發傳輸三個子流程。其中文件預處理子流程為數據清算核心流程，其主要過程如下圖3所示（實際流程更復雜，限于篇幅，此處為簡化流程）。

文件預處理具體過程如下：

1.接受處理請求，調用文件狀態服務，判斷文件是否已經在處理或已經處理，如果文件已處理則流程結束，對文件進行備份。

2.調用賬期日服務，獲取并更新賬期日。

3.發起話單校驗服務，如果校驗不通過則流程處理結束。

4.發起查重校驗服務，如果校驗不通過，則查重回退，流程結束。

5.發起結果發布服務，如果結果發布不通過，則結果發布回退，流程結束。

6.發起異步入庫調用，進行異步入庫。

BPEL流程開發采用Oracle JDeveloper Studio工具，數據清算總流程實現的是one-way流程，并可以對外暴露為一個webservice服務，供DataClearingService（數據清算總流程封裝服務）在收到目錄檢測輸出消息時進行調用。

整個流程分為3個部分：receiveInput、ICTransfer、PremainProcess。

1.receiveInput：流程調用的起始節點，接受從DataClearingService輸入的消息，消息類型為DirDetectOutput（目錄檢測服務的輸出消息）。

2.ICTransfer：異步調用ICTransferProcessService（上發傳輸流程封裝服務），進行上發傳輸流程；在Receive節點設置超時機制，目前超時時間設置為900秒。

3.PremainProcess：以one-way的方式調用預處理流程的封裝服務。預處理流程實現的是異步流程，并可以對外暴露為一個webservice服務。

圖4 新一代架構與傳統架構系統調度性能對比

OSB服務層設計與實現

OSB（Oracle Service Bus）服務層在整個SOA核心架構中承擔服務封裝、消息流轉換與預處理、協議轉換等功能。支持多協議、多渠道的通訊方式及異構系統間交互。OSB層中服務封裝主要有兩種類型的服務，一種是業務服務(Business Service)，另外一種是代理服務（Proxy Service）。業務服務會直接綁定具體的服務組件地址，比如JMS的URI或者WebServices的URI；代理服務主要負責消息格式轉換、消息路由與異常處理。代理服務是OSB服務層對外暴露的接口。在新一代計費清算架構中同時使用到了同步服務與異步服務，一般來說對于響應時間短的服務設計為同步服務，響應時間長的設計為異步服務。

同步服務由一個代理服務和一個業務服務組成。代理服務會通過路由方式調用業務服務。服務調用通過代理服務，路由到業務服務，業務服務可通過配置輸入、輸出隊列與具體的業務組件進行交互，代理服務同步等待業務服務的處理返回。

異步服務相比同步服務的特點在于，調用者發起調用之后不阻塞等待，調用結果通過反向回調通知到調用方。請求代理服務接收到請求后調用請求業務服務，請求業務服務與業務組件通過JMS隊列進行驅動交互。業務組件處理完業務邏輯后將處理結果以消息方式回寫到響應隊列，響應代理服務通過監聽響應隊列的方式由消息負責驅動進行業務服務的回調。

OSB層中異步服務由兩個代理服務和兩個業務服務組成。代理服務中包括請求代理服務和響應代理服務。請求代理服務負責請求消息的格式轉換、請求日志記錄與路由并調用請求業務服務；響應代理服務負責響應消息的格式轉換、請求日志記錄與路由并調用響應業務服務。

圖5 新一代架構與傳統架構調度性能對比

組件層設計與實現

由于服務支撐平臺涉及遺留C++系統組件的集成，綜合考慮各種封裝方式，采用隊列方式能方便系統遷移改造。整個服務支撐平臺包括如下三類隊列：事件通知隊列，用于記錄處理事件的隊列，主要消費者為訂閱了事件主題的外部或內部組件（事件觀察器）；處理隊列，業務服務處理的核心處理隊列，包括輸入（請求）隊列、響應（輸出）隊列；異常隊列，為消息處理異常情況下，對消息的備份，支持人工介入處理。在具體進行SOA新架構遷移中，新一代計費清算架構在設計之初即考慮構建統一的服務接入框架，將具體SOA技術進行屏蔽，盡量降低架構遷移的工作量。服務接入框架實現的主要功能包括：1.JMS消息隊列讀寫。構建統一的JMS隊列訪問機制，保證消息存取的事務性。2.消息解析與生成。對獲取的消息統一解析為業務實體，并將處理結果組裝為返回消息，這樣具體服務組件只需對業務實體進行處理，無需關心具體消息結構。3.通用消息處理機制。框架封裝了統一的消息處理流程，包括異常消息處理、消息處理日志。4.統一數據層訪問。框架對清算話單訪問提供多種數據層訪問機制，當前支持包括本地文件系統、分布式緩存、分布式文件系統。

服務框架的構建使得具體的服務遷移工作量大大降低，也保證了遺留組件遷入SOA架構的質量。

系統實施效果

新一代計費清算系統已經部署并行，通過采集原有生產系統與并行環境進行性能指標對比，顯示計費清算服務以及計費服務處理性能上，新一代計費清算架構都有明顯的提升。

系統調度性能

相比原有傳統架構，采用單機進程調度，依賴于數據庫讀寫速度。新一代清算架構，采用SOA消息調度，支持分布式調度，且消息走內存和網絡方式，不與數據庫交互，效率提升約46%。

系統平均處理性能

由于調度性能的提升以及降低了數據庫IO的讀寫以及部分處理環節的優化，HPUX部署方式下，整體平均處理性能由原有的609TPS，提升到877TPS，提升44%，云計算部署方式下，性能提升到1209TPS，提升99%。

新一代計費清算系統引入SOA，打破原有封閉式架構，實現計費清算服務可復用，通過構建統一服務接入框架，降低遺留系統接入新架構的接入成本，為計費清算系統集中化運營運維提供了技術保障；整體架構實現分布化，對原有組件進行X86化改造，具備部署云計算平臺的能力，使得系統架構具備橫向擴展能力，相比原有架構，系統在性能、可靠性、可擴展性方面都有較大提升。當然，整體架構還有很多問題待完善解決，這些問題將在后續項目中逐步得到完善和徹底解決。