Node.js na maszynach wielordzeniowych

Node.js wygląda interesująco, ALE muszę coś przeoczyć - czy Node.js nie jest dostrojony tylko do działania na jednym procesie i wątku?

Jak zatem skalować w przypadku procesorów wielordzeniowych i serwerów wieloprocesorowych? W końcu świetnie jest zrobić jak najszybciej serwer jednowątkowy, ale przy dużych obciążeniach chciałbym użyć kilku procesorów. To samo dotyczy przyspieszania aplikacji - wydaje się, że dzisiaj sposób polega na użyciu wielu procesorów i równoległym wykonywaniu zadań.

Jak Node.js pasuje do tego obrazu? Czy jego pomysłem jest jakoś dystrybuowanie wielu instancji czy co?

[ Ten post jest aktualny na dzień 2012-09-02 (nowszy niż powyżej). ]

Node.js absolutnie skaluje się na maszynach wielordzeniowych.

Tak, Node.js to jeden wątek na proces. Jest to bardzo celowa decyzja projektowa i eliminuje potrzebę radzenia sobie z semantyką blokowania. Jeśli się z tym nie zgadzasz, prawdopodobnie jeszcze nie zdajesz sobie sprawy z tego, jak niesamowicie trudno jest debugować wielowątkowy kod. Aby uzyskać głębsze wyjaśnienie modelu procesu Node.js i dlaczego działa on w ten sposób (i dlaczego NIGDY nie będzie obsługiwać wielu wątków), przeczytaj mój drugi post .

Jak więc skorzystać z mojego 16-rdzeniowego urządzenia?

Dwie drogi:

• W przypadku dużych zadań obliczeniowych, takich jak kodowanie obrazu, Node.js może odpalać procesy potomne lub wysyłać wiadomości do dodatkowych procesów roboczych. W tym projekcie miałbyś jeden wątek zarządzający przepływem zdarzeń i procesami N wykonującymi ciężkie zadania obliczeniowe i przełamującymi pozostałe 15 procesorów.
• Aby skalować przepustowość w usłudze sieciowej, powinieneś uruchomić wiele serwerów Node.js w jednym urządzeniu, po jednym na rdzeń i rozdzielić ruch między nimi. Zapewnia to doskonałe powinowactwo procesora i skaluje przepustowość prawie liniowo wraz z liczbą rdzeni.

Skalowanie przepustowości w serwisie internetowym

Od wersji 6.0.X Node.js dołączono moduł klastra od razu po wyjęciu z pudełka, co ułatwia skonfigurowanie wielu pracowników węzłów, którzy mogą nasłuchiwać na jednym porcie. Zauważ, że NIE jest to to samo, co starszy moduł „klastra” learnboost dostępny przez npm .

if (cluster.isMaster) {
  // Fork workers.
  for (var i = 0; i < numCPUs; i++) {
    cluster.fork();
  }
} else {
  http.Server(function(req, res) { ... }).listen(8000);
}

Pracownicy będą rywalizować o akceptację nowych połączeń, a najmniej obciążony proces najprawdopodobniej wygra. Działa całkiem dobrze i może dość dobrze skalować przepustowość w urządzeniach wielordzeniowych.

Jeśli masz wystarczająco dużo obciążenia, aby zająć się wieloma rdzeniami, będziesz chciał zrobić jeszcze kilka rzeczy:

1. Uruchom usługę Node.js za web-proxy, takim jak Nginx lub Apache - coś, co może dławić połączenie (chyba że chcesz, aby warunki przeciążenia całkowicie obniżyły pole), przepisz adresy URL, podaj zawartość statyczną i proxy inne pod-usługi.

2. Okresowo przetwarzaj procesy robocze. W przypadku długotrwałego procesu nawet niewielki wyciek pamięci ostatecznie się zsumuje.

3. Skonfiguruj zbieranie / monitorowanie dziennika

PS: Dyskusja między Aaronem i Christopherem w komentarzach do innego postu (na początku tego pisma, jest to najwyższy post). Kilka komentarzy na ten temat:

