不管是網站或者網頁應用 (web applications), 提供支援的語言 、 框架 、 工具等等可以說已經相當成熟 , 對初學者來說 : 最大的問題應該只是常常不知道該如何選擇哪個 。 但隨著行動網路裝置的普及 , 網頁應用開發面臨新的挑戰 , 像是 : 要求大量連線 、 即時雙向互動等 , 這些都讓傳統的應用服務器 (application server) 出現捉襟見拙的窘況 。 本文山姆鍋介紹 Vert.x 這個即時網頁應用框架 , 作為雲端應用基礎架構的一部分 。 想像一下 , 您需要寫一個網頁即時通 (Web IM) 軟體 , 要如何達到讓大量的用戶可以即時雙向的溝通 ? 為了達到這個要求 , 大部份的做法都會讓客戶端 (JavaScript) 跟服務端建立 ( 真實或者模擬的 ) 雙向持續的連線 。 說到這裡 , 對服務端有經驗的人應該都會想到 C10K 的問題 , 更進一步會知道可以採用非同步處理方式來解決 。 提供非同步處理的解決方案 , 目前最熱門的應該屬於 Node.js, 對於非同步處理的支援 , 它可說是很完善的方案 。 但從實務的觀點來考量 , 非同步處理只是整個方案的一部分 , 還有其他面向需要考量 。

JavaScript 以外的語言

雖然 JavaScript 可說是網頁應用開發領域最多人熟悉的語言 , 但後端服務開發人員卻未必熟悉 。 雖然 Node.js 支援像 CoffeeScript 這種可以轉譯成 JavaScript 的語言 , 但基本上可說只支援 JavaScript。 對於希望使用像 Node.js 這麼優秀的工具但卻希望使用不同腳本語言的人來說 ,Node.js 的這個限制會增加學習的門檻 。

Vert.x 提供 Java, JavaScript, Ruby, Groovy 等語言支持 ,Scala 以及 Closure 也在計劃中 。 對於現有 Node.js 使用者 ,Vert.x 支援 JavaScript 應該很有吸引力 , 可惜目前 Vert.x 尚沒有 Node.js 的完整相容界面 ](http://nodyn.io/), 很難說未來會不會出現或者需不需要這樣的相容界面 。

大量現存的程式庫

從實務面來講 , 現存大量的程式庫都不是採用非同步方式設計 , 運用這些程式庫顯然是無可避免的問題 。 由於 Node.js 只支援非同步處理 , 需要透過像是 Celery 這樣的分散式任務佇列 (distributed task queue) 來呼叫後端處理程序 。

針對這個問題 ,Vert.x 採用混和 (hybrid) 的處理模式來解決 。 除了非同步處理 ,Vert.x 也提供背景工作的執行 , 兩者採用不同的執行緒池 (thread pool)。 非同步處理執行緒不允許進行阻斷式操作 (blockgin operation), 但背景工作則沒有這個限制 。 因此 , 可以使用背景工作執行像是資料庫存取動作 , 再將結果傳給非同步處理 。

這兩者設計方式 , 沒有孰優熟劣的問題 , 但 Vert.x 的方式不用另外設定 , 顯然比較單純 。

服務端執行效能

通常山姆鍋不會建議您基於執行效能來選擇一個應用平台 , 況且 Node.js 對大部份的應用都已經夠快 , 沒有理由因為其他方案快個 10% 就轉換跑道 。 Java 語言雖然有許多缺點 , 但是 JVM 卻是很好的虛擬機器 , 執行速度很快 。 使用 JVM 作為後端的執行平台 , 對很多人來說還是有較大的吸引力 。

水平擴充的能力

Vert.x 的模組間只能透過 Event bus 來溝通 , 如此 , 確保模組間達到低偶合的要求 。Vert.x 的 Event bus 可以橫跨多台主機 , 也就是 , 多台主機可以形成一個叢集 (cluster) 一起提供服務 。 藉由這樣分散式 Event bus 的設計 , 訊息可以從主機 A 送給連到主機 B 的其他客戶端 , 更好的是 , 程式可以不用修改便可以有這樣的支援 。

Vert.x 的分散式 Event bus 或者叢集功能是採用 Hazelcast 這套 IMDb 來實現 。 對於即時性的要求越來越高的情況下 , 在整體架構上 , 應該都要有一個像 Hazelcast 這樣的分散式快取 (distributed cache) 存在 , 如此 , 才能減少資料庫存取進而有效降低反應時間 。

小結

山姆鍋本人很欣賞 Node.js 這樣創新的解決方案 , 本文僅就一個 Java 平台的開發者的觀點說明 : 如果 Node.js 不符合您的需求 , 還有另一個不錯的替代方案 。