12 Tipps zum Skalieren von Node.js.

Node.js ist bereits weltweit erfolgreich tätig, wie die darauf bereitgestellten Anwendungen von Unternehmen wie Netflix, Reddit, Walmart und Ebay belegen. Es hat jedoch seine eigenen Probleme bei der Skalierung. unter dem Gesichtspunkt der Skalierung von Personen, die an einer einzelnen Codebasis arbeiten, also unter dem Gesichtspunkt der vertikalen und horizontalen Skalierung in der Cloud. Zusätzlich zu meiner persönlichen Erfahrung mit der Skalierung von Node.js bei Unternehmen wie Reddit und Netflix habe ich mit einigen Experten von Microsoft Azure gesprochen und einige Tipps für Sie zur Skalierung von Node.js in Ihrem Unternehmen ausgearbeitet.

Schreiben Sie eine Qualität Node.js.

Je früher Sie mit der Verwendung von Lintern, Formatierungs- und Typprüfungswerkzeugen in Ihrem Code beginnen, desto besser.

Es kann schwierig sein, diese Dinge mitten in einem Projekt einzuführen, da möglicherweise viel Refactoring erforderlich ist. Dies kann auch Ihren Git-Verlauf verschmutzen. Letztendlich helfen Ihnen diese Tools jedoch dabei, den Code lesbar zu machen.
Wenn Sie sie immer noch nicht verwenden, wenden Sie sich sofort ESLint und Prettier zu . ESLint schützt Ihren Code vor schlechten Mustern. Prettier hilft Ihnen dabei, Ihren Code vor der Pull-Anforderung automatisch zu formatieren.

Eine umfassendere Lösung besteht darin, Ihrer Codebasis Tools wie Flow oder TypeScript hinzuzufügen. Mit diesen Tools können Sie subtilere Fehler abfangen, z. B. das Aufrufen einer Funktion mit einem numerischen Parameter anstelle einer Zeichenfolge oder das Aufrufen der .filter- Methode für Objekte anstelle eines Arrays. Trotz der Komplexität und der Notwendigkeit, Ihr Team zu schulen, verdienen diese Tools Ihre Aufmerksamkeit: Sie können die Entwicklung mit Intellisense beschleunigen und Laufzeitfehler mit Typschutz verhindern.

Schreiben Sie Tests

Tests waren für Entwickler schon immer ein schwieriges Thema. Einige glauben fest an testgetriebene Entwicklung, während andere selten Tests schreiben. Aber es gibt einen Mittelweg:

• Definieren Sie Schlüsselmodule und schreiben Sie umfassende Unit-Tests für diese. Achten Sie besonders auf die „glücklichen Reisen“: Randfälle und Szenarien, in denen möglicherweise Fehler auftreten können. Schreiben Sie für andere Module ein oder zwei Komponententests, die „glückliche Pfade“ und möglicherweise häufige Fälle abdecken, die Sie möglicherweise entdeckt haben
• Minimaler UI-Test . Die Benutzeroberfläche ändert sich ständig und es ist oft unpraktisch, viel Zeit mit Tests für Code zu verbringen, der sich häufig ändert.
  
• Schreiben Sie Tests, um Fehler zu erkennen . Wenn Sie einen Fehler in Ihrem Code finden und beheben, schreiben Sie einen Komponententest, der diesen Fehler in Zukunft beheben wird.
  
• Schreiben Sie einige Integrationstests , um sicherzustellen, dass alle Teile miteinander übereinstimmen.
  
• Schreiben Sie noch weniger End-to-End-Tests . Decken Sie die wichtigsten Pfade auf Ihrer Website ab. Wenn Sie beispielsweise eine E-Commerce-Website erstellen, lohnt es sich möglicherweise, einen Test zu schreiben, um die Website aufzurufen, sie in den Warenkorb zu legen und die Liste der Produkte zu überprüfen. Die Wartung dieser Tests ist teuer. Halten Sie daher einen kleinen Kern von Tests bereit, die Sie zur Wartung motivieren können.
  

Der Ausgangspunkt für das Schreiben von Tests ist die Fähigkeit, neuen Code sicher bereitzustellen. Schreiben Sie so viele Tests, dass es nicht weniger gibt, als Sie selbst fühlen, aber versuchen Sie, nicht mehr als die obige Liste zu schreiben.

Staatenloses Design

