Używanie tylko Node.js vs. Node.js z Apache / Nginx

W jakich przypadkach należy używać Node.js tylko jako serwera podczas rzeczywistego wdrożenia?

Jeśli ktoś nie chce używać tylko Node.js, co gra lepiej w Node.js? Apache czy Nginx?

Istnieje kilka dobrych powodów, aby trzymać inny serwer WWW przed Node.js:

• Nie musisz martwić się o uprawnienia / setuid dla procesu Node.js. Zwykle tylko root może się połączyć z portem 80. Jeśli pozwolisz nginx / Apache martwić się uruchomieniem jako root, powiązaniem z portem 80, a następnie rezygnacją z uprawnień roota, oznacza to, że Twoja aplikacja Node nie musi się tym martwić.
• Udostępnianie plików statycznych, takich jak obrazy, css, js i HTML. Węzeł może być mniej wydajny w porównaniu do korzystania z odpowiedniego serwera sieci web z plikiem statycznym (Węzeł może być również szybszy w wybranych scenariuszach, ale nie jest to normalne). Oprócz plików obsługujących wydajniej, nie będziesz musiał się martwić o obsługę tagów eTag lub nagłówków kontroli pamięci podręcznej tak, jak gdybyś obsługiwał rzeczy poza węzłem. Niektóre frameworki mogą sobie z tym poradzić, ale chciałbyś mieć pewność. Niezależnie od tego, prawdopodobnie prawdopodobnie wolniej.
• Jak wspomniał Matt Sergeant w swojej odpowiedzi, możesz łatwiej wyświetlić znaczące strony błędów lub wrócić do strony statycznej, jeśli usługa węzła ulegnie awarii. W przeciwnym razie użytkownicy mogą uzyskać limit czasu połączenia.
• Uruchomienie innego serwera WWW przed Węzłem może pomóc w złagodzeniu luk bezpieczeństwa i ataków DoS na Węzeł. Dla przykładu w świecie rzeczywistym, CVE-2013-4450 jest uniemożliwione przez prowadzenie coś podobnego Nginx przed węzłem .

Zastrzegam drugi punkt, mówiąc, że prawdopodobnie powinieneś podawać swoje pliki statyczne za pośrednictwem CDN lub zza serwera buforującego, takiego jak Varnish. Jeśli to robisz, tak naprawdę nie ma znaczenia, czy źródłem jest Node, Nginx czy Apache.

Zastanów się w szczególności nad nginx: jeśli używasz websockets, upewnij się, że korzystasz z najnowszej wersji nginx (> = 1.3.13), ponieważ dodała ona tylko obsługę aktualizacji połączenia w celu korzystania z websockets.

Aby dodać jeszcze jeden powód do odpowiedzi pauljza, używam serwera frontonu, aby mógł obsługiwać 502 strony błędów podczas restartowania serwera backend lub z jakiegoś powodu ulega awarii. Dzięki temu użytkownicy nigdy nie otrzymają błędu dotyczącego niemożności nawiązania połączenia.

Uważam, że używanie Węzła do obsługi plików statycznych jest odpowiednie we wszystkich okolicznościach, o ile wiesz, co robisz . Z pewnością jest to nowy paradygmat używania serwera aplikacji do obsługi plików statycznych, ponieważ tak wiele (co?) Konkurencyjnych technologii (PHP, Ruby, Python itp.) Wymaga serwera WWW takiego jak HTTPD lub Nginx przed serwerami aplikacji .

Każdy obiektywny powód, dla którego kiedykolwiek czytałem przeciwko podawaniu plików statycznych za pomocą Node, opiera się na idei używania tego, co wiesz najlepiej lub używania tego, co jest postrzegane jako lepiej przetestowane / bardziej stabilne. Są to bardzo ważne powody praktycznie, ale mają niewielkie znaczenie czysto techniczne.

O ile nie znajdziesz funkcji, która jest możliwa w przypadku klasycznego serwera WWW, która nie jest możliwa w przypadku Węzła (i wątpię, że to zrobisz), wybierz to, co wiesz najlepiej lub z czym wolisz pracować, ponieważ oba podejścia są w porządku.

Co do Nginx vs Apache - będą „grać” tak samo z Node. Powinieneś porównać je bez względu na Węzeł.

Dodatek: ważne jest również, jeśli potrzebujesz odwrotnego proxy, na przykład, aby uruchomić serwer Websocket na tym samym porcie, lub może mieszać niektóre techonlogie (odpowiedz na niektóre żądania NodeJS i na PHP inne lub cokolwiek innego)