[訊息論壇] ICE Messaging Forum 蔣居裕
<技術篇>
你一秒幾次？
本週報的中文正式名稱中，存在著「即時」二字，它的原文為 ”Real-time”，在大陸地區，則被稱為「實時」。
在訊息傳遞的領域中，即時是一個重要的課題。訊息傳遞的需求並非始於今日，但對即時性的要求，卻愈來愈嚴苛。其原因即在訊息的數位化、數位訊息收發設備不斷的推陳出新、以及企業無止境追求競爭力的提昇。
當我們提到「即時」時，應該要非常小心，因為這裡面存在絕對與相對兩種觀點。
絕對的是時間性要求的數值；相對的是商業價值的轉換。
即時的絕對觀點，來自類似下列的敘述：
- 一個網頁若無法在 6 秒內下載呈現，瀏覽者即會不耐而離去。
- 投資人無法接受一支股票的行情變動，延遲超過 1 秒才呈現。
- 玩家的角色在線上遊戲裡，至少必須做到每秒三次的更新，免得車子撞成一團而還不知。
- 在車隊派遣的 GIS/GPS 位置上，要能做到不低於 10
秒一次的更新。
- 在水、空氣等環境監控上，平時可以在 1~5 分鐘內更新一次，但對緊急時期的防災要求，卻必須提高到每秒更新一次。
- 公司決策層級的數位儀表版，以 1 分鐘為單位更新；但生產機台上的訊息，卻必須以
1 秒為單位更新。
簡單的說，即時的絕對觀點，是要問出：「你的訊息一秒更新幾次？」
即時的相對觀點，是在時間價值上，有沒有辦法趕上應用的最低要求。
時至今日，批次作業 (Batch Processes)，還是存在的企業資訊流通方式。批次作業的間隔，可能是一日一次、一週一次、或是一月一次。以技術而言，大多數的批次作業，都可採取架設存取閘道
(Access Gateway) 的方式，變成即時的資訊流通。問題只在於：有沒有必要？因為並不是所有的資訊存取作業，都必須要做到發生時立即作業這般的即時
(In-time Process，這應該叫”及時”)。所以在此一觀點下的即時性關鍵報告，是必須分析出時間在各項商業處理上的最低需求，才足以判斷即時性在此的相對意義。換句話說，在已經滿足最低時間性要求的情況下，再去強調更高的即時性，其能夠換取的商業價值不會太高。
絕對或相對，不是互斥的觀點。前者著重在使用者對於應用面時間的忍受數值，考驗的是人性對技術的絕對苛刻程度；而後者則強調即時性在商業價值轉換的高低。
不管是絕對還是相對，低的即時性需求，也許以傳統的資訊架構，如以資料庫為主，就足堪應付；需不需要導入 MOM，則是其他的因素考量：比如是要主動
Push，而非定時 Polling，或是系統需要一個通用的訊息平台，以便接取各種不同類型的訊息；但並不特別強調其應用的即時性等。
| 資訊系統的即時性：DB-centric
vs. MOM-centric |
Database 與 MOM 天生的任務目標不同。Database 是資訊的留存所，重點是資訊的庫存管理；MOM
是資訊的流通管道，重點是要做到訊暢其流。
在 MOM 應用觀念尚未普及的今天，我們可以看到有許多 Developer 限於經驗，大量使用 Database 來應付即時性要求非常高，或是訊息來源非常多的應用系統，以致深為系統效率不彰，即時性大打折扣所苦。
若是這種情況，就該改變架構，慎重評估導入 MOM，從 DB-centric 改為 MOM-centric。
 |
 |
