基于ｊａｖａ的一種通用計費平臺的設計和實現

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

關鍵詞：計費平臺；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 引言

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

2 系統設計思想

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

3 系統結構與模塊

3.1 系統設計目標

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

3.2 整體架構

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

3.3 計費服務器

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

4 模塊設計

4.1 Provision模塊設計

Provision模塊是系統的前端，主要負責接受客戶端以不同協議發送過來的請求和發送處理的結果。采用java多線程技術，部分線程負責接受請求數據包放入隊列，其余取出請求進行處理，以提高系統的吞吐率。基于安全的原因，通常用DES或者其他的加密算法來處理傳輸的數據。因為加密解密部分占用系統CPU資源，容易成為系統的瓶頸之一。

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

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

4.2 Process Pipeline模塊的設計

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

4.3 Service Providers模塊的設計

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

5 結論

5.1 測試單個計費服務器

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

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

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

5.2 測試分布式系統

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

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

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

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

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

參考文獻

[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.