摘要：隨著網(wǎng)絡的應用，計費系統(tǒng)已經(jīng)成為公司所用軟件的核心之一。對企業(yè)計費流程的仔細分析發(fā)現(xiàn)有很多共同之處。如何避免公司功能類似的計費系統(tǒng)的重復開發(fā)呢？本文提出了一個解決方案——基于java的通用計費平臺。平臺采用優(yōu)秀的設計思想和完全模塊化的方法，具有靈活、高效、擴展行好和易于維護等特點。計費平臺可以方便地擴展模塊以滿足公司的實際需要，也可以采用不同的硬件配置以滿足多種性能要求。本文對計費平臺的構架、模塊設計和測試等方面進行了詳盡闡述。

關鍵詞：計費平臺；AOP；ICE；java

Abstract: With the developing of network， Billing System is becoming the core of the compony. Based on carefully analyzed for the procedure of billing of the company， we found that they were similar. The problem is how to avoid repeated development on similar Billing System. A common java-based Billing Platform is supplied. The platform has synthesized several popular and modularization designs ， and offers a flexible， effective， well expansible and maintainable characteristic. It is easy to add new modules to the platform to satisfy the requirement. And it is can take different configuration to fulfill needed performance. This paper mainly concerned on the framework， module design as well as testing.

Keywords: Billing Platform；AOP；ICE；java

1 引言

隨著網(wǎng)絡的應用越來越廣泛，對基于網(wǎng)絡的計費系統(tǒng)的功能和性能要求越來越高。電子商務公司要處理各種各樣的訂單，網(wǎng)絡游戲要進行復雜的收費。不同公司的實際情況都不相同，對計費要求的重點也不一樣。通過抽象計費流程，采用優(yōu)秀的AOP(Aspect-Oriented Programming)[1]設計思想來實現(xiàn)通用的部分，用不同的模塊來實現(xiàn)企業(yè)的不同需求，形成了通用的計費平臺的框架。公司復雜費率的計算問題，可以采用計費引擎來解決。Java以其優(yōu)秀的設計思想，高效的開發(fā)效率，眾多工具的支持和平臺無關性，成為最好的選擇。

2 系統(tǒng)設計思想

計費平臺設計為可以由單臺或多臺計費服務器組成，以滿足不同的性能要求。服務器采用模塊化的設計，兼容多種協(xié)議來接收和回復請求。處理模塊采用多線程的方式，不同的線程處理不同的功能模塊。將系統(tǒng)的通訊模塊和業(yè)務處理模塊分開，降低系統(tǒng)的耦合性。通訊模塊和業(yè)務處理模塊都設計成由幾個單一功能的子模塊組成，他們之間通過請求分發(fā)模塊聯(lián)系。請求分發(fā)模塊分析請求，根據(jù)業(yè)務子模塊注冊的服務類型發(fā)送請求，同時將處理的結果發(fā)送到通訊模塊的發(fā)送隊列。為提高系統(tǒng)的吞吐率，單獨的線程接受請求并進行緩存。

3 系統(tǒng)結構與模塊

3.1 系統(tǒng)設計目標

計費系統(tǒng)是公司的核心之一，具有開放性、高性能、擴展性和易于維護等特點。系統(tǒng)使用優(yōu)秀的設計思想和技術，開放性體現(xiàn)在可以接受多種類型協(xié)議的請求，高性能需要系統(tǒng)具有高吞吐率，擴展性好要系統(tǒng)可以方便地增減模塊以滿足新的需求，易于維護性可以降低系統(tǒng)的維護代價。

3.2 整體架構

如圖1所示。計費平臺主要由以下幾個部分組成。其中，Billing Server是計費服務器，處理具體的計費請求。Coordinator Server 是協(xié)調服務器，保證Billing Server之間的負載平衡，同時完成計費服務器的注冊和注銷服務。C_jdbc Server[2]是數(shù)據(jù)庫簇服務器（或者服務程序），可以將多個DataBase Server模擬成一個DataBase Server簇。Billing Server和DataBase Server數(shù)目可以根據(jù)具體的應用需要作增減。

3.3 計費服務器

如圖2所示，計費服務器Billing Server采用完全的模塊化設計。Provision模塊為通訊模塊，是計費系統(tǒng)對外的接口；Process Pipeline模塊是請求分發(fā)模塊，對請求作預處理后分發(fā)到處理模塊；Service Providers模塊是業(yè)務處理模塊，作實際的處理工作。操作數(shù)據(jù)庫的請求發(fā)送到C_jdbc Server上，由C_jdbc Server完成實際的數(shù)據(jù)庫操作。

4 模塊設計

4.1 Provision模塊設計

