Node.js高性能JavaScript 工具包v8.0.0正式版

Node.js高性能JavaScript 工具包v8.0.0正式版是一套用來編寫高性能網絡服務器的 JavaScript 工具包，一係列的變化由此開始。比較獨特的是，Node.js 會假設你是在 POSIX 環境下運行它 Linux 或 Mac OS X。如果你是在 Windows 下，那就需要安裝 MinGW 以獲得一個仿 POSIX 的環境。在 Node 中，Http 是首要的。Node 為創建 http 服務器作了優化，所以你在網上看到的大部分示例和庫都是集中在 web 上(http 框架、模板庫等）。

更新內容

Node.js v8.0.0 已正式發布。v8.0.0 是下一個主要的版本，帶來了一係列重大的變化和新功能，內容十分多，本文包含主要重要的更改和功能的摘要。

npm 5.0.0

npm 最近宣布發布了 5.0.0 版本的 npm 客戶端，現在在 Node.js 8.0.0 中使用了這個重要的新版本。

V8 5.8

Node.js 8.0.0 使用了 V8 5.8，這是 JavaScript 運行時的重要更新，其中包括性能方麵和麵向開發者 API 的重大改進。對 Node.js 開發者來說最重要的是 V8 5.8 保證與 V8 5.9 和即將推出的 V8 6.0 具有 ABI 的向前兼容性，這將有助於確保 Node.js 原生插件生態係統的穩定性。在 Node.js 8 的生命周期中，會計劃升級到 5.9 甚至 6.0。

V8 5.8 引擎還有助於設置新的 TurboFan + Ignition 編譯器管道（compiler pipeline）的轉移，這將為所有 Node.js 應用程序提供重要的新的性能優化。雖然 V8 之前的版本已經存在，但 TurboFan 和 Ignition 將在 V8 5.9 中首次默認啟用。新的編譯器管道代表了這樣一個重大變化 —— Node.js 核心技術委員會（CTC）選擇推遲最初發布安排在 4 月的 Node.js 8，以便更好地適應它。

Node.js API (N-API)

對於使用或創建原生插件的 Node.js 開發者，新的實驗性的 Node.js API（N-API）對於現有的 Native Abstractions for Node.js (nan) 來說是一個重大的改進，它將允許原生插件在一個係統上編譯一次，並在多個版本的 Node.js 上使用。

通過提供一個新的虛擬機不可知的應用程序二進製接口（ABI），原生插件不僅可以在多個版本的 V8 JavaScript 運行時上運行，還可以在微軟的 Chakra-Core 運行時上使用。

N-API 在 Node.js 8.0.0 中是實驗性的功能。

完全支持 WHATWG URL 解析器

WHATWG URL 標準實現的實驗性 URL API 去年已經添加到 Node.js 7.x 中，自那以來一直在積極發展。現在，從 8.0.0 開始，新的 URL 實現現在是 Node.js 中完全支持的非實驗性 API。下麵展示了一個示例用法，官方文檔中提供了更多詳細信息。

const URL = require('url').URL;const myUrl = new URL('/a/path', 'https://example.org/')

這個新的 URL 實現是最重要的，因為它與現代 Web 瀏覽器（如 Chrome，Firefox，Edge 和 Safari）中的 URL 實現和 API 相匹配，允許使用 URL 在不同環境之間共享代碼。

長期支持

Node.js 8 是下一個進入長期支持（LTS）的版本。這將在 2017 年 10 月進入，一旦 Node.js 8 轉換到LTS，將會使用代號 Carbon。

軟件簡介

Node.js 是一套用來編寫高性能網絡服務器的 JavaScript 工具包，一係列的變化由此開始。比較獨特的是，Node.js 會假設你是在 POSIX 環境下運行它 Linux 或 Mac OS X。如果你是在 Windows 下，那就需要安裝 MinGW 以獲得一個仿 POSIX 的環境。在 Node 中，Http 是首要的。Node 為創建 http 服務器作了優化，所以你在網上看到的大部分示例和庫都是集中在 web 上(http 框架、模板庫等）。

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 的服務器所做的那樣，那看起來似乎是一種明智之舉。