W jaki sposób system zdarzeń Node.js różni się od wzorca aktora Akka?

Pracowałem Node.jsprzez jakiś czas i uważam się za całkiem niezłego z Javą. Ale właśnie odkryłem Akkai od razu zainteresowałem się jego wzorem aktorskim (z tego, co rozumiem).

Teraz, zakładając, że moje umiejętności w zakresie JavaScript były na równi z moimi umiejętnościami Scala / Java, chcę skupić się na praktyczności obu systemów. Zwłaszcza jeśli chodzi o usługi internetowe.

Rozumiem, że Node doskonale radzi sobie z wieloma równoległymi operacjami. Wyobrażam sobie, że dobra usługa sieciowa Node dla systemu zarządzania zasobami byłaby doskonała w obsłudze wielu użytkowników wprowadzających zmiany w tym samym czasie (w aplikacji o dużym natężeniu ruchu).

Ale po przeczytaniu o aktorach w Akce wydaje się, że byłby świetny w tym samym. Podoba mi się pomysł ograniczenia pracy do kawałków wielkości kęsa. Poza tym lata temu parałem się Erlangiem i zakochałem się w używanym przez niego systemie przekazywania wiadomości.

Pracuję nad wieloma aplikacjami, które zajmują się złożoną logiką biznesową i myślę, że nadszedł czas, aby wskoczyć w jedną lub drugą. Szczególnie uaktualnianie starszych aplikacji Struts i C #.

W każdym razie, unikając świętych wojen, w jaki sposób te dwa systemy zasadniczo się różnią? Wygląda na to, że oba są nastawione na ten sam cel. Być może architektura „samonaprawiania” Akki ma przewagę.

EDYTOWAĆ

Wygląda na to, że głosuję blisko. Proszę nie traktuj tego pytania jako „co jest lepsze, węzeł czy akka?”. To, czego szukam, to fundamentalne różnice w bibliotekach sterowanych zdarzeniami, takich jak Node, i bibliotekach opartych na aktorach, takich jak Akka.

Bez wchodzenia w szczegóły (o których wiem zbyt mało w przypadku Node.js), główna różnica polega na tym, że Node.js obsługuje tylko współbieżność bez równoległości, podczas gdy Akka obsługuje oba. Oba systemy są całkowicie sterowane zdarzeniami i mogą być skalowane do dużych obciążeń roboczych, ale brak równoległości utrudnia w Node.js (tj. Równoległość jest jawnie kodowana przez uruchamianie wielu węzłów i odpowiednio wysyłanie żądań; dlatego jest nieelastyczna w czasie wykonywania) , podczas gdy w Akce jest to dość łatwe ze względu na przestrajalne, wielowątkowe executory. Biorąc pod uwagę małe, odizolowane jednostki pracy (wywołania aktorów), Akka automatycznie zrównoleglenie wykonania dla Ciebie.

Inną ważną różnicą jest to, że Akka zawiera system do obsługi awarii w ustrukturyzowany sposób (poprzez nadzorowanie każdego aktora przez swojego rodzica, co jest obowiązkowe), podczas gdy Node.js opiera się na konwencjach dla autorów, aby przekazywać warunki błędu z wywołania zwrotnego do wywołania zwrotnego. Podstawowy problem polega na tym, że systemy asynchroniczne nie mogą stosować standardowego podejścia do wyjątków stosowanych przez synchroniczne systemy oparte na stosie, ponieważ kod „wywołujący” przeniósł się do innych zadań do czasu wystąpienia błędu wywołania zwrotnego. Wbudowana obsługa błędów w systemie zwiększa prawdopodobieństwo, że aplikacje zbudowane w tym systemie są niezawodne.

Powyższe nie ma być wyczerpujące, jestem pewien, że różnic jest o wiele więcej.

Nie używałem jeszcze Akki, ale wygląda na to, że jest podobny do erlang, ale w Javie. W erlangu wszystkie procesy są jak aktorzy w Akce, mają skrzynki pocztowe, możesz przesyłać wiadomości między nimi, masz przełożonych itp.

Node.js używa współbieżnej współbieżności. Oznacza to, że masz współbieżność, gdy na to zezwalasz (na przykład podczas wywoływania operacji io lub jakiegoś zdarzenia asynchronicznego). Kiedy masz długą operację (obliczanie czegoś w długiej pętli), cały system blokuje się.

Erlang stosuje zapobiegawcze przełączanie zadań. Gdy masz długą pętlę, system może ją wstrzymać, aby uruchomić inną operację i kontynuować po pewnym czasie. W przypadku ogromnej współbieżności Node.js jest dobry, jeśli wykonujesz tylko krótkie operacje. Oba obsługują miliony klientów: http://blog.caustik.com/2012/08/19/node-js-w1m-concurrent-connections/ http://blog.whatsapp.com/index.php/2012/01/ 1 milion to tyle 2011 /

W javie potrzebujesz wątków, aby wykonywać dowolną współbieżność, w przeciwnym razie nie możesz wstrzymać wykonywania wewnątrz funkcji, co robi erlang (w rzeczywistości erlang pauzuje między wywołaniami funkcji, ale dzieje się tak ze wszystkimi funkcjami). Możesz wstrzymać wykonywanie między wiadomościami.

Nie jestem pewien, czy to uczciwe porównanie do rysowania. Czytam to bardziej jako „jak wypada porównanie systemu opartego na zdarzeniach z modelem aktora?”. Nodejs może wspierać model aktora, tak jak robi to Scala w Akce, czy C # w Orleanie, w rzeczywistości sprawdź nactor , ktoś wydaje się już tego próbować.

Jeśli chodzi o porównanie systemu zdarzeniowego z modelem aktora, pozwoliłbym opisać to mądrzejszym ludziom. Kilka krótkich uwag dotyczących modelu aktora:

• Model aktora jest oparty na przekazie
• Modele aktorów zwykle dobrze sobie radzą w systemach rozproszonych (klastrach). Oczywiście systemy oparte na zdarzeniach mogą być dystrybuowane, ale myślę, że model aktora ma wbudowaną dystrybucję w odniesieniu do dystrybucji obliczeń. Nowe żądanie może zostać skierowane do nowego aktora w innym silosie, który nie jest pewien, jak to zadziała w przypadku zdarzenia.
• Model aktora wspiera niepowodzenie w tym, że jeśli hej, klaster 1 zostanie wyłączony, obserwator może ogólnie znaleźć inny silos do wykonania pracy

Zobacz też dramat . Jest to kolejna implementacja modelu aktora nodejs.