Der Schlüssel beim Schreiben skalierbarer Node.js ist, dass Ihre Server keine Status für jemanden oder etwas speichern müssen. Dies verhindert eine horizontale Skalierung. Verschieben Sie den Status in eine andere Anwendung und lösen Sie das Problem an einer anderen Stelle (z. B. Redis, Etcd, ...). Sie sollten im Voraus darüber nachdenken. Dann wird es sehr schwierig sein, es zu entwirren, wenn Sie dies noch nicht getan haben. Es ist auch hilfreich, wenn Sie sich jemals dazu entschließen, Monolithen in Mikrodienste zu zerlegen.

Statistik: für die Entwicklung - Node.js, für die Produktion - CDN

Wie ich möchte, dass Unternehmen einen Fehler in diesem Fehler sehen. Das Bereitstellen Ihrer statischen Assets über Ihre Webanwendung (insbesondere über einen Webpack-Dev-Server oder den Parsel-Dev-Server) ist eine großartige Entwicklererfahrung, da der Einführungszyklus beim Schreiben von Code verkürzt wird. Sie sollten Ihre Statik jedoch niemals über Node.js bereitstellen. Es muss separat über ein CDN geliefert werden, z. B. ein Azure-CDN.

Statische Rückgaben mit Node.js sind unnötig langsam, da CDNs verteilter und daher physisch näher am Endbenutzer sind und CDN-Server für kleine Ressourcen stark optimiert sind. Das Verwalten der Statik mit Node ist ebenfalls unangemessen teuer, da die Serverzeit von Node.js viel teurer ist als die CDN-Serverzeit.

Beginnen Sie frühzeitig mit der Bereitstellung und stellen Sie sie häufiger bereit

Ich kenne dich nicht, aber wenn ich etwas zum ersten Mal entsperre, funktioniert es nie. Dies liegt normalerweise daran, dass ich vergessen habe, die richtigen privaten Schlüssel zu senden, oder den Pfad zum lokalen Host fest codiert habe. Kleine Probleme, die lokal remote arbeiten, lehnen dies ab. Diese Probleme können sich ansammeln, und was vorher leicht behoben werden kann, wenn es natürlich zu früh ist, um es zu finden, kann zu einer großen Menge unverständlicher Fehler führen, die einfach nicht normal abgefangen werden können.

Mit Visual Studio Code können Sie übrigens solche Probleme lösen . Sie können Ihre Anwendung mit einem Klick direkt in Azure bereitstellen. Auf diese Weise können Sie auf einfache Weise überprüfen, ob bei der Bereitstellung in einer anderen Umgebung keine Probleme auftreten.

Stellen Sie 2 Server gleichzeitig bereit

Dieser Rat kommt von meinem hart erarbeiteten Wissen und einem Meer von Herzschmerz. Der Kern des Hinweises besteht darin, dass es nur wenige Unterschiede zwischen der Bereitstellung von zwei Servern und zehn Servern gibt und dass es keinen großen Unterschied zwischen der Bereitstellung von zehn Servern und einhundert Servern gibt. Es gibt jedoch einfach einen großen Unterschied zwischen der Bereitstellung eines Servers und zweier Server.
Ähnlich wie beim Bereitstellen zustandsloser Server, beginnend mit zwei Servern, können Sie Ihre horizontalen Skalierungsprobleme schnell überwinden, sodass Sie bei starkem Datenverkehr skalierbar sind.

Hab keine Angst vor Linien

Moderne Datenbanken können ohne Ihre Hilfe eine gewisse Menge an Lesen und Schreiben alleine bewältigen. Wenn Sie Ihre Idee testen, können Sie sich auf Ihre Datenbank verlassen, um kleine bis mittlere Workloads zu bewältigen.

Vorzeitige Skalierung bringt Sie eher um als rettet Sie. Aber irgendwann wächst Ihre Anwendung, sodass Sie nicht mehr alles in die Datenbank schreiben können, da Probleme mit der Lese- und Schreibbandbreite auftreten. Bei einigen Anwendungen mit einem einfachen Datensatz oder wenn Sie eine Datenbank wie Cassandra auswählen, die selbst mit massiven Skalierungen arbeitet, ist dies später ein Problem, bei anderen früher.

