Node.js 應該用在什麼地方

Node.js 應該用在什麼地方

聊天

聊天是最典型的多用戶實時交互的應用。從IRC開始，有許多開源或者不開源的協議都運行在非標準端口上，而如今，使用 Node.js 則能夠解決這些問題——在標準的80端口運行 WebSockets。

聊天應用程序是最能體現 Node.js 優勢的例子：輕量級、高流量而且能良好的應對跨平臺設備上運行密集型數據（雖然計算能力低）。同時，聊天也是一個很是值得學習的用例，由於它很簡單，而且涵蓋了目前爲止一個典型的 Node.js 會用到的大部分解決方案。

讓咱們試着來描繪它如何工做。

在最簡單的狀況下，咱們佈置了一個聊天室在咱們的網站上，用戶能夠在上面發消息，固然是一對多的形式。例如，假設總共有三我的鏈接到咱們的網站上。

在服務端這邊， 咱們有一個使用 Express.js 搭建的簡單站點，該站點實現了兩件事 1) 處理路徑爲 ‘/’ 的GET請求時，下發包括一個留言板以及一個發送信息的 ‘發送’ 按鈕的頁面 2) 一個監聽客戶端發送新消息的 websockets 服務。

在客戶端這邊，咱們有一個 HTML 頁面，上面有個兩個 js 方法，一個是用於觸發事件的 「發送」 按鈕，這會把把輸入的消息經過 webscoket 發送，另外一個方法是用 webscoket 在客戶端上監聽服務端來的推送（例如，其餘用戶發送的消息）。

當有一個客戶端發送消息的時候，發生的事情是：

1. 瀏覽器上，點擊發送按鈕觸發了 js 函數，將輸入框中的文字經過 websocket 消息發送到服務器的 websocket 客戶端（頁面初始化加載的時候鏈接的）。
2. 服務端的 websocket 組件收到 消息，而後經過廣播方法轉發到其餘全部鏈接的客戶端。
3. 經過頁面上運行的 websocket 客戶端組件，全部的客戶端都能收到這條推送的新消息。接着 js 處理函數能夠把這個消息添加到文字框內。

 

這是一個最簡單的例子。若是要更好的解決方案，你可使用 Redis 數據庫作一個簡單的緩存。在一個更高級的解決方案中，你可能須要一個消息路由來專門處理消息隊列，而且須要一個更強健的發送機制，好比發送的時候覆蓋上暫 時離線的用戶或者爲離線的註冊用戶存儲還沒有接收的消息等等。可是不論你作了怎麼樣的改進，Node.js 都將遵循一個基本原則：響應事件，處理多個併發鏈接，並保持流動性的用戶體驗。

對象數據庫接口（API ON TOP OF AN OBJECT DB）

儘管，Node.js 確實很是擅長實時交互的應用，同時它也十分適合經過對象數據庫（object DB）來查詢數據（如 MongoDB）。以 JSON 格式存儲的數據容許 Node.js 直接處理，不須要糾結數據轉換和匹配的問題。

舉個例子，若是你正在使用 Rails，你會將 JSON 數據轉成 二進制的 model，當數據再被 Backbone.js, Angular.js 或者 jQuery AJAX 之類的調用又要轉回 JSON。若是是 Nodejs 的話，你能夠經過一個 REST API 簡單的導出 JSON 對象以供客戶端使用。另外，從數據庫讀寫時候若是使用的是 MongoDB 的話，你也不用擔憂的 JSON 與任何數據之間的格式問題。總之，你能夠避免多元的數據轉換問題，不管是在客戶端、服務端仍是數據庫。

隊列輸入

若是你正在接收一個高量併發的數據，你的數據庫可能會成爲你處理的瓶頸。正如上面的描述，Node.js 能夠輕鬆的處理併發鏈接。 可是，因爲數據庫操做是一個阻塞的操做（在這種狀況下），這就是麻煩的地方。Node.js的解決方案是，在數據真正的寫入以前就認可客戶端的數據是真實 的。

用這種方法，在高負載的時候系統繼續維持它的響應，這在當客戶端不須要嚴格確認一個數據是否成功的被寫入時特別有用。典型的例子包括：日誌記錄或者用戶跟蹤數據（user-tracking data）的記錄，這會被分批處理而且在稍後才使用；同時也包括最終一致性（so, 經常使用於 NoSQL）能夠接受，不須要當即反應的操做（例如 Facebook 上更新點讚的數目）。

