WebSphere Application Server 中 Web 伺服器插件工作原理及故障診斷

引言

Web 伺服器與 WebSphere Application Server ( 簡稱為 WAS) 配合進行請求分發是一種很常見的拓撲結構。而 IBM WebSphere Application Server 的 Web 伺服器插件實際上就是 Web 伺服器和 WAS 之間的連接配接器。它主要的職責就是将從 Web 伺服器接收的請求轉送給 WAS。了解 Web 伺服器插件的工作原理不但可以幫助我們更快地檢測跟插件相關的問題，還能幫助我們建構更加完善的應用架構。

回頁首

Web 伺服器插件的工作原理

跟 WAS 不同，Web 伺服器插件是使用 C 語言開發的，是以它會稍微依賴于插件所在的作業系統及使用的 Web 伺服器。但這個依賴關系非常小，因為 Web 伺服器插件在不同作業系統和 Web 伺服器上的操作都差不多。下面我們就一步步介紹 Web 伺服器插件的工作原理。

Web 伺服器插件基礎

WAS 前端支援很多不同廠商的 Web 伺服器，常見的 Web 伺服器包括 IBM HTTP Server、Apache HTTP Server 和微軟的 IIS 等。我們這裡主要以 IBM HTTP Server ( 簡稱 IHS) 為例。如下圖所示，一個從浏覽器發送的 HTTP 請求經過 Web 伺服器之後會被重新定向給應用伺服器 ( 這裡指的應用伺服器都是 WAS)。這個重定向的操作就是由 Web 伺服器插件來完成的，我們可以把它想成是一個 Web 伺服器和應用伺服器之間的“代理”。

圖 1. Web 伺服器插件

WebSphere Application Server 中 Web 伺服器插件工作原理及故障診斷

這個重定向是基于一系列插件配置的規則，Web 伺服器會優先讓插件去處理每一個請求，隻有當插件沒有配置相關的 URL 才會讓 Web 伺服器去處理。我們可以這樣去了解，如果 Web 伺服器插件把 HTTP 請求發送給 WAS，那麼插件就可以看成是一個 HTTP 用戶端，WAS 接收這些請求，那 WAS 就可以看成是一個 HTTP 伺服器。HttpTransport 元件就是在 WAS 内部充當 HTTP 伺服器來接收 HTTP 請求的，我們可以設定多個 HttpTransport 元件配合多個端口使用。

那麼肯定有人要問為什麼要使用 Web 伺服器插件而不直接将 HTTP 請求從 Web 伺服器轉給 HttpTransport 元件呢？使用插件來完成這個工作有很多優點：

插件可以提供負載管理和故障轉移的能力幫助我們将請求分發給多個 WAS 或者将請求轉發給合适的 WAS。
靜态頁面由 Web 伺服器處理就夠了，不需要轉給 WAS 進而提高處理性能。
插件相當于在用戶端和 WAS 之間多加了一層結構，進而也提高了 WAS 的安全性。

Web 伺服器插件架構

接下來就讓我們看看插件工作的細節，幫助我們更好地了解插件的原理：

圖 2. Web 伺服器插件請求轉發流程

WebSphere Application Server 中 Web 伺服器插件工作原理及故障診斷

Web Server Process – native code：從浏覽器過來的請求第一步會經過預設的 80 端口進入 Web 伺服器。
httpd.conf：之後 IHS 會通過預設的 httpd.conf 找到插件的配置檔案 plugin-cfg.xml 進而将 HTTP 請求轉給插件。
插件會在 Web 伺服器啟動時加載 plugin-cfg.xml 配置檔案。我們需要把插件同 IHS 安裝在同一台機器上。
plugin-cfg.xml：這是插件的核心配置檔案。它包含了哪些 URL 将轉發給 WAS。我們可以通過 WAS 的管理控制台修改和生成這個配置檔案。但修改和生成配置檔案後我們還需要同 Web 伺服器同步配置資訊。
HttpTransport：這個元件實際上可以了解為一個 WAS 内部的基于 Java 的 HTTP 伺服器。它主要的職責就是接收從插件轉過來的請求并将請求再轉給 WAS 的 Web 容器處理。
Web Container：Web 容器最後就是利用 Java EE 的 servlet 規範解析并處理請求，再将處理的結果傳回給 Web 伺服器插件。