Wenn Sie ein solches Problem haben oder bald haben werden, haben Sie Optionen für die Auswahl von Technologien, mit denen Sie weiter gehen werden. Eine dieser Technologien kann die Nachrichtenwarteschlange sein. Der derzeitige Standard ist Apache Kafka, mit dem Sie Ihre Nachrichten in Themen organisieren und dann Anwendungen, um dieses Thema zu abonnieren. So können Sie beispielsweise Nachrichten in der Anwendung sammeln, ein bestimmtes Thema anhören und dann Daten stapelweise in Ihre Datenbank schreiben, damit diese nicht ständig verstopfen. Darüber hinaus läuft Kafka problemlos auf Azure .

Microservices zur Skalierung

Wenn Ihre Anwendung wächst, erscheinen natürliche logische Unterteilungen. Ein Teil der Anwendung kann Zahlungen verarbeiten, während der andere Teil die API für Ihr Frontend bereitstellt. Wenn Sie logische Unterteilungen vornehmen, sollten Sie diese als separate Mikrodienste betrachten. Seien Sie jedoch vorsichtig, da die Einführung von Microservices ebenfalls mit großer Komplexität verbunden ist. Aber es lohnt sich. So kann beispielsweise jeder Microservice eine eigene Metrik haben. Indem Sie sie auswerten, können Sie sie unabhängig voneinander skalieren.

Verwenden Sie Behälter

Ihre Anwendung funktioniert möglicherweise lokal gut, es können jedoch schwerwiegende Probleme beim Bereitstellen auftreten. Tools wie Docker und Kubernetes funktionieren für Sie, um dieses Problem zu vermeiden. Docker, das Sie sich als Mini-Instanz (Container) von Linux oder Windows vorstellen können, in dem Sie die Anwendung ausführen können; und Kubernetes als Tool, das alle Ihre Container in der Cloud miteinander verbindet.

Kubernetes mag ein komplexes Tier sein, aber ein Tier, das ein komplexes Problem löst. Wenn Sie ein unerfahrener DevOps-Zauberer sind, haben Sie möglicherweise Schwierigkeiten. Ich empfehle daher, mit Draft zu beginnen . Wenn Sie mit Yeoman für Javascript-Projekte vertraut sind, können Sie Draft als ähnliches Tool bewerten, jedoch für Kubernetes-Projekte: ein Tool, das ein Drahtmodell für Ihr Projekt erstellt. Von dort aus können Sie mit dem Helm- Tool zusätzliche Architekturelemente installieren, die Sie erstellen müssen (z. B. nginx, mehr Node.js, MongoDB, Kafka-Server usw.), fast wie npm für Kubernetes.

Sobald Sie das Kubernetes-Ökosystem verstanden haben, wird die Bereitstellung in der Cloud von nun an zu einem Kinderspiel.

Sammeln Sie Metriken

Wenn Sie nicht wissen, wie Sie die Frage "Wie funktioniert meine Bewerbung?" Beantworten sollen, haben Sie Probleme oder sie werden es bald tun. Schließlich helfen Ihnen verschiedene Arten von Indikatoren im Laufe der Zeit dabei, den Status Ihrer Anwendung ständig zu verbessern. Unter dem Gesichtspunkt der Kosten für die Zukunft und unter dem Gesichtspunkt des Benutzerkomforts im Hinblick auf die Verbesserung der Reaktionszeit. Sie sollten auf jeden Fall Kennzahlen wie langsame Pfade, Seitenaufrufe, Sitzungszeit und andere wichtige Kennzahlen verfolgen, die für Ihr Unternehmen wichtig sind.

Es gibt viele Möglichkeiten, diese Indikatoren zu erfassen. Dienste wie New Relic und AppDynamics bieten Ihnen wertvolle Informationen zur Verbesserung Ihrer Anwendung.

Wenn Sie mit Azure arbeiten, erfüllt Application Insights diese Anforderungen ebenfalls und es ist auch einfach, andere Tools wie CI / CD anzuschließen.

CI / CD erspart Ihnen so viel Schmerz

Wie oft haben Sie die Bereitstellung während FTP verdorben und Ihren Server für einige Minuten heruntergefahren? Es war bei mir. Sie sollten sich niemals darauf verlassen, Produktionscode bereitzustellen. Die Vorgehensweise mit Visual Studio Code ist ziemlich cool, dient jedoch hauptsächlich Entwicklungs- oder Demonstrationszwecken. Wenn Sie bereit sind, ein System auf Produktionsebene zu erstellen, sollten Sie die kontinuierliche Integration und die kontinuierliche Bereitstellung verwenden (häufig als CI / CD abgekürzt - kontinuierliche Integration und kontinuierliche Bereitstellung).