Provision模塊是系統(tǒng)的前端，主要負責接受客戶端以不同協(xié)議發(fā)送過來的請求和發(fā)送處理的結果。采用java多線程技術，部分線程負責接受請求數(shù)據(jù)包放入隊列，其余取出請求進行處理，以提高系統(tǒng)的吞吐率?；诎踩脑?，通常用DES或者其他的加密算法來處理傳輸?shù)臄?shù)據(jù)。因為加密解密部分占用系統(tǒng)CPU資源，容易成為系統(tǒng)的瓶頸之一。

具體流程如圖3所示。系統(tǒng)接受請求后，通過解密和轉換格式，發(fā)送到處理模塊。處理完成后，將處理的結果報文封裝成客戶端可以解析的格式，加密以后發(fā)送出去。

Provision模塊目前支持的協(xié)議方式有TCP、UDP、SOAP和ICE協(xié)議方式。

4.2 Process Pipeline模塊的設計

系統(tǒng)中要處理的請求中，如訪問控制、緩存控制、計數(shù)統(tǒng)計、日志、異常處理和請求類型有效性檢查等，可以通過AOP技術來實現(xiàn)。Pipelines中的每個要流經(jīng)的部分稱為filter（過濾器）。請求按指定的順序經(jīng)過filters過濾處理。計費系統(tǒng)需要，事務管理filter可以對指定類型的請求作事務處理，計費filter通過規(guī)則引擎完成費率計算。處理不同方面的filters可以根據(jù)具體的需要增減。設計如圖4所示。

4.3 Service Providers模塊的設計

Service Providers模塊完整具體的業(yè)務邏輯，將業(yè)務邏輯分解為簡單的單功能模塊。Asset Provider完成和用戶資產相關的操作，如賬戶的存款、取款。Provision provider完成對平臺外部系統(tǒng)接口的調用。通過使用ice通訊協(xié)議以獲得較高的開發(fā)效率。Session Provider 處理系統(tǒng)中會話信息，降低數(shù)據(jù)庫的操作頻率以提高系統(tǒng)的性能。具體開發(fā)的時候，可以根據(jù)需要增減模塊來滿足實際的需要。簡單設計如圖5所示。

5 結論

5.1 測試單個計費服務器

測試條件：單個計費服務器運行在Linux9.0上，數(shù)據(jù)庫服務器運行在MS2003 Server上。配置均為P4 2.6G和512M內存。不用Coordinator Server 和C_jdbcServer。

測試結果：數(shù)據(jù)庫服務器滿負荷。如表1所示。

結果分析：單臺計費服務器，可以滿足數(shù)據(jù)庫操作不太頻繁的普通計費要求。要獲得更高的性能，需要通過采用更高配置的數(shù)據(jù)庫服務器。

5.2 測試分布式系統(tǒng)

測試由兩臺計費服務器組成的分布式系統(tǒng)。Coordinator Server 運行在計費服務器1上，C_jdbcServer運行在計費服務器2上。數(shù)據(jù)庫服務器運行在MS 2003 Server上。

測試條件：計費服務器1和計費服務器2均運行在Linux9.0上，數(shù)據(jù)庫服務器運行在MS 2003 Server上。所有服務器配置均為P4 2.6G和512M內存。

測試結果：所有請求都包含數(shù)據(jù)庫寫操作，數(shù)據(jù)庫服務器滿負載。如表2所示。

結果分析：在分布式系統(tǒng)下，性能良好，可以滿足絕大多情況下的服務要求。要獲得更高的性能，需要采用更高的數(shù)據(jù)庫服務器配置和計費服務器配置。

結論：通過測試得出，計費平臺能夠很好地滿足企業(yè)的計費要求。單臺服務器可以滿足請求不太頻繁的計費，適合業(yè)務量不太多的情況。多臺服務器組成的分布式系統(tǒng)，能夠滿足請求頻繁的計費，可以用在大型電子商務、大型網(wǎng)絡游戲和類似情況的計費上。計費系統(tǒng)瓶頸之一是數(shù)據(jù)收發(fā)的加密解密，需要占用較多的CPU資源，占用程度取決于加密算法的復雜度。系統(tǒng)另外一個瓶頸在數(shù)據(jù)庫，數(shù)據(jù)庫性能在較大程度上影響了系統(tǒng)的吞吐率。CPU的占用可以采用高頻的或多個CPU聯(lián)合的方式解決，數(shù)據(jù)庫瓶頸可以采用更好的數(shù)據(jù)庫系統(tǒng)和更高配置的硬件來彌補。

參考文獻

[1]Aspectj project. http://www.Eclipse.org/aspectj/.

[2]C-jdbc.http://c-jdbc.objectweb.org/.

[3]ICE.http://www.zeroc.com/ice.html.

[4]Hibernate.http://www.hibernate.org/.

[5]趙巍，肖璋.短信平臺的設計與維護.計算機工程與設計，2005，26(6):1642-1644.