| 圖例：DB-centric |
圖例：MOM-centric |
如此帶來的直接效益，包含了資料庫使用數量的降低、免除了跨平台客戶端所需的 Gateway、以及資訊流動的即時性大幅提昇等。
不似消費性套裝軟體產品，使用者是針對一般消費大眾；MOM 的使用者是具某種技術能力的 Developer (應用軟體開發者)。在
Developer 著手開發訊息應用之前，必須先對流通整個系統的訊息，進行細部的分析，才能較實際地進行系統設計，並且看出
MOM 的使用效益。細部的訊息系統分析，必須找出下列 13 項標的，才堪稱完善：
- Role：訊息系統相關角色設定 (人或系統)
- Flow：訊息流程
- Meaning：訊息傳遞的意義為何
- Msg. Producer / Msg. Consumer：誰是訊息的產生者或訊息的消費者
- Number of Msg. Producers and
Msg. Consumers：訊息產生者與訊息消費者的數量為何
- Real-time：即時性的最低要求為何
- Msg.
Size：訊息的大小
- Msg.
Frequency：訊息的頻率 (一秒幾次)
- Scalability：系統短、中、長期的服務規模 (連線使用數)
落點描繪
- One-way or Bi-directional：各種客戶端的訊息流通是單向還是雙向
- Computation：商業邏輯的運算效能需求
- Carrier/Protocol：訊息通訊載體或通訊協定的支援需求
- Platform：客戶端軟體的執行環境平台支援
如果針對每一個單一訊息，都能分析出上述的各項標的，那 MOM 的導入，就可算成功了一半。本期不深入說明上述各項標的分析的意義，讓我們回到即時性的討論來。
上述 13 項標的，除了即時性本身外，其餘與即時性會有直接相互影響的，則是 Msg. Frequency (訊息的頻率)
與 Msg. Size (訊息的大小)。很容易明瞭的是：
- 訊息的頻率愈高，即時性需求愈高。
若訊息頻率低到一定程度時，即使捨 MOM，而就 DBMS，用資料先進資料庫儲存，而後取出，來達到訊息流動的目標，可能就足堪應付。
- 訊息的長短愈小，愈容易達成高即時性。
這是因為訊息越短越小，訊息於產生、傳送、接收的處理時間，都可以縮短，所以每秒可以更新的次數即可提高。
在 Developer 所使用的 API 中，與訊息收送頻率、訊息大小的相關運作如下 (以 ActiveX Control
─ iPushX.ocx 為例)：
訊息的生產者傳送
- 為確保即時大量訊息傳遞的效率，在萬人連線時猶似一人，所以
iPush Server 內部會取適當的大小來運作。當欲餵入 iPush Server 的訊息長度小於預設 (約
1KB) 時，可以使用 Method：
ipushSend(LPCTSTR strChannel,
LPCTSTR strData)，傳送純文字訊息。
ipushSendBin(LPCTSTR channel,
const VARIANT FAR& data, long datalen)，傳送二進位訊息。
- 但 Developer 一定有傳送較大訊息的需求，這時只要叫用可以自動對超過指定長度的訊息或是檔案進行切割的
Method：
ipushSendBlock(LPCTSTR channel,
LPCTSTR name, const VARIANT FAR& data, long datalen)，純文字或二進位傳送皆可。
與此 Method 搭配運用，還有兩個 Properties：
blockSize ：設定 API 自動切割的每個訊息長度，單位為
Byte。
delayTime：設定 API 切割後，前後兩個訊息餵入
iPush Server 的時間間距，單位為 Millisecond (ms)。預設為 10 ms。
透過以上的 Properties 設定，Developer 即可計算出「一秒更新幾次」的頻率。
若再加上 Msg. Producer 的數量，進一步計算出訊息於餵入 iPush Server 時的頻寬需求；加上
Msg. Consumer 的數量，即可進一步計算出訊息從 iPush Server 送出的頻寬需求。
訊息的消費者接收
訊息被餵入 iPush Server，在經過效率很高，遠低於 ms 為處理單位的
Publishing Channel Permission Checking + Channel Subscription
Mapping 後，會馬上主動推播 (Proactive Push) 給有訂閱的連線訊息消費者。當訊息消費者端的
API 接到訊息時，若是該訊息為被切割過，則會等到該訊息各部分的 Block 都接收到後，才進行組合還原。
接下來，視作業環境的不同，即會觸發一個 Event (事件)，或是呼叫一個已經設計好的 Callback 函式，讓消費者端的訊息應用程式接手處理該訊息。以
iPushX.ocx 為例，其會觸發的 Event 如下：
- DataReceived：收到一般長度較短的純文字訊息。
- SetData：收到一般長度較短的二進位訊息。
- SetData2：收到一般長度較短的二進位訊息，且
Channel 名稱為非列印字元時。
- BlockDataReceived：收到切割重組的訊息。
消費者端訊息應用程式即藉由各 Event 所帶來的 Channel 資料與訊息內容，可以進行後續邏輯處理了。
ICE iPush® Communication Server 產品的目標，即是成為一個即時鉅量連線的訊息導向中介軟體
(Massive-connection MOM)。從上述的討論來看：
- 訊息生產傳送
→ iPush Server Publishing Channel Permission Checking →
iPush Server Channel Subscription Mapping → 訊息接收消費
在頻寬無虞的情況下，都是以 ms ，或是低於 ms 為時間單位在進行的，如此的訊息流動即時性，加上可以同時應付成千上萬鉅量連線的特性，這真的是
DB-centric 系統架構用於訊息收送所無法企及的。
猶有甚者，即使是不同的 MOM 產品間，也存在著即時性程度的差異。有些 MOM 產品的設計，乃是以 Queue
為基礎，在其上添加 Pub/Sub 的功能，其 Client API 卻以 Polling 的方式，來對 MOM 定時探尋是否有新的訊息需要傳送。
雖然對 Developer 而言，同樣面對 API 來設計應用程式，但實際上，卻已經大大犧牲了 MOM 於即時性上的訴求，導致整體系統
Real-time 與 Performance 無法兼得。這與 iPush Server Native Pub/Sub
的設計有甚大的差異，是 Developer 必須明察小心面對的。
|
