不管是網站或者網頁應用 (web applications),提供支援的語言、框架、工具等等可以說已經相當成熟,對初學者來說:最大的問題應該只是常常不知道該如何選擇哪個。但隨著行動網路裝置的普及,網頁應用開發面臨新的挑戰,像是:要求大量連線、即時雙向互動等,這些都讓傳統的應用服務器(application server) 出現捉襟見拙的窘況。本文山姆鍋介紹 < a href="http://vertx.io/" target="_blank" rel="noopener">Vert.x 這個即時網頁應用框架,作為雲端應用基礎架構的一部分。

想像一下,您需要寫一個網頁即時通 (Web IM) 軟體,要如何達到讓大量的用戶可以即時雙向的溝通?為了達到這個要求,大部份的做法都會讓客戶端 (JavaScript) 跟服務端建立 (真實或者模擬的) 雙向持續的連線。說到這裡,對服務端有經驗的人應該都會想到 < a href="http://www.kegel.com/c10k.html" target="_blank" rel="noopener">C10K 的問題,更進一步會知道可以採用非同步處理方式來解決。提供非同步處理的解決方案,目前最熱門的應該屬於 < a href="http://nodejs.org/" target="_blank" rel="noopener">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 只支援非同步處理,需要透過像是 < a href="http://www.celeryproject.org/" target="_blank" rel="noopener">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 或者叢集功能是採用 < a href="http://www.hazelcast.com/" target="_blank" rel="noopener">Hazelcast 這套 IMDb 來實現。對於即時性的要求越來越高的情況下,在整體架構上,應該都要有一個像 Hazelcast 這樣的分散式快取 (distributed cache) 存在,如此,才能減少資料庫存取進而有效降低反應時間。

小結

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