# Node.js 成為堆棧的一部分了嗎？ SimpleGeo 說是的。 > 原文： [http://highscalability.com/blog/2011/2/22/is-nodejs-becoming-a-part-of-the-stack-simplegeo-says-yes.html](http://highscalability.com/blog/2011/2/22/is-nodejs-becoming-a-part-of-the-stack-simplegeo-says-yes.html)  這是對 [SimpleGeo](http://simplegeo.com/) 的基礎架構工程師 Wade Simmons 的采訪，這項服務使*易于開發人員根據[節點的使用情況輕松創建位置感知應用程序](http://nodejs.org/)*。 js 作為后端服務組件，取代了一次用 Java，Python 或 Ruby 編寫的代碼。 這些天，Node.js 發現它進入了很多堆棧，我很好奇為什么會這樣。 我在編寫多個消息傳遞系統時的經驗是，程序員不喜歡異步模型，而像 Node.js 這樣的純異步編程模型（尤其是使用服務器端 Javascript 的異步編程模型）將脫穎而出，這真是令人驚訝。 韋德（Wade）足夠慷慨地幫助他們解釋在 SimpleGeo 使用 Node.js 的背后原因。 我非常感謝 Wade 抽出寶貴時間接受采訪。 他做得非常出色，并為現代 Web 堆棧如何在現實生活的坩堝中發展提供了很多見識。 從這里開始對韋德·西蒙斯的采訪： 從一開始，在 SimpleGeo，我們一直是事件驅動，無阻塞網絡服務器的粉絲。 我們的核心 API 服務器是用 Python 編寫在 Tornado Web 服務器（ [http://www.tornadoweb.org](http://www.tornadoweb.org) /）之上的。 我們也有使用 Twisted 編寫的內部服務器（ [http://twistedmatrix.com/](http://twistedmatrix.com/) ）。 當您的服務器將主要是與 IO 綁定時，事件驅動框架非常有意義，并且我們的許多內部服務基本上都是圍繞不同類型的索引和數據庫進行包裝的。 您可能想知道為什么我們已經在其他人中開發和部署了代碼之后，為什么現在要嘗試基于事件的不同框架呢？ 答案是我們希望 Node.js 可以避免的其他框架存在一些缺點。 ### 未設計為異步的語言將阻塞 龍卷風的主要問題是圖書館的支持。 Tornado 提供了一個非阻塞的 HTTP 客戶端，但是對其他協議的支持是有限的或不存在的。 這意味著很容易嘗試使用大量可用于 Python 的庫。 一旦發生這種情況，您將不可避免地開始阻止事件線程，并且到服務器的并發連接將開始彼此阻塞。 這意味著您遇到了兩個世界中最糟糕的一個：單線程服務器，沒有任何潛在的好處。 ### Twisted 與 Python 的配合不佳 Python 的 Twisted 框架具有更好的庫支持，因為已經為其實現了許多協議。 沒有我們想要的那樣廣泛的支持，但是至少它比龍卷風要好得多。 不過，SimpleGeo 上的很多人都不是 Twisted 的粉絲，因為它與 Python 的其余部分無法很好地融合在一起。 例如，方法的命名約定為駝峰式，而不是 python 標準的“帶下劃線的小寫”。 Twisted 的學習曲線也可能更陡峭，因為可以在網上找到更少的示例（盡管確實存在的示例非常好，并且也有一些好書）。 ### 協作多任務模型更易于調試 我們還考慮了協程庫，例如 Eventlet（ [http://eventlet.net/](http://eventlet.net/)）。 在 SimpleGeo 中有很多關于協作多任務或協程是否是更好的樣式的爭論。 決定繼續使用 Node.js 的團隊喜歡協作方法，因為它使調試并發問題更容易測試。 您確切地知道您的程序將控制權交給其他任務，因此追蹤與共享狀態有關的問題要容易得多。 ### 異步瀏覽器體驗正在轉移到服務器 我認為 Node.js 受到青睞的主要原因之一是人們已經習慣了 JavaScript 的異步編程風格。 即使是主要從事后端工作的程序員也可能會不時地涉足客戶端 JavaScript。 JavaScript 并不是完美的語言，但是它的功能卻比大多數更好，并且有許多文獻記載的方法可以避免它的陷阱。 離開瀏覽器世界后，不必再擔心向后兼容性，美好的事物就會開始閃耀。 ### 主要用作服務之間的膠水 當前，Node.js 的主要用途是作為 API 的入口點。 我們有許多不同的內部服務器，我們不同的 API 端點需要為每個請求命中一個或多個。 Node.js 服務器進行身份驗證，發出并行內部請求，然后將結果合并為請求的輸出格式。 該服務器還負責記錄統計信息并記錄詳細的請求信息以供以后解析。 ### 易于調試，測試和良好表現 到目前為止，我們的經驗是編寫 Node.js 代碼非常直觀并且易于測試。 生產部署非常穩定，我們還沒有出現內存泄漏問題或使用如此年輕的平臺（敲敲敲打）會遇到的其他問題。 我們計劃在內部將 Node.js 用于我們框架的其他一些“膠合”樣式； 主要充當后端和客戶端之間的路由器/轉換器的組件。 這些是已經或將要用 Tornado / Twisted 用 Pyt??hon 編寫的組件。 Python 在我們的堆棧中仍然有很多用途，但是隨著我們對它的適應程度不斷提高，Node.js 開始滲透。 ### Node.js 沒有計劃實現 CPU 密集型服務 我們沒有計劃在 Node.js 中做任何占用大量 CPU 的工作。 我們正在 Cassandra 之上使用 Java 進行數據庫層的開發，我們暫時可能會堅持使用它。 我們正在那里而不是在遠程網絡服務器上實施空間邏輯，因此我們可以在數據旁邊進行盡可能多的處理。 我不相信對 v8 中的內存模型有足夠的控制權（某些數據結構實際上可能是腫的），無法完成諸如 Node.js 中的數據庫這樣的密集型操作。 ### 代碼由 SimpleGeo 提供 盡管 Node.js 還很年輕，但社區發展非常迅速，在 github 和 npm（Node 包管理器）上可以找到大量的庫。 SimpleGeo 喜歡開源，因此當我們發現缺少或缺少的圖書館時，請確保釋放所有改進，以便其他人可以使用它們。 從我們的工作中創建的一些庫示例： * [https://github.com/wadey/node-thrift](https://github.com/wadey/node-thrift) * [https://github.com/wadey/node-microtime](https://github.com/wadey/node-microtime) * [https://github.com/wadey/decimaljson](https://github.com/wadey/decimaljson) 在 [https://github.com/simplegeo](https://github.com/simplegeo) 上可以找到更多內容。 ## 相關文章 * Quora： [SimpleGeo 的 API 平臺使用哪種語言編碼？](http://www.quora.com/What-language-is-SimpleGeos-API-platform-coded-in/answer/Joe-Stump) * [HackerNews 線程](http://hackerne.ws/item?id=2251490) “找到 ITS 方式”。 沒有撇號。