Web 伺服器插件工作流程

下面我們将詳細向大家介紹 Web 伺服器插件的工作流程，流程主要包括四個步驟：

初始化
URL 比對和 WAS 伺服器選擇
将請求發送給指定 WAS
接收從 WAS 傳回的結果

初始化

當 IHS 啟動後，IHS 會先讀取 <HIS_HOME>\conf\httpd.conf 檔案進行初始化。Web 伺服器啟動成功後會繼續讀取插件的配置檔案 plugin-cfg.xml，并将配置檔案中的配置解析出來。一旦 Web 伺服器啟動、讀取并加載配置成功之後，插件就可以準備接收 HTTP 請求了。

如果在 WAS 控制台中配置了 Web 伺服器，當有新的應用安裝到 WAS 上時，我們需要更新插件的 plugin-cfg.xml 配置檔案。更新方法有兩種：

利用 WAS 管理控制台生成并傳播新的配置檔案

圖 3. WAS 控制台 Web 伺服器管理界面

WebSphere Application Server 中 Web 伺服器插件工作原理及故障診斷

手工拷貝到插件的配置目錄中或者直接修改配置檔案

更新 plugin-cfg.xml 配置檔案後，Web 伺服器是不需要重新開機的。預設情況下，插件會每隔 60 秒自動重新加載配置檔案。如果您想更改這個數值，可以修改 plugin-cfg.xml 的配置檔案。下面我們把重新加載的時間間隔改為 5 分鐘 (300 秒 )：

清單 1. 代碼最大長度示例

<Config RefreshInterval=”300”> 
 <Log LogLevel="Warn" Name= 
"D:\WebSphere\AppServer/logs/http_plugin.log"/> 
 <Property Name="ESIEnable" Value="false"/> 
 <Property Name="ESIMaxCacheSize" Value="1024"/>

在測試或開發環境中可以使用較短的 RefreshInterval 時間，因為應用或環境需要經常修改。對于比較穩定的生産環境，我們建議 RefreshInterval 值可以設定的稍微長一些，這樣可以提高整個系統的性能。

URL 比對和 WAS 伺服器選擇

Web 伺服器接受到新的 HTTP 請求會首先将這個請求傳給插件。如果插件配置了相應的 URI，插件會比對 URI 将請求傳給 WAS 處理，如果沒有配置相應的 URI，那隻能由 Web 伺服器來處理了。首先我們先介紹一下插件配置中的相關屬性：

清單 2. 插件配置的相關屬性

<Config> 
 <Log LogLevel="Error" Name="<WAS_HOME>\logs\http_plugin.log"/> 
 <VirtualHostGroup Name="default_host"> 
 <VirtualHost Name="*:80"/> 
 </VirtualHostGroup> 
 <ServerCluster Name="MyCluster"> 
 <Server Name="CL1"> 
 <Transport Hostname="SHARAD" Port="9080" Protocol="http"/> 
 </Server> 
 </ServerCluster> 
 <UriGroup Name="MyURIs"> 
 <Uri Name="/MyPath/*"/> 
 </UriGroup> 
 <Route ServerCluster="MyCluster"
 UriGroup="MyURIs" VirtualHostGroup="default_host"/> 
 </Config>

這些配置的主要作用是就是将一個請求與 ServerCluster 中的一台伺服器關聯起來：

插件首先先将請求同每一個 Route 對比一下。一個 Route 包括 ServerCluster、UriGroup 和 VirtualHostGroup 的資訊。
根據 HTTP 請求的資訊，如果 Route 中有比對的 UriGroup 和 VirtualHostGroup，那麼插件就會将此請求發給相對應的 ServerCluster。
如果 ServerCluster 中有多個伺服器，那麼插件會根據一定的政策或 Session 等資訊将請求發送給合适的伺服器。

接下來，我們就看看整個插件 URL 比對和選擇伺服器的過程：

圖 4. 插件 URL 比對和選擇伺服器的過程

WebSphere Application Server 中 Web 伺服器插件工作原理及故障診斷

