2013-05-16 19 views
7

Zastanawiam się, czy plik node.js jest dobry dla aplikacji po stronie serwera, która w rzeczywistości nie komunikuje się z przeglądarką, czy komunikacja z przeglądarką jest tylko dodatkową częścią całej aplikacji używanej raczej do zarządzania.Node.js do komunikacji między serwerami

Pomysł jest prosty:

  1. Server odbiera dużą ilość ruchu UDP z krótkich wiadomości zawierających dane użytkownika z innego serwera.

  2. Dla każdej aplikacji wiadomości wykonuje wyszukiwanie DB i odfiltrowuje wiadomości z identyfikatorami użytkownika, które nie znajdują się na białej liście.

  3. Filtrowane wiadomości są przetwarzane, co skutkuje kolejną aktualizacją bazy danych lub wysyłaniem danych do innego serwera.

Czy taki przypadek, dobry scenariusz do nauki node.js, czy może nie ma z tego żadnej korzyści w porównaniu np. Z Java EE?

+3

Myślę, że jest to doskonały program do pisania dla zwierząt (w zależności od bazy danych), sprawdź http://nodejs.org/api/dgram.html dla dokumentacji –

+1

Węzeł najlepiej działa, jeśli większość czasu spędzasz w IO (db, dysk, sieć itd.). Podczas gdy Twoja aplikacja wykonuje IO, węzeł może obsłużyć więcej żądań. Jeśli przetwarza dużo procesora, to utknie w tym i nic więcej. Większość z wymienionych na liście dźwięków jest idealna dla węzła, z wyjątkiem może "Przetworzono wiadomości filtrowane". Jeśli to przetwarzanie jest drogie, możesz mieć problem. –

+0

Czy pojawił się problem z java EE? występy czy współbieżność? masz wiele rozwiązań dla współbieżności w java, czy warto dodać kolejną warstwę w innym języku, nie sądzę, chyba że to, co próbowałem, zawiodło. – mpm

Odpowiedz

3

Zastrzeżenie: Pracuję dla firmy, która współtworzy plik node.js i promuje jego użycie, więc moja opinia może być stronnicza.

Jak wspomniano w komentarzach, plik node.js powinien być odpowiedni dla Ciebie. W rzeczywistości jest to jeden z najczęstszych scenariuszy, w których ludzie używają node.js - pobierają dane z (prawdopodobnie wielu) źródeł, wykonują niewielkie przetwarzanie procesora i odsyłają odpowiedź lub przechowują wynik. Dopóki filtrowanie wiadomości nie jest bardzo kosztowne, implementacja node.js prawdopodobnie przewyższa wersję J2EE.

Powodem jest to, że Node.js jest mocno zoptymalizowany pod kątem rozwiązań, w których serwer spędza większość czasu oczekiwania. Oczekiwanie na połączenie klienta, oczekiwanie na odpowiedź bazy danych, oczekiwanie na odczyt/zapis dysku, oczekiwanie na odczyt odpowiedzi przez klienta, itp.

J2EE stosuje wielowątkowość, w której istnieje jeden wątek do obsługi każdego żądania, czyli w tym przypadku nieoptymalny. Większość wątków czeka, więc nie uzyskuje się korzyści z jednoczesnego uruchamiania dużej ilości kodu, ale nadal trzeba zapłacić cenę za przełączanie kontekstów i wyższe zużycie pamięci.

Jest jedna rzecz, którą chciałbym rozważyć przed pójściem na node.js: czy jesteś w stanie i możesz wdrożyć plik node.js w swoim środowisku produkcyjnym? Przejście na nową platformę wiąże się z pewnymi kosztami, a osoby obsługujące aplikację będą musiały nauczyć się radzić sobie z aplikacjami node.js.

+0

> 'Wdrożenie node.js prawdopodobnie będzie lepsze niż wersja Java EE" - Czy masz dane do obsługi tego? Ten test porównawczy na przykład nie obsługuje dokładnie Twojego twierdzenia: http://www.techempower.com/benchmarks/#section=data-r5 –

+0

> 'Java EE używa wielowątkowości, w której masz jeden wątek do obsługi każdego żądania '- To jedna opcja. Java EE obsługuje również asynchroniczne przetwarzanie HTTP. Zobacz np. http://www.javakeexample.com/2013/01/creating-asynchronous-servlets-with.html i https://blogs.oracle.com/enterprisetechtips/entry/asynchronous_support_in_servlet_3 –

+0

@ArjanTijms Dobre punkty. Nie mam twardych danych do poparcia roszczenia dotyczącego wydajności. Jednak benchmark, o którym mówisz, jest wadliwy, używa klienta mysql, który ma znane problemy z wydajnością. Jeśli chodzi o async J2EE - asynchroniczny serwlet prawdopodobnie nie jest wystarczający, powinieneś używać async do komunikacji z DB itp. I to nie jest typowe użycie dla komponentów J2EE, czyż nie? –

Powiązane problemy