Kontinuierliche Integration ist die Praxis der Softwareentwicklung, bei der Arbeitskopien mehrmals täglich zu einem gemeinsamen Hauptentwicklungszweig zusammengeführt und häufige automatisierte Zusammenstellungen des Projekts durchgeführt werden, um potenzielle Fehler schnell zu identifizieren und Integrationsprobleme zu lösen.

Bei der kontinuierlichen Bereitstellung wird der Code, der das CI bestanden hat, übernommen, die erforderlichen Schritte zum Erstellen, Containerisieren oder Packen ausgeführt und an den Server gesendet. Es ist empfehlenswert, mehrere zu testende Ebenen zu haben. Sie können zuerst zum internen Entwicklungsserver gehen, um ihn zuerst in einer Umgebung mit geringem Risiko anzuzeigen. Sie können es zuerst testen, bevor Sie es an eine QS-Umgebung senden, in der Ihre QS-Ingenieure oder möglicherweise ein externer Service bestätigen, dass alles wie erwartet funktioniert. Von dort aus können Sie zu einer Zwischenumgebung wechseln, in der Ihre Anwendung noch nur intern ist, aber mit Produktionsdaten und -einstellungen arbeitet, sodass Sie sie in der Produktionsumgebung selbst testen können, bevor Sie sie direkt an die Produktion senden. Sie können auch eine kleine Gruppe von Servern auswählen, um den neuen Code zu überprüfen: Sie leiten nur einen kleinen Prozentsatz des tatsächlichen Datenverkehrs an diese Server, um sicherzustellen, dass bei der Arbeit mit realen Benutzern nichts kaputt geht. Wenn es kaputt geht, wissen Sie, wo Sie nach dem Problem suchen müssen. Wenn nicht, können Sie von einer kleinen Gruppe von Benutzern zu allen wechseln.

Viele Open Source-Anbieter und -Projekte erfüllen diese Anforderungen. Jenkins, Travis und CircleCI sind großartige Optionen für CI. Azure verfügt über einen eigenen CI / CD-Dienst namens Azure Pipelines, der sehr intuitiv zu bedienen ist und sich problemlos mit dem integrierten Azure-Ökosystem verbinden lässt.

Geheimnisse bewahren

Jede Anwendung hat unweigerlich einige Geheimnisse. Dies können Schlüssel und geheime Zeilen aus Anmeldeinformationen, Datenbanken und vielem mehr sein. Es wäre sehr schlimm, wenn sie in die falschen Hände geraten würden. Sie sind jedoch erforderlich, um die Anwendung auszuführen. Was machen wir also? Normalerweise verwenden wir in der Entwicklung Tools wie dotenv , um die Konfigurationsdatei lokal zu speichern und sie über process.env in Node.js lesen zu können. Das ist großartig für Entwickler, aber schrecklich für die Produktion.

Stattdessen ist es nützlich, eine Art geheimes Verwaltungstool zu verwenden. Glücklicherweise verfügt Kubernetes über ein integriertes System und ist recht einfach zu bedienen. Sie geben Kubernetes-Geheimnisse auf der Containerseite an und geben sie dann an Ihre Anwendung als Umgebung weiter, die den Angriff erheblich erschwert.

Ein weiteres Tool, das Ihre Aufmerksamkeit verdient, ist Azure Key Vault . Was ist cool an Key Vault? Auch wenn Microsoft Ihre Schlüssel nicht lesen kann (nur Sie können sie entschlüsseln), verfolgt Azure Ihre Protokolle und alle zweifelhaften Verwendungen Ihrer Schlüssel, um Sie auf mögliche Kompromisse aufmerksam zu machen.

Fazit

Node.js muss wie jede andere Plattform skaliert werden. Und wie jede andere Plattform verfügt sie über eigene Aufgaben und Skalierungsfunktionen, die wissenswert sind und die beim Entwerfen großer Projekte berücksichtigt werden sollten.

Originalartikel: „Elf Tipps zum Skalieren von Node.js“ ( En ).

Ich schlage in den Kommentaren vor, Tipps zu teilen, die Sie zur Skalierung von Node.js geben können. Es wird interessant sein zu hören.