12 conseils pour mettre à l'échelle Node.js

Node.js fonctionne déjà avec succès à l'échelle mondiale, comme en témoignent les applications déployées sur celui-ci de sociétés telles que Netflix, Reddit, Walmart et Ebay. Cependant, il a son propre ensemble de problèmes lors de la mise à l'échelle; du point de vue de la mise à l'échelle des personnes travaillant sur une base de code unique, donc du point de vue de la mise à l'échelle verticale et horizontale dans le cloud. En plus de mon expérience personnelle avec la mise à l'échelle de Node.js lorsque je travaillais pour des entreprises telles que Reddit et Netflix, j'ai parlé avec des experts travaillant chez Microsoft Azure et j'ai trouvé quelques conseils pour vous sur la mise à l'échelle de Node.js dans votre entreprise.

Ecrire un Node.js de qualité

Le plus tôt vous commencez à utiliser des linters, des outils de mise en forme et de vérification de type dans votre code, mieux c'est.

Ces choses peuvent être difficiles à introduire au milieu d'un projet en raison de la quantité potentiellement importante de refactoring qui peut être nécessaire, cela peut également polluer votre historique git, mais à la fin ces outils vous aideront à rendre le code lisible.
Si vous ne les utilisez toujours pas, tournez immédiatement les yeux vers ESLint et Prettier . ESLint protégera votre code contre les mauvais schémas, Prettier vous aidera à formater automatiquement votre code avant de tirer la demande.

Une solution plus substantielle consiste à ajouter des outils tels que Flow ou TypeScript à votre base de code. Ces outils vous permettent de détecter des erreurs plus subtiles, telles que l'appel d'une fonction avec un paramètre numérique au lieu d'une chaîne ou l'appel de la méthode .filter sur des objets au lieu d'un tableau. Malgré la complexité et la nécessité de former votre équipe, ces outils méritent votre attention: ils peuvent accélérer le développement avec Intellisense et éviter les erreurs d'exécution avec la protection de type.

Ecrire des tests

Les tests ont toujours été un problème difficile pour les développeurs. Certains croient fermement au développement piloté par les tests, tandis que d'autres écrivent rarement des tests. Mais il y a un terrain d'entente:

• Définissez les modules clés et rédigez des tests unitaires complets pour eux. Portez une attention particulière aux «voyages heureux»: cas limites et scénarios dans lesquels des erreurs peuvent potentiellement se produire. Pour les autres modules, écrivez un ou deux tests unitaires couvrant les «chemins heureux» et éventuellement les cas courants que vous avez pu découvrir
• Test d'interface utilisateur minimum . L'interface utilisateur change constamment et il est souvent impossible de passer beaucoup de temps à faire des tests de code qui changeront fréquemment.
  
• Ecrivez des tests pour détecter les bugs . Chaque fois que vous trouvez et corrigez un bogue dans votre code, écrivez un test unitaire qui détectera ce bogue à l'avenir.
  
• Écrivez quelques tests d'intégration pour vous assurer que toutes les pièces correspondent.
  
• Écrivez encore moins de tests de bout en bout . Couvrez les chemins clés de votre site, par exemple, si vous créez un site de commerce électronique, il peut être utile de rédiger un test pour entrer sur le site, l'ajouter au panier et vérifier la liste des produits. Ces tests sont coûteux à maintenir, alors pensez à garder un petit noyau de tests que vous pouvez motiver à maintenir.
  

Le point de départ pour écrire des tests est la possibilité de déployer en toute confiance un nouveau code. Écrivez autant de tests qu'il n'y en a pas moins que ce que vous ressentez vous-même, mais essayez de ne pas écrire plus que la liste ci-dessus.

Conception sans état

La clé lors de l'écriture de Node.js évolutif est que vos serveurs n'ont pas à stocker les états pour quelqu'un ou quelque chose. Cela empêchera la mise à l'échelle horizontale. Déplacez l'état vers une autre application et résolvez le problème ailleurs (par exemple Redis, Etcd, ...). Vous devriez y penser à l'avance. Il sera alors très difficile de démêler si vous ne l'avez pas déjà fait auparavant. Cela vous aidera également si vous décidez de décomposer des monolithes en microservices.

Statistiques: pour le développement - Node.js, pour la production - CDN

Comment j'aimerais que les entreprises voient une erreur dans cette erreur. La gestion de vos actifs statiques à partir de votre application Web (en particulier, via quelque chose comme webpack-dev-server ou le serveur de développement de Parsel) est une excellente expérience pour les développeurs car elle raccourcit le cycle d'introduction lors de l'écriture de code. Cependant, vous ne devez jamais servir votre statique via Node.js. Il doit être expédié séparément via un CDN, tel qu'un CDN Azure.

Les retours statiques avec Node.js sont inutilement lents car les CDN sont plus dispersés et donc physiquement plus proches de l'utilisateur final, et les serveurs CDN sont hautement optimisés pour les petites ressources. La maintenance de la statique avec Node est également excessivement coûteuse, car l'heure du serveur Node.js est beaucoup plus chère que celle du serveur CDN.

