首頁(yè)>>廠(chǎng)商>>系統集成及應用軟件開(kāi)發(fā)商>>峰華智訊

分布式呼叫中心管理系統技術(shù)實(shí)現

張瑞 2001/05/31

隨著(zhù)現代企業(yè)的分支機構越來(lái)越多，應用系統的負載和數據量也日趨龐大。應用系統經(jīng)過(guò)了主機/終端和客戶(hù)/服務(wù)器結構的歷程，現在正由客戶(hù)/服務(wù)器方式轉向三層結構方式。所謂三層結構是指在客戶(hù)/服務(wù)器兩層結構基礎上加入中間層，中間層叫應用服務(wù)器或中間件，結構如圖1所示。

圖1 應用系統三層結構

CORBA和EJB在技術(shù)上日趨成熟，三層結構的技術(shù)標準也日益完善，與客戶(hù)/服務(wù)器方式相比，三層結構有很多優(yōu)點(diǎn)：

(1) 可實(shí)現應用級和數據庫級的全面分布。應用分為用戶(hù)界面和業(yè)務(wù)邏輯，業(yè)務(wù)邏輯以組件的形式分布在應用服務(wù)器上。服務(wù)器根據需要分布在整個(gè)網(wǎng)絡(luò )的任何節點(diǎn)上，盡管整個(gè)應用在物理上是分布式的，但邏輯上卻是一個(gè)整體。當前的分布式數據庫技術(shù)已經(jīng)非常成熟，能保證分布數據的完整性和一致性。

(2) 實(shí)現大用戶(hù)量、大吞吐量下的負載平衡。隨著(zhù)Internet的迅速發(fā)展，在Web上需要實(shí)現很多關(guān)鍵業(yè)務(wù)（如網(wǎng)上購物、訂票等），這些應用的最大特點(diǎn)是并發(fā)用戶(hù)量大，三層結構比以前的結構更能承擔大業(yè)務(wù)量。三層結構將應用縱向均勻分布在客戶(hù)端、應用服務(wù)器和數據庫服務(wù)器上，橫向分布在多個(gè)應用服務(wù)器和數據庫服務(wù)器上，應用的分布實(shí)現了負載的平衡。因此，在大用戶(hù)量、大吞吐量情況下，仍能迅速響應每個(gè)客戶(hù)端的需求。

(3) 如果使用Java技術(shù)，可實(shí)現應用的跨平臺。Java是一種跨平臺的語(yǔ)言，不論是在客戶(hù)端，還是在應用服務(wù)器上使用Java技術(shù)，都可使應用在一個(gè)操作系統上編寫(xiě)，并能無(wú)縫移植到其他操作系統上。

(4) 能實(shí)現組件級的開(kāi)發(fā)。應用服務(wù)器的組件既能用于傳統的客戶(hù)端，也能應用于Web，提高了代碼的重用率。

(5)中間層的存在，大大提高了數據的安全性。Web或其他客戶(hù)端不直接訪(fǎng)問(wèn)數據庫，從而加強了數據的安全性。

基于以上優(yōu)點(diǎn)，分布式的體系結構目前已被眾多的應用系統所采用。

總體結構和技術(shù)平臺

1. 總體結構

為了更好地說(shuō)明應用服務(wù)器的功能以及應用和數據的分布，需要用一個(gè)實(shí)例描述，因此我們構造了一個(gè)虛擬的應用——分布式呼叫中心管理系統。與傳統的呼叫中心不同，這是一個(gè)全國范圍的呼叫中心，數據、應用和座席需要分布在全國各個(gè)節點(diǎn)。各節點(diǎn)的受理員可受理全國各地的客戶(hù)，并且能訪(fǎng)問(wèn)全網(wǎng)內任何節點(diǎn)的數據，其系統結構如圖2所示。

圖2 分布式呼叫中心系統結構

可以看出：我們把數據庫建在省受理中心（內部數據庫）或其他業(yè)務(wù)部門(mén)（外部數據庫），根據各地的需求，一個(gè)應用服務(wù)器可對應一個(gè)或多個(gè)數據庫服務(wù)器。應用服務(wù)器細分為業(yè)務(wù)邏輯和數據邏輯，業(yè)務(wù)邏輯響應客戶(hù)端的請求，從客戶(hù)端獲得參數，返回結果，業(yè)務(wù)邏輯的組件將整個(gè)業(yè)務(wù)封裝，業(yè)務(wù)邏輯調用數據邏輯，實(shí)現對不同地點(diǎn)異構數據庫的訪(fǎng)問(wèn)。

