Nodejs介紹

1.javascript

  瀏覽器給網站發請求的過程一直沒怎麼變過。當瀏覽器給網站發了請求。服務器收到了請求,而後開始搜尋被請求的資源。若是有須要,服務器還會查詢一下數據庫,最後把響應結果傳回瀏覽器。不過,在傳統的web服務器中(好比Apache),每個請求都會讓服務器建立一個新的進程來處理這個請求。html

  後來有了Ajax。有了Ajax,咱們就不用每次都請求一個完整的新頁面了,取而代之的是,每次只請求須要的部分頁面信息就能夠了。這顯然是一個進步。可是好比你要建一個FriendFeed這樣的社交網站(相似人人網那樣的刷朋友新鮮事的網站),你的好友會隨時的推送新的狀態,而後你的新鮮事會實時自動刷新。要達成這個需求,咱們須要讓用戶一直與服務器保持一個有效鏈接目前最簡單的實現方法,就是讓用戶和服務器之間保持長輪詢(long polling)。前端

  HTTP請求不是持續的鏈接,你請求一次,服務器響應一次,而後就完了長輪訓是一種利用HTTP模擬持續鏈接的技巧。具體來講,只要頁面載入了,無論你需不須要服務器給你響應信息,你都會給服務器發一個Ajax請求。這個請求不一樣於通常的Ajax請求,服務器不會直接給你返回信息,而是它要等着,直到服務器以爲該給你發信息了,它纔會響應。好比,你的好友發了一條新鮮事,服務器就會把這個新鮮事當作響應發給你的瀏覽器,而後你的瀏覽器就刷新頁面了。瀏覽器收到響應刷新完以後,再發送一條新的請求給服務器,這個請求依然不會當即被響應。因而就開始重複以上步驟。利用這個方法,可讓瀏覽器始終保持等待響應的狀態。雖然以上過程依然只有非持續的Http參與,可是咱們模擬出了一個看似持續的鏈接狀態java

  咱們再看傳統的服務器(好比Apache)。每次一個新用戶連到你的網站上,你的服務器就得開一個鏈接。每一個鏈接都須要佔一個進程,這些進程大部分時間都是閒着的(好比等着你好友發新鮮事,好友發完纔給用戶響應信息。或者等着數據庫返回查詢結果什麼的)。雖然這些進程閒着,可是照樣佔用內存。這意味着,若是用戶鏈接數的增加到必定規模,你服務器沒準就要耗光內存直接癱了。node

  這種狀況怎麼解決?解決方法就是剛纔上邊說的:非阻塞事件驅動。這些概念在咱們談的這個情景裏面其實沒那麼難理解。你把非阻塞的服務器想象成一個loop循環,這個loop會一直跑下去。一個新請求來了,這個loop就接了這個請求,把這個請求傳給其餘的進程(好比傳給一個搞數據庫查詢的進程),而後響應一個回調(callback)。完事了這loop就接着跑,接其餘的請求。這樣下來。服務器就不會像以前那樣傻等着數據庫返回結果了。c++

  若是數據庫把結果返回來了,loop就把結果傳回用戶的瀏覽器,接着繼續跑。在這種方式下,你的服務器的進程就不會閒着等着。從而在理論上說,同一時刻的數據庫查詢數量,以及用戶的請求數量就沒有限制了。服務器只在用戶那邊有事件發生的時候才響應,這就是事件驅動。git

  FriendFeed是用基於Python的非阻塞框架Tornado (知乎也用了這個框架) 來實現上面說的新鮮事功能的。不過,Node.js就比前者更妙了。Node.js的應用是經過javascript開發的,而後直接在Google的變態V8引擎上跑。用了Node.js,你就不用擔憂用戶端的請求會在服務器裏跑了一段可以形成阻塞的代碼了。由於javascript自己就是事件驅動的腳本語言。你回想一下,在給前端寫javascript的時候,更多時候你都是在搞事件處理和回調函數。javascript自己就是給事件處理量身定製的語言。github

  Node.js仍是處於初期階段。若是你想開發一個基於Node.js的應用,你應該會須要寫一些很底層代碼。可是下一代瀏覽器很快就要採用WebSocket技術了,從而長輪詢也會消失。在Web開發裏,Node.js這種類型的技術只會變得愈來愈重要。web

 2.數據庫