Commencez à déployer tôt, déployez plus souvent

Je ne vous connais pas, mais quand je débloque quelque chose pour la première fois, ça ne marche jamais. C'est généralement parce que j'ai oublié d'envoyer les bonnes clés privées ou que j'ai codé en dur le chemin vers l'hôte local. Les petits problèmes qui fonctionnent localement à distance refusent de le faire. Ces problèmes peuvent s'accumuler et ce qui pourrait être facilement résolu avant, si, bien sûr, ils sont trop tôt pour le trouver, peut se transformer en un énorme tas d'erreurs incompréhensibles qui ne peuvent tout simplement pas être détectées normalement.

Soit dit en passant, Visual Studio Code vous permet de résoudre ce type de problème . Il vous permet de déployer votre application directement sur Azure en un seul clic. Il s'agit d'un moyen suffisamment simple pour vérifier qu'il n'y a aucun problème de déploiement dans un autre environnement.

Déployez 2 serveurs à la fois

Ce conseil vient de mes connaissances durement acquises et d'une mer de chagrin. L'essence du conseil est qu'il y a peu de différences entre le déploiement de deux serveurs et dix serveurs, et il n'y a pas beaucoup de différence entre le déploiement de dix serveurs et cent serveurs. Cependant, il y a simplement une énorme différence entre le déploiement d'un serveur et de deux serveurs.
Semblable à la question du déploiement de serveurs sans état, à partir de deux serveurs, vous pouvez rapidement surmonter vos problèmes de mise à l'échelle horizontale de sorte que lorsqu'il y a une forte augmentation du trafic, vous êtes prêt à évoluer.

N'ayez pas peur des lignes

Les bases de données modernes font face à une certaine quantité de lecture et d'écriture par elles-mêmes, sans votre aide. Lorsque vous testez votre idée, n'hésitez pas à vous fier à votre base de données pour gérer des charges de travail de petite à moyenne taille.

Une mise à l'échelle prématurée est plus susceptible de vous tuer que de vous sauver. Mais, à un moment donné, votre application grandira et vous ne pourrez plus tout écrire dans la base de données, face à des problèmes de bande passante en lecture et en écriture. Pour certaines applications qui ont un enregistrement léger, ou si vous choisissez une base de données telle que Cassandra, qui gère à grande échelle seule, ce sera un problème plus tard, pour d'autres ce sera plus tôt.

Si vous avez ou aurez bientôt un tel problème, vous aurez des options pour choisir les technologies avec lesquelles vous irez plus loin. L'une de ces technologies peut être la file d'attente de messages. La norme actuelle est Apache Kafka, qui vous permet d'organiser vos messages en rubriques, puis les applications pour vous abonner à cette rubrique. Ainsi, par exemple, vous pouvez accumuler des messages dans l'application, écouter un certain sujet, puis écrire des données par lots dans votre base de données afin qu'elle ne se bouche pas tout le temps. De plus, Kafka s'exécute facilement sur Azure .

Microservices de mise à l'échelle

À mesure que votre application se développe, des divisions logiques naturelles commencent à apparaître. Une partie de l'application peut traiter les paiements, tandis que l'autre partie servira d'API pour votre frontend. Lorsque vous effectuez des divisions logiques, envisagez de leur faire des microservices distincts. Mais attention, l'introduction de microservices est également lourde de complexité. Mais ça vaut le coup. Ainsi, par exemple, chaque microservice peut avoir sa propre métrique. En les évaluant, vous pouvez les mettre à l'échelle indépendamment.

Utilisez des conteneurs

Votre application peut fonctionner correctement localement, mais il peut y avoir de graves problèmes lors du déploiement. Des outils comme Docker et Kubernetes fonctionneront pour vous afin d'éviter ce problème. Docker, que vous pouvez imaginer comme une mini-instance (conteneur) de Linux ou Windows, dans laquelle vous pouvez exécuter l'application; et Kubernetes comme un outil qui relie tous vos conteneurs dans le cloud.

Kubernetes peut être une bête complexe, mais une bête qui résout un problème complexe. Si vous êtes un sorcier DevOps inexpérimenté, vous pouvez avoir des difficultés, je vous recommande donc de commencer par Draft . Si vous connaissez Yeoman pour les projets Javascript, vous pouvez évaluer Draft comme un outil similaire, mais pour les projets Kubernetes: un outil qui crée un filaire pour votre projet. À partir de là, vous pouvez utiliser l'outil Helm pour installer des éléments d'architecture supplémentaires que vous devez construire (par exemple, nginx, plus de Node.js, MongoDB, serveurs Kafka, etc.), presque comme npm pour Kubernetes.

Dès que vous comprendrez l'écosystème Kubernetes, le déploiement dans le cloud deviendra désormais un jeu d'enfant.

Recueillir des métriques