受理席可以是中心內部的受理席或遠程外包受理席；客戶(hù)端為普通Windows應用，瀏覽器為動(dòng)態(tài)HTML（CGI、ASP、JSP）和Java Applet。它們都是瘦客戶(hù)端，僅有用戶(hù)界面，可訪(fǎng)問(wèn)應用服務(wù)器的業(yè)務(wù)邏輯; 業(yè)務(wù)可由插件的方式改變，這些都可通過(guò)應用服務(wù)器的業(yè)務(wù)邏輯改變來(lái)實(shí)現。 整個(gè)系統網(wǎng)絡(luò )連接由TCP/IP上層協(xié)議CORBA、Http、Socket實(shí)現。

2. 技術(shù)平臺

各個(gè)關(guān)鍵模塊都采用了當前流行和通用的技術(shù)平臺。中間件采用EJB(Enterprise Java Beans)技術(shù)實(shí)現分布式應用技術(shù); Java使應用具有跨平臺特性，即在一個(gè)操作系統平臺上編寫(xiě)的程序移植到其他操作系統平臺上時(shí)，不用修改源代碼。

利用中間件中的數據邏輯，使應用無(wú)需改變客戶(hù)端即可訪(fǎng)問(wèn)其他節點(diǎn)的數據。應用分布式數據庫可實(shí)現整個(gè)系統數據的完整性和一致性。

客戶(hù)端可用普通Windows應用、JSP/ASP/CGI、Java等實(shí)現，通過(guò)IIOP協(xié)議訪(fǎng)問(wèn)應用服務(wù)器的業(yè)務(wù)邏輯。異地的受理席之間語(yǔ)音傳輸用VoIP實(shí)現。

1. 應用和數據分布產(chǎn)生的問(wèn)題

(1) 應用分布產(chǎn)生的問(wèn)題

由于整個(gè)網(wǎng)絡(luò )內的客戶(hù)端和應用服務(wù)器眾多，有以下3個(gè)問(wèn)題需要解決：客戶(hù)端該如何確定請求哪個(gè)應用服務(wù)器；客戶(hù)端如何調用遠程應用服務(wù)器的組件; 各應用服務(wù)器之間如何協(xié)調工作。

(2) 數據分布產(chǎn)生的問(wèn)題

由于客戶(hù)端的數據可能同時(shí)取自多個(gè)點(diǎn)，所以任何一個(gè)客戶(hù)端都可能要同時(shí)訪(fǎng)問(wèn)異地數據庫，并且需要訪(fǎng)問(wèn)IP地址經(jīng)常變化的數據庫。因此，若需要新增一個(gè)節點(diǎn)時(shí)，需考慮系統的應用和數據如何劃分，客戶(hù)端如何使正在處理中的業(yè)務(wù)實(shí)現平穩過(guò)渡。

2. 解決的方法

(1) 應用分布問(wèn)題的解決

應用分布問(wèn)題可通過(guò)設計客戶(hù)端和應用服務(wù)器的訪(fǎng)問(wèn)規則來(lái)解決。訪(fǎng)問(wèn)應遵循以下規則: 每一客戶(hù)端有且只有一個(gè)應用服務(wù)器為之服務(wù)，一般是該客戶(hù)端本地的應用服務(wù)器；客戶(hù)端需要訪(fǎng)問(wèn)遠程服務(wù)器時(shí)應該通過(guò)為之服務(wù)的應用服務(wù)器; 每個(gè)應用服務(wù)器都運行所有業(yè)務(wù)邏輯組件和它訪(fǎng)問(wèn)的數據庫的數據邏輯組件，在業(yè)務(wù)量大的中心可做群集（Cluster）。

解決數據分布的問(wèn)題稍為復雜，首先要確定數據存放原則和數據訪(fǎng)問(wèn)規則。

數據存放的原則：采用分布式數據庫，對業(yè)務(wù)性數據采取就近分布存儲的策略，而對于控制性數據則利用事務(wù)日志來(lái)保持各點(diǎn)數據的一致性。系統應用同時(shí)支持數據的遠程訪(fǎng)問(wèn)，支持大吞吐量的聯(lián)機事務(wù)處理，支持災難恢復。 數據訪(fǎng)問(wèn)的規則: 每個(gè)客戶(hù)端有且只有一個(gè)連接的應用服務(wù)器，每一數據庫有且只有一個(gè)連接的應用服務(wù)器。而每個(gè)應用服務(wù)器可有多個(gè)客戶(hù)端，也可連接多個(gè)數據庫服務(wù)器。通過(guò)建立多個(gè)連接緩存的方法，實(shí)現不同節點(diǎn)和異構數據庫的訪(fǎng)問(wèn)。如圖3所示。