Step 1：當 Web 伺服器接收到一個請求後，它會立即将這個請求轉給插件。
Step 2：插件接收到這個請求後會把它分成兩個部分：主機名和 URI 位址。
Steps 3, 4, 5, 6：插件會自底至上查找配置檔案中定義的 Route，比對 Route 中的 VirtualHostGroup。如果有多個 Route 都比對，那麼會選擇最底下比對的 Route，如果沒有比對的 Route，那麼插件會把請求傳回給 Web 伺服器。
Steps 7, 8a, 9：接下來插件會依次比對 UriGroup 中的 URI 位址。當主機名和 URI 位址都比對了，插件就可以将這個請求轉給合适的 WAS 了。
Steps 10a, 10b：如果 VirtualHostGroup 和 URI 比對失敗，插件會把請求發回給 Web 伺服器，如果比對成功，将從 ServerCluster 選擇合适的伺服器接收請求。
Steps 11, 12, 13：之後插件會檢查請求的 Cookie 或 URL 中的 jsessionid 參數。從 jsessionid 中找到相應的 CloneID，如果此 CloneID 與某一台 WAS 的 CloneID 比對，那麼插件就會将請求轉給這台 WAS，如果沒有 jsessionid 或者沒有 CloneID 比對，那麼繼續執行 Step 14。
Step 14：如果沒有 jsessionid，插件會根據 ServerCluster 中每台 WAS 的 LoadBalanceWeight 權重、ClusterAddress 位址和 Random/RoundRobin 随機 / 輪詢 ( 依次分發 ) 規則尋找合适的 WAS，使用者都可以自行修改這些配置。
Step 15：HTTP 請求會被送給目标 WAS，如果 WAS 沒響應或者當機了，那麼插件會通過選擇政策重新選擇合适的 WAS 發送。

将請求發送給指定 WAS

相對于 WAS 來說，插件就是一個 HTTP 用戶端。是以插件的發送過程就是通過 TCP/IP 協定将浏覽器請求轉發給 WAS。

如果請求成功地轉發給了 WAS，插件會從 WAS 端收到一個成功的 TCP/IP ACK 回複。如果在逾時之前仍沒有收到回複，插件會傳回給 Web 伺服器一個 500 錯誤。我們可以通過作業系統層面設定 TCP/IP 的逾時時間，也可以在插件的 plugin-cfg.xml 配置檔案中設定。
接收從 WAS 傳回的結果

将請求發送給 WAS 後插件會進入等待狀态。當 WAS 傳回給插件對應的結果後，插件結束其等待狀态。但當請求處理失敗後，插件會把 WAS 标為不可用的狀态，如果此 WAS 長期處于不可用狀态，插件會将請求轉給 ServerCluster 中的另一台 WAS。如果所有的 WAS 都不可用或網絡逾時，插件會傳回給 Web 伺服器一個 500 的錯誤。

對于 WAS 端的 HttpTransport 子產品來說可以了解成一個基于 Java 内嵌的 HTTP 伺服器或者内部的 IHS。它會同 WAS 中的 Web Container 通信發送請求并接收處理後的結果。

回頁首

Web 伺服器插件的問題診斷

有時候檢測一個 WAS 元件的問題很困難，而且檢查到最後可能是和 Web 伺服器插件相關的問題。接下來我們就會介紹一些工具和技術來幫助大家追蹤和檢測問題。

Web 伺服器端的日志和 Trace

插件的日志檔案：http_plugin.log

當出現插件初始化失敗了、HTTP 報 500 或 404 等錯誤、WAS 通路不了了或者網絡錯誤等問題時可以檢查這個日志檔案。它位于插件目錄的 logs/<web server>/ 裡。

插件的日志級别可以設為三種級别：Error、Warn 或 Trace。Error 級别是預設級别，隻列印少量的資訊，其次是 Warn 級别，Trace 級别會給出最詳盡的資訊。我們可以在 plugin-cfg.xml 配置中修改日志的級别：

清單 3. 插件日志的級别

<?xml version="1.0" encoding="ISO-8859-1"?> 
 <Config> 
 <Log LogLevel=”Error" Name="E:\Temp\HTTPServer\Plugins\logs\webserver1 
 http_plugin.log"/>

具體的日志格式如下：

[ddd mm dd hh:mm:ss yyyy] PID TID - MsgType: Component: Task: Message

