[訊息論壇] ICE Messaging
Forum 蔣居裕
技術篇：iPush®
Server 部署之道 (上 ─ 單機篇)
一旦 Developer 將訊息應用軟體開發完成，經過測試之後，接下來，就該是進行整套系統上線部署
(Go-live Deployment) 的時候了。
我們曾經在本訊息論壇中提醒 Developer，千萬不要誤把單純的 Development
開發環境當成複雜的 Deployment 上線環境，以免在應用系統上線時，才發覺大小各種問題叢生。
事實上，系統部署的規劃，應該是在系統分析設計完畢之後，就已經讓負責軟體開發的 Developer
清楚知道才對。而系統分析設計要能夠正確地規劃出部署環境，則是其具備清楚的各項前提要素，如：
- 應用系統上線後，在尖峰時刻 (Peak Time)，準備要可以同時服務多少上線的使用者？
- 訊息的大小範圍如何？
- 上述兩者綜合加乘考量，應該要準備多少頻寬？
- 一部訊息伺服器夠嗎？還是必須部署伺服叢集 (Clustering)？
- 訊息伺服器的 IP / Host Name 為何？DNS 設定要正確。
- 訊息伺服器所使用的 Port Number 為何？
- 訊息伺服器要部署在防火牆 (Firewall) 內，還是外？
- 搭配訊息伺服器使用的 Web Server，其各項設定是否無誤？
- 如果訊息應用程式為需搭配 Web Server 執行者 (如 ASP、Java
Applet)，那相關 Binary 檔案 (如 .ocx, .class, .jar, ......) 要放置在甚麼路徑之下？
是的，就是有這麼多系統部署上的環節要注意，所以我們才說上線環境的複雜程度，絕非單純的開發環境所能比擬。尤其現在企業講究網路安全，SA/SD、Developer
若不跟網管人員好好坐下來討論一番，是很容易出亂子的。
沒有良好的部署，就沒有良好的服務，其理至明。以下兩期，我們針對以 iPush®
Server 為中心的訊息應用系統，深入討論應該如何正確部署。
本期將重點放在單台的 iPush® Server 部署上，而下一期，則會進階討論如何部署具備
Fail Over 能力的多台 iPush® Server Clustering。
一套完整的 iPush® Server，其實是由下列四個部分組成的：
- iPush®
Messaging Kernel：又稱為 iCore，為 iPush®
Server 的即時傳訊核心；一般即稱之為 iPush® Server。
- BackOffice：提供各項管理的功能與介面。
- AuthService：即
Access Center Server (簡稱 AC Server)，對欲連線登入的 User 進行認證作業
(Authentication)。
- License Daemon：對
License Key 進行管控。
 |
