Node.JS

Node 是一個服務器端 JavaScript 解釋器

nodejs他是用C++開發的一種運行於服務器端的語言(在服務器端運行的javascript)，能夠寫網站後臺程序，能夠作服務端應用開發。

 

NODEJS，區別於，普通JS是腳本運行客戶端，而NODEJS中的JS是運行於服務器端，這麼說吧，NODEJS的做用至關PHP,ASP等語言。

 

1.node.js是一個構建在Chrome JavaScript運行環境的平臺，這是很重要的一點，node.js並非一門語言，而是一個平臺

2.node.js致力於使構建速度快、穩定的網絡程序更簡單

3.node.js具備事件驅動和非阻塞I/O的特點，使之輕量級而且高效率

4.node.js很是適合在分佈式設備運行數據密集型實時應用程序

 

服務器端運行的JavaScript？

Chrome JavaScript runtime也就是咱們常說的 Chrome的V8 JavaScript Engine，也就是Goole開發的一個用於Chrome瀏覽器的底層JavaScript引擎，用於解析JavaScript語句建立

 

其運行環境，保證咱們寫的語句在瀏覽器上的表現和咱們預期的一致。

 

那麼爲何說node.js是服務器端運行的JavaScript？好好地nodejs幹嗎要和V8扯上關係？除了Google搞的V8解釋JavaScript十分的快，十分重要的一個緣由是V8 JavaScript 引擎

 

並不只限於在瀏覽器中運行，能夠嵌入任何應用程序中運行。Node.js 和.net framework相似是一個平臺，但它沒有像.net同樣創造了一門語言——C#在這個平臺上運行，而是很巧妙的借用了web開發人員已經很是熟悉的JavaScript語法，使用V8引擎來解析語句，並將其重建可在服務器上使用。

 

因此嚴格上說node.js並非服務器端運行的Javascript，而是能夠在服務器端運行JavaScript語法的平臺。

 

Node 旨在解決什麼問題？

Node 公開宣稱的目標是 「旨在提供一種簡單的構建可伸縮網絡程序的方法」。當前的服務器程序有什麼問題？咱們來作個數學題。在 Java™ 和 PHP 這類語言中，每一個鏈接都會生成一個新線程，每一個新線程可能須要 2 MB 配套內存。在一個擁有 8 GB RAM 的系統上，理論上最大的併發鏈接數量是 4,000 個用戶。隨着您的客戶端基礎的增加，您但願您的web 應用程序支持更多用戶，這樣，您必須添加更多服務器。固然，這會增長業務成本，尤爲是服務器成本、運輸成本和人工成本。除這些成本上升外，還有一個技術問 題：用戶

 

可能針對每一個請求使用不一樣的服務器，所以，任何共享資源都必須在全部服務器之間共享。例如，在 Java 中，靜態變量和緩存須要在每一個服務器上的 JVMs 之間共享。這就是整個 web 應用程序架構中的瓶頸：一個服務器可以處理的併發鏈接的最大數量。

 

Node 解決這個問題的方法是：更改鏈接鏈接到服務器的方式。每一個鏈接都建立一個進程，該進程不須要配套內存塊，而不是爲每一個鏈接生成一個新的 OS 線程（並向其分配一些配套內存）。Node 聲稱它毫不會死鎖，由於它根本不容許使用鎖，它不會直接阻塞 I/O 調用。Node 還宣稱，運行它的服務器能支持數萬個併發鏈接。事實上，Node 經過將整個系統中的瓶頸從最大鏈接數量更改到單個系統的流量來改變服務器面貌。

 

如今您有了一個能處理數萬條併發鏈接的程序，那麼您能經過 Node 實際構建什麼呢？若是您有一個 web 應用程序須要處理這麼多鏈接，那將是一件很 「恐怖」 的事！那是一種 「若是您有這個問題，那麼它根本不是問題」 的問題。在回答上面的問題以前，咱們先看看 Node 如何工做以及它被設計的如何運行。

 

它對什麼有好處？

正如您此前所看到的，Node 很是適合如下狀況：在響應客戶端以前，您預計可能有很高的流量，但所需的服務器端邏輯和處理不必定不少。Node 表現出衆的典型示例包括：

RESTful API

提供 RESTful API 的 Web 服務接收幾個參數，解析它們，組合一個響應，並返回一個響應（一般是較少的文本）給用戶。這是適合 Node 的理想狀況，由於您能夠構建它來處理數萬條鏈接。它仍然不須要大量邏輯；它本質上只是從某個數據庫中查找一些值並將它們組成一個響應。因爲響應是少許文本，入站請求也是少許的文本，所以流量不高，一臺機器甚至也能夠處理最繁忙的公司的 API 需求。