Si vous ne savez pas comment répondre à la question "Comment fonctionne ma candidature?", Alors vous aurez des problèmes ou ils le feront bientôt. Après tout, différents types d'indicateurs au fil du temps vous aideront à améliorer constamment l'état de votre application. Du point de vue des coûts pour l'avenir et du point de vue de la commodité pour l'utilisateur en termes d'amélioration du temps de réponse. Vous devez absolument garder une trace des mesures telles que les chemins lents, les pages vues, le temps de session et d'autres mesures clés qui sont importantes pour votre entreprise.

Il existe de nombreuses façons de collecter ces indicateurs. Des services tels que New Relic et AppDynamics vous fourniront des informations précieuses sur la façon d'améliorer votre application.

Si vous travaillez avec Azure, Application Insights répond également à ce besoin, et il est également facile de brancher d'autres outils comme CI / CD.

CI / CD vous sauvera de tant de douleur

Combien de fois avez-vous gâché le déploiement pendant FTP et arrêté votre serveur pendant plusieurs minutes? C'était avec moi. Vous ne devez jamais vous fier au déploiement du code de production. Comment faire cela en utilisant Visual Studio Code est assez cool, mais c'est principalement à des fins de développement ou de démonstration. Lorsque vous êtes prêt à créer un système au niveau de la production, vous devez utiliser l'intégration continue et le déploiement continu (souvent abrégé CI / CD - intégration continue et déploiement continu).

L'intégration continue est la pratique du développement logiciel, qui consiste à fusionner les copies de travail en une branche principale commune de développement plusieurs fois par jour et à effectuer des assemblages automatisés fréquents du projet pour identifier rapidement les défauts potentiels et résoudre les problèmes d'intégration.

Le déploiement continu prend en charge votre code qui a passé le CI, exécutant les étapes nécessaires pour les créer, les conteneuriser ou les emballer, et les envoyer au serveur. Il est recommandé d'avoir plusieurs niveaux à tester. Vous pouvez d'abord aller sur le serveur de développement interne pour le voir d'abord dans un environnement à faible risque. Vous pouvez le tester avant de l'envoyer dans un environnement QA où vos ingénieurs QA ou éventuellement un service externe confirmeront que tout fonctionne comme prévu. À partir de là, vous pouvez basculer vers un environnement intermédiaire dans lequel votre application est toujours uniquement interne, mais fonctionne à l'aide de données et de paramètres de production, vous pouvez donc la tester dans l'environnement de production lui-même avant de l'envoyer directement en production. Vous pouvez également sélectionner un petit groupe de serveurs pour vérifier le nouveau code: vous et ne dirigez qu'un petit pourcentage du trafic réel vers ces serveurs pour vous assurer que rien ne casse lorsque vous travaillez avec de vrais utilisateurs. S'il se casse, vous savez où chercher le problème. Sinon, vous pouvez passer d'un petit groupe d'utilisateurs à tout le monde.

De nombreux fournisseurs et projets open source répondent à ces besoins. Jenkins, Travis et CircleCI sont d'excellentes options pour CI. Azure a son propre service CI / CD appelé Azure Pipelines, et il est assez intuitif à utiliser, et encore une fois, il se connecte facilement à l'écosystème Azure intégré.

Gardez des secrets

Toute application a forcément des secrets. Il peut s'agir de clés et de lignes secrètes provenant d'informations d'identification, de bases de données, etc. Ce serait très mauvais s'ils se transformaient en de mauvaises mains. Cependant, ils sont nécessaires pour exécuter l'application. Alors on fait quoi? Habituellement, lors du développement, nous utiliserons des outils tels que dotenv pour enregistrer le fichier de configuration localement et pouvoir le lire via process.env dans Node.js. C'est génial pour les développeurs, mais terrible pour la production.

Au lieu de cela, il est utile d'utiliser une sorte d'outil de gestion des secrets. Heureusement, Kubernetes a un système intégré et est assez simple à utiliser. Vous fournissez des secrets Kubernetes du côté du conteneur, puis il les fournira à votre application en tant qu'environnement qui complique considérablement l'attaque.

Azure Key Vault est un autre outil digne de votre attention. Ce qui est cool avec Key Vault, même si Microsoft ne peut pas lire vos clés (vous seul pouvez les décrypter), Azure gardera une trace de vos journaux et gardera une trace de toutes les utilisations douteuses de vos clés pour vous alerter de tout compromis.

Conclusion

Node.js, comme toute autre plate-forme, doit être mis à l'échelle. Et, comme toute autre plate-forme, elle a ses propres tâches et la particularité de la mise à l'échelle, qui méritent d'être connues et qui doivent être prises en compte lors de la conception de grands projets.

Article original: «Onze conseils pour mettre à l'échelle Node.js» ( Fr ).

Je suggère dans les commentaires de partager des conseils que vous pouvez donner sur la mise à l'échelle de Node.js. Ce sera intéressant à entendre.