每個網站應該是自己的`node.js`進程

Question

我們主持大約150個網站（可能縮放到300+），我們正在考慮遷移到node.js。大多數網站流量相當低<每月1毫焦瀏覽量。

每個網站應該是自己的node.js進程，還是應該使用相同的node.js進程（或一小組負載均衡進程）爲所有網站提供服務。每臺服務器的節點進程數是否存在技術限制或合理限制？

每個站點的進程：感覺效率低下，但我不知道它是否實際上效率低下。確保一個越野車站點不會影響其他站點。

每個核心/小組進程的進程：可能性更高，但是當我需要更新站點代碼庫時，會發生什麼情況，是否會影響其他站點？另外，一個站點中的代碼失敗會影響其他站點。

理想情況下，我希望每個站點有一個進程，以便我們可以託管來自每個工作服務器的所有站點。這樣，當負載增加時，我們可以啓動另一個相同的工作服務器並在兩者之間進行負載平衡，而不必隨意說SiteA轉到ServerA，SiteB轉到ServerB。任何node.js大師可以提供一些智慧？

所有的靜態文件請求都將被Nginx或類似Varnish的東西處理。

Answer 1

這裏有很多問題。總的來說，答案是，這取決於......當你進行整個「表演」討論時，它總是這樣做。話雖如此，建立一個堅實的節點的最簡單的方法是注意以下關於NodeJS的基本事實，並且我也將評論它們與你的問題有關的含義。

• 您在Node中獲得的併發性在某些情況下非常有效，即IO重操作。我們真正在談論的是儘量減少等待下一個請求的停機時間。正因爲如此，Node在一臺機器上每個內核有一個進程的環境中工作得非常好。節點確實能夠最大限度地提高可用於在重負載下處理請求的CPU數量。這就是說，如果你的循環中有零字節的其他工作，通過每個核心有多個節點進程，你可以看到次要的性能提升（就最大請求/秒/處理器核心而言）。但是，我從來沒有看到過增加這個數字3的好處。即使在整個事件循環實際上只是一個文件服務器的情況下。

• 關於每個網站評論的過程。這是一個壞主意，原因很多。舉個例子，一個好的節點服務器可以每秒處理數千個請求。我們的（公司名稱略去的）服務器通過Amazon EC2在中等羣集（大量ram，中央CPU時鐘，4個內核）上託管，但每個羣集的每秒請求數約爲3000次。我們的服務器做了一些CPU工作，對於簡單的文件服務器我相信你可以做得更好。嚴格地說，當然，每個站點都可以通過啓動每個站點的流程/核心/在這裏快速升級來提供更多請求！但是從架構的角度來看，這並不是必須的，而且成本和複雜性都很高。我會推薦的是投資一個有很多RAM的設置。您的服務器緩存經常請求的文件的能力將比您爲特定機器啓動大量進程而無限制地影響您的性能。

• 關於整個RAM的東西。您希望爲給定核心啓動的進程數量取決於兩件事情。一個是你的事件循環做了多少同步工作。同步工作越多，給定請求和事件循環之間的時間間隔越長，以準備好處理下一個請求。如果您有一個繁忙的事件循環，那麼您將處於需要更多進程/ CPU核心的情況。另一件可以影響這一點的事情，特別是與文件服務器相關的是RAM的數量。節點在高RAM環境中運行得更好，但是你可以對任何文件服務器真的這麼說...這和活動異步操作的數量有關。節點工作方式的一個缺點是負載很重，您可以同時獲得大量事件處理程序。然而，如果你的服務器忙於等待大量異步磁盤/ IO的發生，它會比並發/簡單性好，如果你有足夠的內存，它會減慢並崩潰得更快。如果您沒有足夠的RAM來處理所有這些事件處理程序，則您將需要遵循1進程/內核安排。否則，Node會更容易同時啓動多個事件處理程序，並再次導致您比其他情況更快崩潰。

我沒有足夠的信息來告訴你你應該做什麼。這完全依賴於特定服務器的體系結構，站點，站點大小，數據量等等。但是，這三部分知識是幫助您充分利用Node服務器的基本知識。說實話，你有關負載平衡的想法與上面的考慮混在一起，應該對你很好。當然，微優化是可能的，但是如果你做這些事情，你應該很容易地看到數以千計的請求/秒，然後由於DDOS類型的條件而開始出現崩潰。

Answer 2

不，不要這樣做。把事情簡單化！並檢出http://12factor.net/。

幾百個進程與您以其他方式失去的簡單性相比毫無意義。在如此多的級別上，這將是一個可怕的決定，即由單個節點進程提供多個站點（或稱「邏輯應用程序單元」）。

如果您問這個問題，您可能需要在「遷移」到Node之前更多地探究Node。錯誤處理和問題分離在Node中比在其他情況下更復雜。具體而言，domain和cluster API都不成熟。但實際上，這是您違反應用程序的乾淨而簡單的原則。我可以繼續下去。