數據經過某些緩存或者消息隊列的基礎組件（例如 RabbitMQ, ZeroMQ）進入隊列，而且經過一個獨立的數據庫批量寫入進程來一一消化，或者經過一個更高性能的計算密集型後端服務來進行處理。其餘的語言/框架也可 以實現類似的操做，但在相同的配置下是達不到 nodejs 的高吞吐量與高併發。

 

簡單的說：使用 Node，你能夠把數據庫操做扔到一邊並在稍後處理它們，假設他們成功了同樣繼續執行下去。（筆者注：在開發中一般的狀況一般是，種耗時的操做經過回調函數來異步處理，主線程繼續往下執行）

數據流

在較爲傳統的網絡平臺上，HTTP 的請求和響應更像是孤立的事件；然而事實上，他們都是數據流。這一觀察結果在 Nodejs 上能夠用來創建一些很酷的功能。由於數據通以流的形式接收，而咱們能夠在網站上在線處理正在上傳中的文件。這樣的話，就能夠實現實時的音頻和視頻編碼，以及在不一樣數據源之間進行代碼（代理見下一段）。

（筆者注：Node 有代替如 apache 這樣的 webserver 處理數據，因此開發者能夠直接收到客戶端一份一份上傳的數據，並實時處理。上面這段話聽起來有點抽象，不過各位能夠簡單的想象一下不須要開 YY 或者 QQ，打開網頁就能進行語音視頻的功能。）

代理

Node.js 能夠經過異步的方式處理大量的併發鏈接，因此很容易做爲服務端的代理來使用。這在與不一樣響應時間的不一樣服務之間進行代理，或者是收集來自多個來源的數據時尤爲有用。

舉個例子：考慮一個服務器端的應用程序和第三方資源進行通訊以更新自不一樣來源的數據，或者將服務端上的一些圖像和視頻資源存儲到第三方雲服務。

雖然專用代理服務器確實存在，可是若是你尚未專用的代理服務器，或者你須要一個本地開發的解決方案，那麼使用 Node 來作代理多是更好的選擇。關於這個解決方案，個人意思是指當你在開發的時候，你可使用Node.js的開發環境搭建一個服務來處理對資源和代理的請 求，而在生產環境下，你可使用專用的代理服務（好比nginx，HAProxy等）來處理這些交互。

股票操盤手的儀表盤

讓咱們繼續討論應用程序這塊。實時網絡的解決方案能夠很輕鬆的實現證券交易軟件——用於跟蹤股票的價格，執行計算、作技術分析，同時生成報表。

使用一個實時的的基於網頁的解決方案，將會容許操盤手輕鬆的切換工做軟件以及工做地點。相信不久，咱們或許會在 佛羅里達州、伊維薩島又或者是巴厘島的海灘上看到他們。

應用監聽儀盤表

另外一種常見的用例中，使用 Node+Web+Socket 很是適合：跟蹤網站訪問者而且可視化實時它們之間的實時交互。 （若是你有興趣，能夠去看看Hummingbird）

你可能須要採集用戶的實時狀態, 或者甚至當他們到達渠道中某個特定的點時, 打開一個交流頻道， 經過有針對性的互動介紹移動到下一個階段. （若是你感興趣的話，推薦你看看 CANDDi）

想象一下，若是你知道你的訪客的實時操做，並可以形象化地看到他們的交互，這將對你的業務帶來多大的提高。隨着實時的、雙向 socket 通訊的 Node.js ，如今你能夠作到了。

系統監控儀表

如今，讓咱們看看事情的基礎設施方面。想象一下，好比，但願爲其用戶提供服務監控頁面（例如，GitHub上的狀態頁）的 SaaS 運營商 。經過 Node.js 的事件循環，咱們能夠建立一個基於 Web 的功能強大的儀表板，以異步方式檢查服務狀態而且使用的 WebSockets 將數據推送到客戶端。

內部（公司內部）和公共服務的狀態均可以使用該項技術實現實時的上報。讓咱們把這一想法延伸的遠一點，試着想象一個電信運營商中網絡運營中心（NOC）的監控應用，雲/網絡/服務器運營商，或者一些金融機構，全都運行在這個由 Node.js 和 WebSocket 組成的應用上，而不是 Java 和/或 Java Applet。

注意：不要嘗試使用 Node 打造硬實時系統（即，響應時間要求一致的系統）。 Erlang是多是該類應用程序的更好的選擇。