圖3 數據訪(fǎng)問(wèn)

為了實(shí)現遠程的訪(fǎng)問(wèn)，需要在每一節點(diǎn)有應用服務(wù)器與數據庫對照表和遠程調用的方法。應用服務(wù)器與數據庫對照表記錄的是被使用的應用服務(wù)器和數據庫連接緩存的關(guān)系。

對每一個(gè)客戶(hù)端訪(fǎng)問(wèn)數據的請求，由遠程調用方法確定客戶(hù)端調用的數據是本地的還是遠程的。若是本地，可通過(guò)本地應用服務(wù)器的數據邏輯直接訪(fǎng)問(wèn); 若為遠程，查詢(xún)對照表確定調用哪個(gè)遠程應用服務(wù)器，再通過(guò)本地應用服務(wù)器訪(fǎng)問(wèn)該遠程服務(wù)器，實(shí)現數據訪(fǎng)問(wèn)。遠程數據訪(fǎng)問(wèn)過(guò)程如圖4所示。

圖4 遠程數據訪(fǎng)問(wèn)過(guò)程

在圖4中，訪(fǎng)問(wèn)順序為：

A點(diǎn)客戶(hù)端→A點(diǎn)應用服務(wù)器→B點(diǎn)應用服務(wù)器→B點(diǎn)數據庫。這一調用程序說(shuō)明了，客戶(hù)端是如何同時(shí)通過(guò)應用服務(wù)器訪(fǎng)問(wèn)本地和遠程數據庫。

當增減應用服務(wù)器節點(diǎn)時(shí)，需要增減對照表記錄，各節點(diǎn)對照表的一致性通過(guò)數據庫日志來(lái)保持。當增加數據庫節點(diǎn)時(shí)，將舊數據庫中的數據根據數據存放原則轉入新數據庫(無(wú)論是處理完成或正在處理的的業(yè)務(wù)數據都轉入)，在舊數據庫中做數據移動(dòng)的日志，同時(shí)修改應用服務(wù)器和數據庫對照表。

維護工作量的評估

1. 新增節點(diǎn)工作量的評估

新增節點(diǎn)可分為3個(gè)層次：只需客戶(hù)端、需應用服務(wù)器和需數據庫服務(wù)器。

只需客戶(hù)端: 只需安裝客戶(hù)端軟件，并將其連接到應用服務(wù)器上。

需應用服務(wù)器: 需在新節點(diǎn)安裝應用服務(wù)器，同時(shí)需修改各應用服務(wù)器和數據庫對照表。

需數據庫服務(wù)器: 需在新節點(diǎn)安裝數據庫服務(wù)器，將其連接到應用服務(wù)器，增加應用服務(wù)器的數據庫連接緩存; 還需分離原節點(diǎn)中的數據到新節點(diǎn)，同時(shí)記錄轉移日志。

2. 平臺移植工作量評估

操作系統平臺的移植: 支持所有主流Unix平臺和NT平臺，移植到不同平臺上。由于代碼是由Java編寫(xiě)，所以改變操作系統平臺時(shí)無(wú)需改變代碼。

數據庫平臺：支持ODBC、JDBC和其他專(zhuān)用數據庫專(zhuān)用接口。對以上接口的支持，保證了對主流數據庫平臺的支持。數據庫平臺的改變只需改變數據邏輯，而無(wú)需更改業(yè)務(wù)邏輯和客戶(hù)端。

3. 客戶(hù)端或應用服務(wù)器代碼改變

應用服務(wù)器數量有限，客戶(hù)端卻數量眾多，為減少工作量，應盡可能將修改工作放在應用服務(wù)器端。

在三層結構中，客戶(hù)端為瘦客戶(hù)端，只有用戶(hù)界面。因此只有用戶(hù)界面發(fā)生變化時(shí)，才需改變客戶(hù)端; 若是業(yè)務(wù)發(fā)生變化時(shí)，則只需改變應用服務(wù)器的組件。

4. 安裝和日常管理工作量

安裝: 對于只進(jìn)行業(yè)務(wù)處理的部門(mén)和只需受理客戶(hù)端軟件的部門(mén)，可從統一網(wǎng)址下載軟件，安裝即可使用。對于需要應用服務(wù)器和數據庫服務(wù)器的部門(mén)，需技術(shù)人員現場(chǎng)安裝。

維護: 對于應用服務(wù)器組件的升級，技術(shù)人員可遠程操作。客戶(hù)端軟件的升級需用戶(hù)從網(wǎng)上下載，重新安裝。