[訊息論壇] ICE
Messaging Forum 郭漢丞
應用篇：iPush®
Server 部署案例
經過第 15 與 16 期艾揚電子報關於部署 iPush®
Server 的單機篇與叢集篇之後，相信各位讀者對於部署之道已經有了基本的認識。本期我們將繼續部署 iPush®
Server 這個話題，舉出一個金融服務單位的應用實例，讓理論上的部署之道有一個可以參考的案例，以輔助您進一步的瞭解。
在進入案例探討之前，我們必須要了解，前面的兩篇部署之道，側重於正確部署的各種執行項目，包括組態檔
(*.ini)、Load Balancer、 Firewall 等設定，著重於設定之示範。
不過實際上的情況是：許多我們所提出的理論步驟，卻與您的真實環境有所差異。因此，部署之道除了必須正確地完成設定之外，更重要的是，必須將應用的環境考慮清楚，目標是在部署完成後，可以一次就把新系統整套執行起來。
最後，就算所有最壞的狀況、令人哭笑不得的奇異事件都發生了，也要想辦法讓系統能夠正常運作。換句話說，當您打算將新的系統部署上線，必須先想好各種可能情況下的退路，隨時有應變方案在手上，以備不時之需。
我們只能夠告訴大家，這是一家金融服務單位的實際案例。與客戶機密有關的部分必須予以省略，只舉出問題與思考方向與讀者交流。但可貴之處，還是在於這是一個真實的部署案例。
金融事業單位對於 iPush® Server 的部署要求標準可不低，因為金融機構的資訊服務必須滿足幾項特性：
-
不停機服務特性：即使是新系統上線，也必須維持不中斷的服務。
-
大量資訊服務量能：同一資訊服務必須提供大量客戶在密集時段中使用。
-
客戶使用習慣適應性：客戶要能夠對新資訊服務的使用者介面
(Uer Interface) 快速上手。
對於專案經理而言，上述三項要求在金融服務單位應該都不算是「苛求」吧？實際上，無論團隊在
SA、SD 階段有多少的共識與默契，到了真正部署完成的那一天，恐怕沒有百分之百相信不會出狀況的專案經理。在新系統正式部署上線之前，大概都要心裡默唸阿彌陀佛或是聖母瑪麗亞，祈禱一切順利。
確實，儘管可以頃全力模擬部署時可能發生的問題，但是有些情況是不等到真正上線，還真是不容易想得到。網路環境、防火牆、不同使用者執行環境種種因素影響，很容易讓系統總是在無法預測的地方出問題。
無論如何，面對金融服務單位即將上線的新系統部署，沒有人敢掉以輕心，務求在每一方面執行得盡善盡美。
前面三項金融資訊服務的特性需求中，第 3 項屬於應用面的客戶端軟體設計範疇；而前面的兩項，就與系統技術或部署架構直接相關了。
由於 iPush® Server 已經具備的幾項系統技術架構，所以足以應付前面兩項的需求。這幾項系統技術架構包括了：
-
Fail Over
(錯誤轉介)
-
Fault Tolerance
(容錯機制)
-
Load Balancing
(負載平衡)
-
Scalability (擴充性)
在新系統部署上線之前，以上技術架構於個案實際執行環境上的運行發揮，必須獲得充分的討論，在部署上則會因為需求的不同，而產生差異，必須進行調整。
以金融服務單位而言，必須不中斷地提供資訊服務，同時必須考量已經存在的客戶使用習慣，因此在正式上線之前，必須要執行準備階段的工作。
| 部署之預備動作：預告服務改版
(Trial Run) |
此案例中的金融服務單位使用在 Browser 上執行的 Java Applet 來做為
iPush® Server 的應用客戶端，即這是一個 Web 資訊服務系統，而且這是一個用來取代舊有服務的新系統。
為了讓新的資訊服務能夠讓客戶接受且快速上手，因此在舊的服務退役之前，必須有一個新舊系統的切換準備階段。亦即在舊有資訊服務還在繼續運作之時，就先在服務進入的
Web 頁面通告新版本消息，讓客戶可以先行熟悉，甚至連結使用新系統。
在這時期，實際上是以兩套新舊系統同時運行，一方面讓客戶可以持續舊有服務，一方面也可以測試新系統的穩定性。
在艾揚的經驗中，旗艦級的訊息中介軟體 iPush® Server
幾乎沒有失誤過，問題多半發生在客戶端的 Java Applet 或 Application 設計有 Bug 存在，讓服務的效能打了折扣。
在經過一 ∼ 二週左右的切換準備階段，已經有許多客戶已經實際試用過新的應用軟體，同時系統的小問題也在這段時間中發現，工程人員開始執行最後階段的除錯與調整。
切換準備階段順利完成後，就到了要全面除舊佈新的階段了。
這是最令人緊張的時候，雖然新的系統在事前評估與切換準備階段中，確實能夠有效地提昇服務效能，但是客戶端要求的是正常使用，因此即使部署運行出了小狀況，也必須確保系統能持續運作。對於金融服務事業而言，中斷的每一分鐘都可能是幾百萬的損失。
為了避免產生可能的服務中斷風險，因此我們必須先將「退路」想好！這些「退路」當然還是得從
iPush® Server 的特性當中尋找。
因為 iPush® Server 具備同時運行的備援特性
(Redundancy)，面對金融事業服務大量客戶的特性，這裡可以採用「叢集式」的 iPush®
Clustering 部署，在「備援」這件事情上，就有了許多選擇和方法，以便確保最穩定的系統運作。
我們再一次參考上一期中提到的具
Fail Over 能力的雙 Connection Center 主機範例架構：
| 
|
| |
| 圖例.
具 Fail Over 能力的雙 Connection Center 主機範例架構 |
將交易所的資訊源與交易資訊送入上層左方的第一部 iPush®
Server (Connection Center 1)，與這一部 iPush® Server
平行的層級，我們另外裝設了另一部 iPush® Server (Connection
Center 2)，同時接收另一組備援使用的資訊源，一旦第一部 iPush® Server
出現狀況，系統會在第一時間切換至第二部提供資訊服務的 iPush® Server，以確保資訊服務內容來源不會中斷。
其次，第二層 (L2, Level 2) 部署的 iPush®
Server，串接來自上層的 iPush® Server 資訊，以及直接提供客戶資訊服務。這裡可以部署好幾部
iPush® Server，以因應大量線上客戶的需求。
在上述的金融服務單位案例中，在細節上還有值得深入探討的地方，經過審慎思考後的執行架構，讓我們提供了一次成功的部署。
在金融即時訊息服務上，經計算與實證，每一部 iPush®
Server 可同時服務的連線數量 (Concurrent Connection)，可以達到 2,500
個。而如上的叢集式部署，讓新上線的服務系統幾乎可以無限量地擴充服務量能。如果使用者增加，只需在第二層增加 iPush®
Server 的數量與叢集對外的頻寬，並不會影響到原有系統架構。
在這個案例當中，是不是已經完美無缺地達成「永不停頓」服務的要求了呢？
在備援設計上，其實還是有更進一步發揮的空間。在上述的架構下，Connection Center
只有兩部 iPush® Server 相互備援，所以還是有可能讓實際位在同一地點的兩部
iPush® Server，因為地震、水災、網路骨幹中斷、或其他人為因素，造成同時中斷服務的可能。
改進的方案，則是利用 iPush® Server
可以遠距分散多點部署的能力，讓多部 Connection Center iPush®
Server 採用「異地備援」的方式來更上層樓部署。
下次的採訪篇，將由艾揚的專業團隊成員現身說法，提供實際部署的心得體驗，敬請期待。
|