首先要了解Node.js,咱們能夠先要了解什麼是v8引擎,能夠說Node.js的誕生很大程度上歸功於v8引擎的出現。
咱們都知道計算機處理器智能識別機器語言,而 JavaScript是一門高級語言,計算機並不能直接讀懂因此咱們須要所謂的引擎來將其轉化成計算機所能理解的語言。v8引擎是由Google推出的,爲其瀏覽器Chrome所設計的開源JavaScript引擎。得益於JIT,編譯模式的改變與編譯階段的優化,JavaScript的性能獲得了一個飛躍。其源代碼是用c++寫的,感興趣的能夠點 GitHub - v8/v8: The official mirror of the V8 git repository
除了對JavaScript性能的大幅提高,v8引擎也提供了「嵌入」的功能,使得開發者也能夠在本身的c++程序中使用「嵌入」的v8引擎,從而高效地編譯JavaScript,並加入c++的feature。要知道,做爲一個底層得多的語言,c++能夠實現的feature可要比JavaScript多得多。舉例說明, JavaScript自己並無read這麼一個function。然而經過v8,咱們能夠將其綁定到一個用c++寫的read callback上,從而經過JavaScript咱們也能夠直接加載文件了。

因而,藉助於v8種種便利的功能,Node.js誕生了。
Node.js是一項服務器技術。咱們都知道客戶端提出服務請求,而服務器端負責處理請求並提供服務。而對於互聯網來講,在Node.js以前JavaScript是一項徹底的客戶端技術,被用於瀏覽器中實現各類動畫,對DOM的操做等等。然後端,即服務端則是由PHP、Python、Ruby、Java等等語言來實現。 Node.js的出現,使得先後端使用同一種語言,統一模型的夢想得以實現。
因此 Node.js到底解決了JavaScript的什麼痛點和問題?
  1. 更好的組織代碼,提高複用性。固然在ES6中這一點也獲得了很大的提高。
  2. 處理文件與數據庫。
  3. 與互聯網進行溝通,以標準化的格式處理請求併發送回答。
  4. 快速地解決如上問題。
