張瑞 2001/05/31

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

圖1 應用系統三層結構

CORBA和EJB在技術上日趨成熟，三層結構的技術標準也日益完善，與客戶/服務器方式相比，三層結構有很多優點：

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

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

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

(4) 能實現組件級的開發。應用服務器的組件既能用于傳統的客戶端，也能應用于Web，提高了代碼的重用率。

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

基于以上優點，分布式的體系結構目前已被眾多的應用系統所采用。

總體結構和技術平臺

1. 總體結構

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

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

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

受理席可以是中心內部的受理席或遠程外包受理席；客戶端為普通Windows應用，瀏覽器為動態HTML（CGI、ASP、JSP）和Java Applet。它們都是瘦客戶端，僅有用戶界面，可訪問應用服務器的業務邏輯; 業務可由插件的方式改變，這些都可通過應用服務器的業務邏輯改變來實現。 整個系統網絡連接由TCP/IP上層協議CORBA、Http、Socket實現。

2. 技術平臺

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

利用中間件中的數據邏輯，使應用無需改變客戶端即可訪問其他節點的數據。應用分布式數據庫可實現整個系統數據的完整性和一致性。

客戶端可用普通Windows應用、JSP/ASP/CGI、Java等實現，通過IIOP協議訪問應用服務器的業務邏輯。異地的受理席之間語音傳輸用VoIP實現。

1. 應用和數據分布產生的問題

(1) 應用分布產生的問題

由于整個網絡內的客戶端和應用服務器眾多，有以下3個問題需要解決：客戶端該如何確定請求哪個應用服務器；客戶端如何調用遠程應用服務器的組件; 各應用服務器之間如何協調工作。

(2) 數據分布產生的問題

由于客戶端的數據可能同時取自多個點，所以任何一個客戶端都可能要同時訪問異地數據庫，并且需要訪問IP地址經常變化的數據庫。因此，若需要新增一個節點時，需考慮系統的應用和數據如何劃分，客戶端如何使正在處理中的業務實現平穩過渡。

2. 解決的方法

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

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

解決數據分布的問題稍為復雜，首先要確定數據存放原則和數據訪問規則。

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

圖3 數據訪問

為了實現遠程的訪問，需要在每一節點有應用服務器與數據庫對照表和遠程調用的方法。應用服務器與數據庫對照表記錄的是被使用的應用服務器和數據庫連接緩存的關系。

對每一個客戶端訪問數據的請求，由遠程調用方法確定客戶端調用的數據是本地的還是遠程的。若是本地，可通過本地應用服務器的數據邏輯直接訪問; 若為遠程，查詢對照表確定調用哪個遠程應用服務器，再通過本地應用服務器訪問該遠程服務器，實現數據訪問。遠程數據訪問過程如圖4所示。

圖4 遠程數據訪問過程

在圖4中，訪問順序為：

A點客戶端→A點應用服務器→B點應用服務器→B點數據庫。這一調用程序說明了，客戶端是如何同時通過應用服務器訪問本地和遠程數據庫。

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

維護工作量的評估

1. 新增節點工作量的評估

新增節點可分為3個層次：只需客戶端、需應用服務器和需數據庫服務器。

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

需應用服務器: 需在新節點安裝應用服務器，同時需修改各應用服務器和數據庫對照表。

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

2. 平臺移植工作量評估

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

數據庫平臺：支持ODBC、JDBC和其他專用數據庫專用接口。對以上接口的支持，保證了對主流數據庫平臺的支持。數據庫平臺的改變只需改變數據邏輯，而無需更改業務邏輯和客戶端。

3. 客戶端或應用服務器代碼改變

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

在三層結構中，客戶端為瘦客戶端，只有用戶界面。因此只有用戶界面發生變化時，才需改變客戶端; 若是業務發生變化時，則只需改變應用服務器的組件。

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

安裝: 對于只進行業務處理的部門和只需受理客戶端軟件的部門，可從統一網址下載軟件，安裝即可使用。對于需要應用服務器和數據庫服務器的部門，需技術人員現場安裝。

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