假設我正在構建一個三層網站，在後端使用Mongo DB，並在瀏覽器中使用一些非常輕量級的JavaScript（比如，只需在窗體上進行驗證，也許可以使用一些特殊的控件來引發一些AJAX請求）。我需要爲「中間」層選擇一種技術（我們可以將其分成多個子層，但這裏的細節並不是重點，只是整體技術的選擇），我想在這裏關閉一些原始數據從數據庫中出來，並將其渲染爲一些我推送給瀏覽器的HTML。一個相當典型的瘦客戶端Web架構。Node.js是否應該用於密集處理？
我的安全選擇是在Java中實現這個中間層，使用像Jongo這樣的庫來與Mongo DB交談，也許Jackson會編組/解組JSON，以便在他們發出AJAX請求時與我的控件進行交談。還有一些用於在服務器上呈現我的HTML的模板框架。
我喜歡的JavaScript（好的部分：
不過，我真的拋出這一切窗外，並使用Node.js的這個中間層，由於以下原因的想法很感興趣），並且假設這個應用程序的業務邏輯比Java更具表現力。
它的JavaScript無處不在。在堆棧上的任何位置工作時，無需在語言之間進行切換，實際上也可以在面向對象和功能範例之間切換。層之間沒有翻譯管道，JSON在本地無處不在。
我可以在客戶端和服務器上重新使用驗證邏輯。
如果將來我決定在瀏覽器中執行HTML渲染客戶端，我可以重用現有的模板，像Backbone一樣，只需很少的重構/重測工作。
如果您在這一點上並且喜歡Node，以上所有內容都顯得很明顯。所以我應該選擇節點吧？
但是......這就是對我而言的原因：衆所周知，Node基於單線程異步I/O Web服務器模型。這對於我的數據服務請求方面的可伸縮性和性能來說非常棒，但我的業務邏輯又如何呢？那麼我的模板渲染呢？這些東西不會對單線程上的所有請求造成巨大的瓶頸嗎？
兩個顯而易見的解決方案浮現在腦海中，但他們都沒有坐在右：
保持「阻塞」業務邏輯在那裏，只是使用節點實例的羣集和負載均衡，服務請求真正平行。好，那麼爲什麼Node不是多線程的呢？或者，這是否總是這樣的想法：保持簡單愚蠢，並避免在基本情況下出現多線程複雜性的可能性，如果需要多核處理能力，程序員可以在此基礎上做額外的安裝工作？
保留單個節點實例，並通過調用某些其他多線程應用服務器上運行的業務邏輯的某個Java實現來保持它爲非阻塞狀態。好的，這個選項完全無效了我列出的使用Node的每個專業人員（實際上它比僅使用Java增加了複雜性），除了CRUD請求到DB的性能和可伸縮性方面可能的增益之外。
這最終使我對我問題的要點 - 我錯過了節點難題的一些巨大的重要的一塊，有我剛拿到手的事實完全錯誤的，或者是節點只是不適合在搗鼓業務邏輯服務器？換句話說，Node是否比坐在I/O上的其他一些實現更適合用於坐在數據庫上並以更高性能和更可伸縮的方式服務多個CRUD請求？你必須在下面的某個層次或甚至客戶端執行所有業務邏輯才能保持合理的性能和可伸縮性級別？考慮到所有關於Node的嗡嗡聲，我寧願希望它帶來更多的表現。我很樂意相信！
節點是單線程的原因是所有當前化身（不是計劃或「邊緣化身」）中的JavaScript都是單線程的。這條規則有一些例外，例如客戶端的webworkers，但即使如此，您的線程模型也不同於您在其他語言中可能使用的模式。 – Matt
好點，我並不是真正意義上的真正的多線程，因爲在線程可以共享數據，我的意思是類似於webworkers - 只是一個請求被並行服務的方式，沒有彼此的知識，出於盒子。這顯然可以通過對節點服務器進行集羣來實現 - 我的問題是您不希望這樣做的用例是什麼？單節點Web服務器有什麼實際用途？ – davnicwil