同時,Node.js還帶來了許多別的後端技術所不具有,或是不完善的優勢,如其餘人回答中的事件驅動,異步編程,非阻塞式io等等。JavaScript自己語言的特性,以及其的流行程度與社區活躍度給Node.js帶來了各類意義上的優點。

 3.Nodejs的優點和劣勢?

  要講清楚這個問題,先講講整個Web應用程序架構(包括流量、處理器速度和內存速度)中的瓶頸。 瓶頸在於服務器可以處理的併發鏈接的最大數量Node.js解決這個問題的方法是:更改鏈接到服務器的方式。每一個鏈接發射一個在Node.js引擎的進程中運行的事件,而不是爲每一個鏈接生成一個新的OS線程(併爲其分配一些配套內存)。 Node.js不會死鎖,由於它根本不容許使用鎖,它不會直接阻塞 I/O 調用。Node.js還宣稱,運行它的服務器能支持數萬個併發鏈接。
  Node自己運行V8 JavaScript。V8 JavaScript引擎是Google用於其Chrome瀏覽器的底層JavaScript引擎。 Google使用V8建立了一個用C++編寫的超快解釋器,該解釋器擁有另外一個獨特特徵: 您能夠下載該引擎並將其嵌入任何應用程序。V8 JavaScript引擎並不只限於在一個瀏覽器中運行。所以,Node.js實際上會使用Google編寫的V8 JavaScript引擎,並將其重建爲可在服務器上使用。

   Node.js優勢:
  一、採用事件驅動、異步編程,爲網絡服務而設計。 其實Javascript的匿名函數和閉包特性很是適合事件驅動、異步編程。並且JavaScript也簡單易學,不少前端設計人員能夠很快上手作後端設計。
  二、Node.js 非阻塞模式的IO處理給Node.js帶來在相對低系統資源耗用下的高性能與出衆的負載能力,很是適合用做依賴其它IO資源的中間層服務。
  三、Node.js輕量高效,能夠認爲是數據密集型分佈式部署環境下的實時應用系統的完美解決方案。Node很是適合以下狀況:在響應客戶端以前,您預計可能有很高的流量,但所需的服務器端邏輯和處理不必定不少。

   Node.js缺點:
  一、可靠性低
  二、 單進程,單線程,只支持單核CPU,不能充分的利用多核CPU服務器。一旦這個進程崩掉,那麼整個web服務就崩掉了。
  不過以上缺點能夠能夠經過代碼的健壯性來彌補。
 
  目前Node.js的網絡服務器有如下幾種 支持多進程的方式
  #1 開啓多個進程,每一個進程綁定不一樣的端口,用反向代理服務器如 Nginx 作負載均衡,好處是咱們能夠藉助強大的 Nginx 作一些過濾檢查之類的操做,同時可以實現比較好的均衡策略,但壞處也是顯而易見——咱們引入了一個間接層。
  #2 多進程綁定在同一個端口偵聽。在Node.js中,提供了進程間發送「文件句柄」 的功能,這個功能實在是太有用了(貌似是yahoo 的工程師提交的一個patch) ,不明真相的羣衆能夠看這裏: Unix socket magic   #3 一個進程負責監聽、接收鏈接,而後把接收到的鏈接平均發送到子進程中去處理。 在Node.js v0.5.10+ 中,內置了cluster 庫,官方宣稱直接支持多進程運行方式。Node.js 官方爲了讓API 接口傻瓜化,用了一些比較tricky的方法,代碼也比較繞。這種多進程的方式,不可避免的要牽涉到進程通訊、進程管理之類的東西。 此外,有兩個Node.js的module:multi-node 和 cluster ,採用的策略和以上介紹的相似,但使用這些module每每有一些缺點: #1 更新不及時 #2 複雜龐大,每每綁定了不少其餘的功能,用戶每每被綁架 #3 遇到問題難以解決 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。一個能處理50000條tweet的Node機器僅需20臺服務器便可。 三、電子遊戲統計數據 若是您在線玩過《使命召喚》這款遊戲,當您查看遊戲統計數據時,就會當即意識到一個問題:要生成那種級別的統計數據,必須跟蹤海量信息。這樣,若是有數百萬玩家同時在線玩遊戲,並且他們處於遊戲中的不一樣位置,那麼很快就會生成海量信息。Node是這種場景的一種很好的解決方案,由於它能採集遊戲生成的數據,對數據進行最少的合併,而後對數據進行排隊,以便將它們寫入數據庫。使用整個服務器來跟蹤玩家在遊戲中發射了多少子彈看起來很愚蠢,若是您使用Apache這樣的服務器,可能會有一些有用的限制;但相反,若是您專門使用一個服務器來跟蹤一個遊戲的全部統計數據,就像使用運行Node的服務器所作的那樣,那看起來彷佛是一種明智之舉。 總的來講,Node.js的應用場景 1) 適合 JSON APIs——構建一個Rest/JSON API服務,Node.js能夠充分發揮其非阻塞IO模型以及JavaScript對JSON的功能支持(如JSON.stringfy函數) 單頁面、多Ajax請求應用——如Gmail,前端有大量的異步請求,須要服務後端有極高的響應速度 基於Node.js開發Unix命令行工具——Node.js能夠大量生產子進程,並以流的方式輸出,這使得它很是適合作Unix命令行工具 流式數據——傳統的Web應用,一般會將HTTP請求和響應當作是原子事件。而Node.js會充分利用流式數據這個特色,構建很是酷的應用。如實時文件上傳系統transloadit 準實時應用系統——如聊天系統、微博系統,但Javascript是有垃圾回收機制的,這就意味着,系統的響應時間是不平滑的(GC垃圾回收會致使系統這一時刻中止工做)。若是想要構建硬實時應用系統,Erlang是個不錯的選擇 2) 不適合 CPU使用率較重、IO使用率較輕的應用——如視頻編碼、人工智能等,Node.js的優點沒法發揮 簡單Web應用——此類應用的特色是,流量低、物理架構簡單,Node.js沒法提供像Ruby的Rails或者Python的Django這樣強大的框架 NoSQL + Node.js——若是僅僅是爲了追求時髦,且本身對這兩門技術還未深刻理解的狀況下,不要冒險將業務系統搭建在這兩個漂亮的名詞上,建議使用MySQL之類的傳統數據庫 若是系統能夠匹配Node.js的適用場景,那麼是時候採起具體的措施來講服老闆了。 說服本身老闆採用Node.js的方式 構建一個簡單的原型——花一週時間構建系統某一部分的原型是很是值得的,同時也很容易和老闆在某一點達成一致,等到系統真的在某一部分應用了Node.js,就是打開局面的時候 尋找開發者——首先JavaScript語言的普及度很高,通常公司都不乏Web前端工程師,而此類工程師的學習門檻也很是低。這就意味着Node.js很容易招人,或者公司就隱藏了一些高手 強大的社區支持——Node.js社區很是活躍,吸引不少優秀的工程師,這就意味着公司能夠很容易從社區獲得免費或者付費的支持 系統性能考慮——JavaScript引擎Google V8,加之原生異步IO模型,使得Node.js在性能的表現很是出色,處理數以千計的併發請求很是輕鬆 專業公司的支持——使用開源技術的最大問題是,原做者不承諾對其產品進行技術支持或者質量保證。如今Node.js已經獲得Joyent公司的贊助,這就保證了將來Node.js的發展是可持續性的
相關文章
相關標籤/搜索