Twitter 隊列

想像一下像 Twitter 這樣的公司，它必須接收 tweets 並將其寫入數據庫。實際上，每秒幾乎有數千條 tweet 達到，數據庫不可能及時處理高峯時段所需的寫入數量。Node 成爲這個問題的解決方案的重要一環。如您所見，Node 能處理數萬條入站 tweet。它能快速而又輕鬆地將它們寫入一個內存排隊機制（例如 memcached），另外一個單獨進程能夠從那裏將它們寫入數據庫。Node 在這裏的角色是迅速收集 tweet，並將這個信息傳遞給另外一個負責寫入的進程。想象一下另外一種設計（常規 PHP 服務器會本身嘗試處理對數據庫自己的寫入）：每一個 tweet 都會在寫入數據庫時致使一個短暫的延遲，由於數據庫調用正在阻塞通道。因爲數據庫延遲，一臺這樣設計的機器每秒可能只能處理 2000 條入站 tweet。每秒處理 100 萬條 tweet 則須要 500 個服務器。相反，Node 能處理每一個鏈接而不會阻塞通道，從而可以捕獲儘量多的 tweets。一個能處理 50,000 條 tweet 的 Node 機器僅需 20 臺服務器便可。

電子遊戲統計數據

若是您在線玩過《使命召喚》這款遊戲，當您查看遊戲統計數據時，就會當即意識到一個問題：要生成那種級別的統計數據，必須跟蹤海量信息。這樣，若是有數百萬玩家同時在線玩遊戲，並且他們處於遊戲中的不一樣位置，那麼很快就會生成海量信息。Node 是這種場景的一種很好的解決方案，由於它能採集遊戲生成的數據，對數據進行最少的合併，而後對數據進行排隊，以便將它們寫入數據庫。使用整個服務器來跟蹤玩家在遊戲中發射了多少子彈看起來很愚蠢，若是您使用 Apache 這樣的服務器，可能會 有一些有用的限制；但相反，若是您專門使用一個服務器來跟蹤一個遊戲的全部統計數據，就像使用運行 Node 的服務器所作的那樣，那看起來彷佛是一種明智之舉。 

Node.js 的優點是「高併發」，因此很適合用來作 IO 調度，但不太適合用來作複雜計算。 

1. NodeJS做爲web server是一個至關出色的IO服務器，而Nodejs性能之因此如此高是依賴於joyent本身搞的libuv，而開發效率之因此高是由於v8，因此若是你以爲js很差調試，大能夠直接使用libuv，而後各類斷點，固然這是在你不會使用nodejs自帶的debug模塊的前提下

2. NodeJS真的就只能作作web server，其餘免談。問題來源主要是v8與內存問題，以前作過一個相似爬蟲的程序，須要支持萬級別用戶，用NodeJS寫的話，效率沒有問題，但內存問題嚴重，500個任務就須要消耗差很少700-800M空間，後臺用libuv+c重寫，業務邏輯相似，已經能夠單機支持4w-5w的用戶量了。所以若是是對內存有很是嚴格的要求，就建議不要使用node了

不少公司已經嘗試使用nodejs作些實時的併發後端。盲目將nodejs來作web框架使用，並不必定能夠發揮其優點，並且如今大多數公司不會貿然將新興的技術用在覈心的業務上，好比說web框架。但在其真正有優點的領域，有技術前瞻性的技術領頭人，仍是會合理採用。我所知道的使用nodejs作生產級別應用的，包括搜狐，搜狐小紙條後端就是用nodejs來處理消息的推送的，以前跟其負責人有過交流。並不像不少人所言，nodejs會首先在web前段業務層上取代PHP等語言，相反，我認爲，其最有可能會首先在服務器端取代原有的不少mq，server作某些工做，而這也應該是正確的方向。

 

它的工做原理是至關有趣的。傳統的網絡服務技術，是每一個新增一個鏈接（請求）便生成一個新的線程，這個新的線程會佔用系統內存，最終會佔掉全部的可用內存。而 Node.js 僅僅只運行在一個單線程中，使用非阻塞的異步 I/O 調用，全部鏈接都由該線程處理，在 libuv 的加分下，能夠容許其支持數萬併發鏈接（所有掛在該線程的事件循環中）。

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，打開網頁就能進行語音視頻的功能。）