| 圖
1. 以 iPush® Server 為核心的訊息應用系統組件架構圖 |
我們要在這邊，特別針對 AC Server 來說個明白。
除非是很大型的訊息應用系統，否則 AC Server 不需要單獨部署在一台 Host
上。以單台服務的 iPush® Server 來說，就是將以上四個組件通通部署安裝在同一台
Host。
而即使是多台階層式的 iPush® Server
叢集，通常 AC Server 也是與最上層的 iPush® Messaging Kernel
部署在同一台 Host 上。
註一：在 iPush®
Server 叢集中最上層的 iPush® Server，即為 Connection
Center for iPush®
Server Clustering，我們下期再來詳加說明。
那麼，AC Server 是如何運作的呢？
對於只負責應用軟體開發的 Developer 而言，對著 iPush®
API 進行函式呼叫，是感覺不到 AC Server 存在的。
以 iPush® DLL API 為例，應用程式若要與 iPush®
Server 建立連線並進行使用者登入作業，則必須呼叫 ConnectReal()
這個函式：
int ConnectReal(char *strCompName,
char *strProdName, char *strUserName, char *strPassword,
char *lpszProxyAddress, int nProxyPort, char *lpszCoreAddress,
int nCorePort, HWND hWnd)
一旦呼叫這個函式，若正常的話，會一連進行兩個動作：
- 嘗試與 iCore (iPush® Messaging
Kernel) 建立 TCP 連線。若失敗，會觸發一個包含錯誤代碼的事件 WM_CONNECTION_FAIL，且應用程式會收到回傳值
0；若成功，則回傳值為該連線的 Socket Port 埠號，並進行下一個動作。
- 嘗試對 AC Server 進行登入作業。若成功，應用程式會收到包含 iPush®
Server IP 與 Port 埠號的事件 WM_CONNECTION_READY
通知；若失敗，則應用程式會收到包含錯誤代碼的事件 WM_CONNECTION_FAIL
通知。
所以，若應用程式收到事件 WM_CONNECTION_FAIL，那麼有可能是在嘗試建立
TCP 連線時，就發生問題；也有可能是 TCP 連線成功了，但登入 AC Server 時卻發生問題。
註二：更多的 WM_CONNECTION_FAIL
事件錯誤代碼，請參考 iPush®
DLL API 的 Programming Guide 說明。
對於應用程式來說，它並不直接面對 AC Server，所謂的 "嘗試對 AC
Server 進行登入作業" ，是由 iPush® Server 內部來進行的。AC
Server 在收到由 API 傳送過來的 User 登入帳號資料 (strCompName,
strProdName,
strUserName, strPassword)
後，會進行下列查驗工作：
- Service (strCompName
+ strProdName) 存不存在？
- Service 過期了沒有？
- Service Concurrent Connection 超過了沒有？
- User ID (strUserName)
存不存在？
- Password (strPassword)
對不對？
- User 帳戶過期了沒有？
- User Concurrent Connection 超過了沒有？
- iPush® Host Concurrent Connection
超過了沒有？
- ......
為能讓 iCore 與 AC Server 串聯起來，完成上述作業，iPush®
必須被正確地組態 (Configuration)。所以我們可以在 iPush.ini 組態檔案中，見到如下的設定項目：
/*************************************************************************/
/* AuthAddress & AuthPort */
/* Where the iPush should connect to, to be it's AC. A blank */
/* AuthAddress represent no AuthConnection needed. */
/*************************************************************************/
AuthAddress=192.168.0.211
AuthPort=1111
非常容易明白：
- AuthAddress：告訴 iCore，它所串聯使用的 AC Server IP
為何。
- AuthPort：該 AC Server 服務聆聽的埠號 (預設為 1111)。
而在 AC Server 運作所需的 Auth.ini 組態檔案中，也存在著對應的服務聆聽埠號設定項目，如下所示：
註三：iPush.ini 檔案位於 iPush®
Server 安裝目錄下的 ICEiPush2000 子目錄中 (for Windows)。
註四：Auth.ini 檔案位於 iPush®
Server 安裝目錄下的 ICEAuthService 子目錄中 (for Windows)。
而 BackOffice 裡面的 Service Management、User Management，就提供了
AC Server 各項檢驗所需的資訊。
AC Server 在運作執行時，會適當地將各種行為寫入 ACLog.txt 這個紀錄檔中，其中即提供了豐富的運作歷史紀錄，是系統管理人員與
Developer 進階了解 AC Server 必讀的參考。
註五：ACLog.txt 的檔案預設位置為
iPush® Server 安裝目錄下的 ICELogFiles 子目錄中。但您可以自行在
Auth.ini 修改 LogFilename
的設定值，以改變其位置與檔案名稱 (for Windows)。
| Web
Server 與 iPush® Server |
整套 iPush® Server 系統，需要 Web Server
來協同運作的原因有二：
1. BackOffice 被設計成 Web 程式，各項功能透過瀏覽器來執行，所以當然一定要有 Web Server
才行囉。
2. 如果，Developer 將 iPush® 應用程式寫成 Java Applet
(使用 iPush® Java Package API)，那在部署上，必須將 Java
Applet 擺放在與 iPush® Server 同一 Host 的 Web Server
虛擬目錄之下。這是 Java Applet (Java Class) 的安全性設計使然，若是使用 ActiveX Control
的 ASP 程式，就沒有這樣 iPush® Server 與 Web Server
要跑在同一 Host 的限制。
在 Web Server 的搭配選用上，是否有指定的種類呢？
目前 iPush® BackOffice 在 Windows
版本上，搭配 IIS 執行，在 Linux 版本上，搭配 Apache 執行。至於用來部署 Java Applet
/ Java Class 與 ASP / ActiveX Control 應用程式所需的 Web Server，就不限特定的種類。
在現今大量依賴網路通訊的企業資訊安全環境中，防火牆 (Firewall) 已經是一個必備的設備。至於一個訊息應用系統，應該將訊息伺服器擺在
Firewall 內，還是 Firewall 外，考量點應該有：
- 在訊息應用系統中流動的資訊，其內容安全性等級需求有多高？
如果只是公眾資訊，如股市行情、即時新聞的訂閱與傳遞，若沒有其他的考量 (如駭客刻意的攻擊)，則可以將訊息伺服器擺放在
Firewall 外。
- Firewall 的執行效能如何？
一旦決定要將訊息伺服器擺在 Firewall 內，那就接著要考量訊息應用系統在尖峰使用時刻的網路流量，Firewall
是不是能夠有效處理？若答案為否，那就必須考慮更換執行效能更佳的 Firewall。
訊息伺服器若擺在 Firewall 內，那網管人員就必須要在 Firewall 的 Proxy
設定中，有適當的組態，以便讓訊息應用系統的訊息流量能夠順利穿越 Firewall。那這個組態所需的資訊在哪裡呢？
讓我們回到 iPush.ini 來，Firewall 的 Proxy 組態設定資訊就在其中的
ListenPort：
/**************************************************************************/
/* Listen Port */
/* Indicate the port which the iPush server listen on. */
/**************************************************************************/
ListenPort=8000
ListenPort 即為 iPush®
Messaging Kernel 服務諸 iPush® Client 連線所聆聽的埠號。依照預設，iPush®
Server for Windows 的埠號為 8000，iPush® Server
for Linux 的埠號為 443。當然，實際上線部署時，Developer 可以與網管人員協調改變之。
其實，對於使用者執行客戶端應用軟體的便利性來說，我們最建議 ListenPort 被設定為
443 (即 Linux 版的預設值)，因為一般 Firewall 會將 443 視為 HTTPS (SSL) 通訊協定所使用的埠號，對使用這個埠號的資料封包予以放行
(此即 HTTPS Tunneling)。
既然如此，那為何 iPush® Server for Windows
的 ListenPort 埠號還要預設為 8000，而不是 443 呢？這是因為單台的 iPush®
Server for Windows 必須搭配 IIS Web Server 來執行 BackOffice，而 IIS
在安裝時，就會將埠號 443 佔去，除非安裝 SSL Server-side Certificate，否則很難將這個設定
Disable。因此，iPush® Server for Windows 只好另覓預設埠號了。
不管 iPush® Server 是擺放在 Firewall
內還是外，一旦伺服器端部署完成，接下來，就是 iPush® Client 端在執行時，要有正確的對應網路連結資訊。尤其是考量到那些在
Firewall 內執行 iPush® Client 應用程式的使用者，一定要在軟體的使用者介面中，保留能夠讓使用者改變
Proxy IP 與 Port 設定的功能，以便 iPush® Client
可以彈性因應其所處的網路管理環境。這在無法預先對使用者網路環境進行管控的 B2C 應用而言，尤其重要。
我們還是以 iPush® DLL API 為例，在應用程式呼叫
ConnectReal() 這個函式時：
int ConnectReal(char *strCompName,
char *strProdName, char *strUserName, char *strPassword,
char *lpszProxyAddress, int nProxyPort, char *lpszCoreAddress,
int nCorePort, HWND hWnd)
其中傳入的參數 lpszProxyAddress
與 nProxyPort，就分別是 iPush®
Client 穿越 Firewall 所需的 Proxy Server IP 位址與埠號資訊。而該 Proxy Server
當然是要設定開放對應的埠號， iPush® Client 才能正常地對由參數 lpszCoreAddress
/ nCorePort 所指定的 iPush®
Server IP 位址 / 埠號收發訊息。
| iPush®
Server 對 Dangling Client 的處理之道 |
由於 Internet 公眾網路上的不確定因素很多，所以有時在 iPush®
Client 未能正常執行 Disconnect，登出並結束與 iPush®
Server 連線的情況下 (如 Client 端突然當機，或是網路中斷)，導致伺服器無法即時判斷並反應 Client
的連線狀態，造成 Dangling Client 的存在。
為清理這些不正常的 Dangling Client，iPush®
Server 祭出的手段，可以在 iPush.ini 檔案裡一窺端倪，相關組態項目如下所示：
/**************************************************************************/
/* CheckAliveTimeBegin & CheckAliveTimeout (min.) */
/* If a client has no respond for CheckAliveTimeBegin(in
minite), */
/* iPush will begin sending ack request info to it. If the
client still has */
/* no respond after CheckAliveTimeout(in minite), iPush
will close this */
/* connection. */
/**************************************************************************/
CheckAliveTimeBegin=10
CheckAliveTimeout=13
- CheckAliveTimeBegin：如果在設定的時間內 (預設為 10 分鐘)，先前連線登入的
iPush® Client 沒有任何動作，則 iPush®
Server 會開始為其計時。
- CheckAliveTimeout：承上，計時經過一段設定時間 (預設為 13
分鐘) 後，若該 iPush® Client 還是沒有動作，那麼 iPush®
Server 就會強迫結束其連線。
由此看來，透過精心校調 Auth.ini 與 iPush.ini 這兩個組態檔，搭配外圍的網路環境設定，一定可以部署出一個既正確，運作效能又佳的訊息應用系統。
不過請記得，一旦修改了 Auth.ini 或 iPush.ini 任何一個組態檔案之後，一定要重新啟動對應的
AC Server 或 iPush® Server。這樣設定修改才會生效。
好了，以上就是我們針對單台的 iPush® Server
訊息應用服務系統所提出的各項部署說明。下一期，就讓我們來談談進階的多台 iPush®
Server Clustering 部署之道
|