• Model wspólnego gniazda jest bardzo wygodny, ponieważ pozwala wielu procesom nasłuchiwać na jednym porcie i konkurować o akceptację nowych połączeń. Koncepcyjnie możesz pomyśleć o gotowym Apache, który robi to ze znaczącym zastrzeżeniem, że każdy proces zaakceptuje tylko jedno połączenie, a następnie umrze. Utrata wydajności Apache polega na tworzeniu nowych procesów i nie ma nic wspólnego z operacjami gniazd.
• Dla Node.js, gdy N pracowników konkuruje na jednym gnieździe, jest niezwykle rozsądnym rozwiązaniem. Alternatywą jest skonfigurowanie front-endu, takiego jak Nginx, i zapewnienie tego ruchu proxy do poszczególnych pracowników, na przemian między pracownikami w celu przypisania nowych połączeń. Te dwa rozwiązania mają bardzo podobną charakterystykę wydajności. A ponieważ, jak wspomniałem powyżej, prawdopodobnie będziesz chciał, aby Nginx (lub alternatywa) przewyższał twoją usługę węzła, wybór tutaj jest naprawdę pomiędzy:

Współużytkowane porty: nginx (port 80) --> Node_workers x N (sharing port 3000 w/ Cluster)

vs

Poszczególne porty: nginx (port 80) --> {Node_worker (port 3000), Node_worker (port 3001), Node_worker (port 3002), Node_worker (port 3003) ...}

Prawdopodobnie istnieją pewne zalety konfiguracji poszczególnych portów (możliwość mniejszego sprzężenia między procesami, bardziej wyrafinowane decyzje dotyczące równoważenia obciążenia itp.), Ale zdecydowanie więcej pracy trzeba skonfigurować, a wbudowany moduł klastra jest niski - alternatywa złożoności, która działa dla większości ludzi.

Jedną z metod byłoby uruchomienie wielu instancji node.js na serwerze, a następnie umieszczenie przed nimi modułu równoważenia obciążenia (najlepiej nieblokującego, takiego jak nginx).

Ryan Dahl odpowiada na to pytanie podczas wykładu technicznego, który wygłosił w Google zeszłego lata. Parafrazując: „po prostu uruchom wiele procesów węzłowych i użyj czegoś rozsądnego, aby umożliwić im komunikację, np. IPC w stylu sendmsg () lub tradycyjne RPC”.

Jeśli chcesz od razu zabrudzić sobie ręce, sprawdź moduł spark2 Forever . To sprawia, że ​​odradzanie wielu procesów węzłowych jest niezwykle łatwe. Obsługuje konfigurowanie udostępniania portów, aby każdy z nich mógł akceptować połączenia z tym samym portem, a także automatycznie się odradzał, jeśli chcesz mieć pewność, że proces zostanie zrestartowany, jeśli / kiedy umrze.

AKTUALIZACJA - 11.11.11 : Wydaje się, że w społeczności węzłów istnieje konsensus, że klaster jest teraz preferowanym modułem do zarządzania wieloma instancjami węzłów na maszynie. Zawsze jest też warte obejrzenia.

Możesz użyć modułu klastra . Sprawdź to .

var cluster = require('cluster');
var http = require('http');
var numCPUs = require('os').cpus().length;

if (cluster.isMaster) {
    // Fork workers.
    for (var i = 0; i < numCPUs; i++) {
        cluster.fork();
    }

    cluster.on('exit', function(worker, code, signal) {
        console.log('worker ' + worker.process.pid + ' died');
    });
} else {
    // Workers can share any TCP connection
    // In this case its a HTTP server
    http.createServer(function(req, res) {
        res.writeHead(200);
        res.end("hello world\n");
    }).listen(8000);
}

Wiele węzłów wykorzystuje wszystkie dostępne rdzenie.
Zajrzyj na http://github.com/kriszyp/multi-node .

Dla prostszych potrzeb możesz uruchomić wiele kopii węzła na różnych numerach portów i umieścić przed nimi moduł równoważenia obciążenia.

Node Js obsługuje klastrowanie, aby w pełni wykorzystać możliwości twojego procesora. Jeśli nie korzystasz z klastra, prawdopodobnie marnujesz swoje możliwości sprzętowe.

Klastrowanie w Node.js pozwala tworzyć osobne procesy, które mogą współużytkować ten sam port serwera. Na przykład, jeśli uruchamiamy jeden serwer HTTP na porcie 3000, jest to jeden serwer działający na jednym wątku na jednym rdzeniu procesora.

Kod pokazany poniżej pozwala ci na klastrowanie twojej aplikacji. Ten kod jest oficjalnym kodem reprezentowanym przez Node.js.

var cluster = require('cluster');
var numCPUs = require('os').cpus().length;

if (cluster.isMaster) {
    // Fork workers.
    for (var i = 0; i < numCPUs; i++) {
        cluster.fork();
    }

    Object.keys(cluster.workers).forEach(function(id) {
        console.log("I am running with ID : " + cluster.workers[id].process.pid);
    });

    cluster.on('exit', function(worker, code, signal) {
        console.log('worker ' + worker.process.pid + ' died');
    });
} else {

    //Do further processing.
}