PID 代表了 Web 伺服器的程序 ID，TID 是 PID 中目标請求的線程 ID，這兩個 ID 都是以十六進制格式顯示的。而 MsgType 主要顯示的是三種日志級别。

下面的清單顯示的是插件接收到 HttpTransport 的資訊 (Trace 級别 )：

清單 4. Trace 級别的日志資訊

============================================================================ 
 [Thu May 01 12:39:05 2003] 000006d0 00000750 - TRACE: ws_common: 
 websphereExecute: Wrote the request; reading the response 
 [Thu May 01 12:39:05 2003] 000006d0 00000750 - TRACE: lib_htresponse: 
 htresponseRead: Reading the response: 
 [Thu May 01 12:39:05 2003] 000006d0 00000750 - TRACE: HTTP/1.1 200 OK 
 [Thu May 01 12:39:05 2003] 000006d0 00000750 - TRACE: Server: WebSphere 
 Application Server/5.0 
 [Thu May 01 12:39:05 2003] 000006d0 00000750 - TRACE: Set-Cookie: 
 JSESSIONID=0000NIK0UC2LBSJ00VVNHITUAEQ:uji3uq4g;Path=/ 
 [Thu May 01 12:39:05 2003] 000006d0 00000750 - TRACE: Cache-Control: no- 
 cache="set-cookie,set-cookie2"
 [Thu May 01 12:39:05 2003] 000006d0 00000750 - TRACE: Expires: Thu, 01 Dec 1994 
 16:00:00 GMT 
 [Thu May 01 12:39:05 2003] 000006d0 00000750 - TRACE: Content-Type: text/html 
 [Thu May 01 12:39:05 2003] 000006d0 00000750 - TRACE: Content-Language: en-US 
 [Thu May 01 12:39:05 2003] 000006d0 00000750 - TRACE: Transfer-Encoding: 
 chunked 
 [Thu May 01 12:39:05 2003] 000006d0 00000750 - TRACE: ws_common: 
 websphereExecute: Read the response; breaking out of loop 
 ============================================================================

Web 伺服器日志：access.log 和 error.log

當遇到 HTTP 500 或 404 等錯誤、Web 伺服器初始化錯誤或或網絡等問題時可以檢查這兩個日志檔案。
- access.log：這個檔案主要記錄傳回給 Web 伺服器的每一個回應，如果 Web 伺服器發送一個請求但沒有從 WAS 收到任何回應的話，我們将無法在這個日志檔案中找到相應的回應。是以我們可以通過這個日志檔案檢查請求是否得到了正确的響應。他的格式如下：
  
  127.0.0.1 - - [01/May/2003:15:48:00 -0500] "GET /AnyPath/MyServlet HTTP/1.0" 200 9736
- Error.log：這個檔案主要記錄 IHS 做遇到的任何錯誤。我們也可以通過 Web 伺服器的配置檔案 httpd.conf 修改日志的級别。

WAS 的日志和 Trace

HttpTransport 的 Trace

如果我們不能從 Web 伺服器和插件的日志檔案中找到有用的資訊，那我們就可以在 WAS 中打開 HttpTransport 子產品的 Trace 資訊查找相關的資訊。如圖：

圖 5. 開啟 Trace

WebSphere Application Server 中 Web 伺服器插件工作原理及故障診斷

HtppTransport 的 Trace 資訊如下：

com.ibm.ws.http.*

com.ibm.ws.webcontainer.*
WAS 的 SystemOut.log 和 SystemErr.log

當然，我們也可以通過 WAS 的兩個日志檔案，檢視是否有和插件相關的 WAS 問題或 HTTP 錯誤等。

檢測工具

我們還可以通過作業系統和 WAS 提供的工具幫助我們檢測插件的問題。比如我們可以通過作業系統的 netstat 和 telnet 指令檢測伺服器是否可用、網絡是否有問題。也可以通過 WAS 自帶的 TPV (Tivoli Performance Viewer) 或者 ITCAM (IBM Tivoli Composite Application Manager) 輔助我們監測和檢查問題。

回頁首

結束語

通過了解 Web 伺服器插件的工作原理及工作流程，我們可以更好地分析問題和完善應用架構。再加上多種日志資訊和其他工具的輔助，我們可以很友善地定位和解決 Web 伺服器插件相關的問題。