sprawdź ten artykuł, aby uzyskać pełny samouczek

Jak wspomniano powyżej, klaster skaluje i równoważy Twoją aplikację we wszystkich rdzeniach.

dodając coś podobnego

cluster.on('exit', function () {
  cluster.fork();
});

Zrestartuje wszystkich nieudanych pracowników.

W dzisiejszych czasach wiele osób woli również PM2 , który obsługuje klastrowanie i oferuje kilka ciekawych funkcji monitorowania .

Następnie dodaj Nginx lub HAProxy przed kilkoma maszynami działającymi z klastrowaniem, a masz wiele poziomów przełączania awaryjnego i znacznie większą pojemność.

Przyszła wersja węzła pozwoli ci na rozwidlenie procesu i przekazanie do niego wiadomości, a Ryan stwierdził, że chce znaleźć sposób na współdzielenie programów obsługi plików, więc nie będzie to prosta implementacja Web Workera.

W tej chwili nie jest to łatwe rozwiązanie, ale wciąż jest bardzo wcześnie, a node jest jednym z najszybciej rozwijających się projektów open source, jakie kiedykolwiek widziałem, więc spodziewaj się czegoś niesamowitego w najbliższej przyszłości.

Spark2 jest oparty na Spark, który nie jest już obsługiwany. Klaster jest jego następcą i ma kilka fajnych funkcji, takich jak tworzenie jednego procesu roboczego na rdzeń procesora i odradzanie martwych pracowników.

Korzystam z pracownika Node do uruchamiania procesów w prosty sposób z mojego głównego procesu. Wygląda na to, że działa świetnie, a my czekamy na oficjalny sposób.

Nowym dzieckiem na tym bloku jest „Up” LearnBoost .

Zapewnia „ponowne ładowanie bez przestojów” i dodatkowo tworzy wielu pracowników (domyślnie liczbę procesorów, ale można je konfigurować), aby zapewnić najlepsze ze wszystkich światów.

Jest nowy, ale wydaje się dość stabilny i z radością go używam w jednym z moich bieżących projektów.

Klaster Moduł pozwala na wykorzystanie wszystkich rdzeni komputerze. W rzeczywistości możesz to wykorzystać w zaledwie 2 poleceniach i bez dotykania kodu za pomocą bardzo popularnego menedżera procesów pm2 .

npm i -g pm2
pm2 start app.js -i max

Możesz uruchomić aplikację node.js na wielu rdzeniach, używając modułu klastra w połączeniu z OS modułem , który może być używany do wykrywania liczby posiadanych procesorów.

Na przykład wyobraźmy sobie, że masz servermoduł, który uruchamia prosty serwer HTTP na backendie i chcesz go uruchomić dla kilku procesorów:

// Dependencies.
const server = require('./lib/server'); // This is our custom server module.
const cluster = require('cluster');
const os = require('os');

 // If we're on the master thread start the forks.
if (cluster.isMaster) {
  // Fork the process.
  for (let i = 0; i < os.cpus().length; i++) {
    cluster.fork();
  }
} else {
  // If we're not on the master thread start the server.
  server.init();
}

Możliwe jest również zaprojektowanie usługi sieciowej jako kilku niezależnych serwerów nasłuchujących na gniazdach unix, dzięki czemu można wcisnąć funkcje takie jak przetwarzanie danych do osobnych procesów.

Jest to podobne do większości architektur serwerów WWW służących do przeszukiwania / baz danych, w których proces cgi obsługuje logikę biznesową, a następnie wypycha i ściąga dane przez gniazdo unix do bazy danych.

różnica polega na tym, że przetwarzanie danych jest zapisywane jako serwer węzła nasłuchujący na porcie.

jest bardziej złożony, ale ostatecznie to właśnie tam musi iść rozwój wielordzeniowy. architektura wieloprocesowa wykorzystująca wiele komponentów dla każdego żądania WWW.

Możliwe jest skalowanie NodeJS do wielu skrzynek za pomocą modułu równoważenia obciążenia czystego TCP (HAProxy) przed wieloma skrzynkami, z których każdy uruchamia jeden proces NodeJS.

Jeśli masz trochę wspólnej wiedzy do dzielenia się między wszystkimi instancjami, możesz użyć centralnego sklepu Redis lub podobnego, do którego można uzyskać dostęp ze wszystkich instancji procesu (np. Ze wszystkich skrzynek)