Sådan optimerer du Node.js produktionsinfrastruktur: Bedste praksis

Forord

Hos Forward Email har vi brugt årevis på at perfektionere vores Node.js produktionsmiljø. Denne omfattende guide deler vores gennemprøvede bedste praksis for Node.js produktionsimplementering med fokus på ydeevneoptimering, overvågning og de erfaringer, vi har gjort med at skalere Node.js-applikationer til at håndtere millioner af daglige transaktioner.

Vores 573% Single Core-ydeevneoptimeringsrevolution

Da vi migrerede fra Intel- til AMD Ryzen-processorer, opnåede vi en forbedring af vores Node.js-applikationers ydeevne på 573%. Dette var ikke bare en mindre optimering – det ændrede fundamentalt, hvordan vores Node.js-applikationer yder i produktion, og demonstrerer vigtigheden af single-core-ydeevneoptimering for enhver Node.js-applikation.

Tip

Valg af hardware er afgørende for bedste praksis for Node.js-produktionsimplementering. Vi valgte specifikt DataPacket-hosting på grund af deres AMD Ryzen-tilgængelighed, fordi single-core-ydeevne er afgørende for Node.js-applikationer, da JavaScript-udførelse er single-threaded.

Hvorfor Single Core-ydeevneoptimering er vigtig for Node.js

Vores migrering fra Intel til AMD Ryzen resulterede i:

  • 573% forbedring af ydeevne i anmodningsbehandling (dokumenteret i vores statussides GitHub-problem #1519)
  • Elimineret behandlingsforsinkelse til næsten øjeblikkelige svar (nævnt i GitHub-problem #298)
  • Bedre pris-til-ydelsesforhold for Node.js-produktionsmiljøer
  • Forbedrede svartider på tværs af alle vores applikationsslutpunkter

Ydeevneforøgelsen var så betydelig, at vi nu anser AMD Ryzen-processorer for at være essentielle for enhver seriøs Node.js-produktionsimplementering, uanset om du kører webapplikationer, API'er, mikrotjenester eller enhver anden Node.js-arbejdsbelastning.

For flere detaljer om vores infrastrukturvalg, se:

Opsætning af Node.js-produktionsmiljø: Vores teknologistak

Vores bedste praksis for Node.js-produktionsimplementering inkluderer bevidste teknologiske valg baseret på mange års produktionserfaring. Her er, hvad vi bruger, og hvorfor disse valg gælder for enhver Node.js-applikation:

Pakkehåndtering: pnpm for produktionseffektivitet

Hvad vi bruger: pnpm (fastgjort version)

Vi valgte pnpm frem for npm og yarn til vores Node.js produktionsmiljøopsætning fordi:

  • Hurtigere installationstider i CI/CD-pipelines
  • Effektiv diskplads gennem hard linking
  • Streng afhængighedsopløsning, der forhindrer fantomafhængigheder
  • Bedre ydeevne i produktionsimplementeringer

Note

Som en del af vores bedste praksis for Node.js-produktionsimplementering fastlåser vi nøjagtige versioner af kritiske værktøjer som pnpm for at sikre ensartet adfærd på tværs af alle miljøer og teammedlemmers maskiner.

Implementeringsdetaljer:

Web Framework: Koa til moderne Node.js-produktion

Hvad vi bruger:

Vi valgte Koa frem for Express til vores Node.js produktionsinfrastruktur på grund af dens moderne async/await-understøttelse og renere middleware-sammensætning. Vores grundlægger Nick Baugh bidrog til både Express og Koa, hvilket gav os dyb indsigt i begge frameworks til produktionsbrug.

Disse mønstre gælder, uanset om du bygger REST API'er, GraphQL-servere, webapplikationer eller mikrotjenester.

Vores implementeringseksempler:

Baggrundsjobbehandling: Bree for produktionspålidelighed

Hvad vi bruger: bree planlægger

Vi har oprettet og vedligeholder Bree, fordi eksisterende jobplanlæggere ikke opfyldte vores behov for understøttelse af arbejdstråde og moderne JavaScript-funktioner i Node.js-produktionsmiljøer. Dette gælder for alle Node.js-applikationer, der kræver baggrundsbehandling, planlagte opgaver eller arbejdstråde.

Vores implementeringseksempler:

Fejlhåndtering: @hapi/boom for produktionspålidelighed

Hvad vi bruger: @hapi/boom

Vi bruger @hapi/boom til strukturerede fejlresponser i vores Node.js-produktionsapplikationer. Dette mønster fungerer for alle Node.js-applikationer, der kræver ensartet fejlhåndtering.

Vores implementeringseksempler:

Sådan overvåger du Node.js-applikationer i produktion

Vores tilgang til overvågning af Node.js-applikationer i produktion har udviklet sig gennem årevis med kørsel af applikationer i stor skala. Vi implementerer overvågning på flere lag for at sikre pålidelighed og ydeevne for enhver type Node.js-applikation.

Produktionsovervågning af Node.js på systemniveau

Vores kerneimplementering: helpers/monitor-server.js

Hvad vi bruger: node-os-utils

Vores produktionsovervågningstærskler (fra vores faktiske produktionskode):

  • 2 GB heapstørrelsesgrænse med automatiske advarsler
  • 25 % hukommelsesforbrug advarselstærskel
  • 80 % CPU-forbrug advarselstærskel
  • 75 % diskforbrug advarselstærskel

Warning

Disse tærskler fungerer for vores specifikke hardwarekonfiguration. Når du implementerer Node.js produktionsovervågning, skal du gennemgå vores monitor-server.js implementering for at forstå den nøjagtige logik og tilpasse værdierne til din opsætning.

Overvågning på applikationsniveau for Node.js-produktion

Vores fejlklassificering: helpers/is-code-bug.js

Denne hjælper skelner mellem:

  • Faktiske kodefejl, der kræver øjeblikkelig opmærksomhed
  • Brugerfejl, der er forventet adfærd
  • Eksterne servicefejl, som vi ikke kan kontrollere

Dette mønster gælder for alle Node.js-applikationer - webapps, API'er, mikrotjenester eller baggrundstjenester.

Vores logføringsimplementering: helpers/logger.js

Vi implementerer omfattende feltredigering for at beskytte følsomme oplysninger, samtidig med at vi opretholder nyttige fejlfindingsfunktioner i vores Node.js-produktionsmiljø.

Applikationsspecifik overvågning

Vores serverimplementeringer:

Køovervågning: Vi implementerer køgrænser på 5 GB og timeouts på 180 sekunder til anmodningsbehandling for at forhindre ressourceudtømning. Disse mønstre gælder for alle Node.js-applikationer med køer eller baggrundsbehandling.

Node.js Produktionsovervågning med PM2 Sundhedstjek

Vi har forfinet vores Node.js produktionsmiljøopsætning med PM2 gennem mange års produktionserfaring. Vores PM2-sundhedstjek er afgørende for at opretholde pålideligheden i enhver Node.js-applikation.

Vores PM2-sundhedstjeksystem

Vores kerneimplementering: jobs/check-pm2.js

Vores Node.js produktionsovervågning med PM2 sundhedstjek inkluderer:

  • Kører hvert 20. minut via cron-planlægning
  • Kræver mindst 15 minutters oppetid før en proces betragtes som sund
  • Validerer processtatus og hukommelsesforbrug
  • Genstarter automatisk mislykkede processer
  • Forhindrer genstartsløkker gennem intelligent sundhedskontrol

Caution

For bedste praksis for Node.js-produktionsimplementering kræver vi 15+ minutters oppetid, før vi betragter en proces som sund, for at undgå genstartsløkker. Dette forhindrer kaskadefejl, når processer kæmper med hukommelse eller andre problemer.

Vores PM2-produktionskonfiguration

Opsætning af vores økosystem: Undersøg vores serverstartfiler for opsætning af Node.js produktionsmiljø:

Disse mønstre gælder, uanset om du kører Express-apps, Koa-servere, GraphQL API'er eller andre Node.js-applikationer.

Automatiseret PM2-implementering

PM2-implementering: ansible/playbooks/node.yml

Vi automatiserer hele vores PM2-opsætning via Ansible for at sikre ensartede Node.js-produktionsimplementeringer på tværs af alle vores servere.

System til håndtering og klassificering af produktionsfejl

En af vores mest værdifulde bedste praksisser for Node.js-produktionsimplementering er intelligent fejlklassificering, der gælder for enhver Node.js-applikation:

Vores isCodeBug-implementering til produktion

Kilde: helpers/is-code-bug.js

Denne hjælper leverer intelligent fejlklassificering til Node.js-applikationer i produktion for at:

  • Prioriter faktiske fejl frem for brugerfejl
  • Forbedr vores hændelsesrespons ved at fokusere på virkelige problemer
  • Reducer alarmtræthed fra forventede brugerfejl
  • Bedre forståelse af applikationer versus brugergenererede problemer

Dette mønster fungerer for enhver Node.js-applikation - uanset om du bygger e-handelswebsteder, SaaS-platforme, API'er eller mikrotjenester.

Integration med vores produktionslogning

Vores loggerintegration: helpers/logger.js

Vores logger bruger isCodeBug til at bestemme alarmniveauer og feltredigering, hvilket sikrer, at vi får besked om reelle problemer, samtidig med at vi filtrerer støj fra i vores Node.js-produktionsmiljø.

Få mere at vide om vores fejlhåndteringsmønstre:

Avanceret ydeevnefejlfinding med v8-profiler-next og cpupro

Vi bruger avancerede profileringsværktøjer til at analysere heap-snapshots og fejlfinde OOM (Out of Memory)-problemer, flaskehalse i ydeevnen og Node.js-hukommelsesproblemer i vores produktionsmiljø. Disse værktøjer er essentielle for enhver Node.js-applikation, der oplever hukommelseslækager eller ydeevneproblemer.

Vores profileringsmetode til Node.js-produktion

Værktøjer vi anbefaler:

  • v8-profiler-next - Til generering af heap-snapshots og CPU-profiler
  • cpupro - Til analyse af CPU-profiler og heap-snapshots

Tip

Vi bruger v8-profiler-next og cpupro sammen til at skabe en komplet arbejdsgang til fejlfinding af ydeevne for vores Node.js-applikationer. Denne kombination hjælper os med at identificere hukommelseslækager, flaskehalse i ydeevnen og optimere vores produktionskode.

Sådan implementerer vi Heap Snapshot-analyse

Vores overvågningsimplementering: helpers/monitor-server.js

Vores produktionsovervågning inkluderer automatisk generering af heap-snapshots, når hukommelsestærskler overskrides. Dette hjælper os med at fejlfinde OOM-problemer, før de forårsager programnedbrud.

Vigtige implementeringsmønstre:

  • Automatiske snapshots når heap-størrelsen overstiger 2 GB-tærsklen
  • Signalbaseret profilering til on-demand-analyse i produktion
  • Opbevaringspolitikker til administration af snapshot-lagring
  • Integration med vores oprydningsjob til automatiseret vedligeholdelse

Arbejdsgang til fejlfinding af ydeevne

Undersøg vores faktiske implementering:

Til heap snapshot-analyse:

  1. Installer v8-profiler-next til generering af snapshots
  2. Brug cpupro** til at analysere de genererede snapshots
  3. Implementer overvågningstærskler** svarende til vores monitor-server.js
  4. Opsæt automatisk oprydning** til at administrere snapshot-lagring
  5. Opret signalhåndterere** til on-demand profilering i produktion

Til CPU-profilering:

  1. Generer CPU-profiler i perioder med høj belastning
  2. Analyser med cpupro for at identificere flaskehalse
  3. Fokuser på hot paths og optimeringsmuligheder
  4. Overvåg før/efter forbedringer af ydeevne

Warning

Generering af heap-snapshots og CPU-profiler kan påvirke ydeevnen. Vi anbefaler at implementere throttling og kun aktivere profilering, når specifikke problemer undersøges eller under vedligeholdelsesvinduer.

Integration med vores produktionsovervågning

Vores profileringsværktøjer integreres med vores bredere overvågningsstrategi:

  • Automatisk udløsning baseret på hukommelses-/CPU-tærskler
  • Advarselsintegration når der registreres ydeevneproblemer
  • Historisk analyse til at spore ydeevnetendenser over tid
  • Korrelation med applikationsmålinger til omfattende fejlfinding

Denne tilgang har hjulpet os med at identificere og løse hukommelseslækager, optimere hot code-stier og opretholde stabil ydeevne i vores Node.js-produktionsmiljø.

Node.js Produktionsinfrastruktursikkerhed

Vi implementerer omfattende sikkerhed for vores Node.js produktionsinfrastruktur gennem Ansible-automatisering. Disse fremgangsmåder gælder for alle Node.js-applikationer:

Systemniveausikkerhed for Node.js-produktion

Vores Ansible-implementering: ansible/playbooks/security.yml

Vores vigtigste sikkerhedsforanstaltninger for Node.js produktionsmiljøer:

  • Swap deaktiveret for at forhindre følsomme data i at blive skrevet til disken
  • Core dumps deaktiveret for at forhindre hukommelsesdumps, der indeholder følsomme oplysninger
  • USB-lager blokeret for at forhindre uautoriseret dataadgang
  • Kerneparameterjustering for både sikkerhed og ydeevne

Warning

Når du implementerer bedste praksis for Node.js-produktionsimplementering, kan deaktivering af swap forårsage hukommelsesafbrydelser, hvis din applikation overstiger den tilgængelige RAM. Vi overvåger hukommelsesforbruget omhyggeligt og dimensionerer vores servere passende.

Applikationssikkerhed for Node.js-applikationer

Redigering af vores logfelt: helpers/logger.js

Vi redigerer følsomme felter fra logfiler, herunder adgangskoder, tokens, API-nøgler og personlige oplysninger. Dette beskytter brugernes privatliv, samtidig med at fejlfindingsfunktionerne opretholdes i ethvert Node.js-produktionsmiljø.

Infrastruktursikkerhedsautomatisering

Vores komplette Ansible-opsætning til Node.js-produktion:

Vores sikkerhedsindhold

Lær mere om vores sikkerhedstilgang:

Databasearkitektur til Node.js-applikationer

Vi bruger en hybrid databasetilgang, der er optimeret til vores Node.js-applikationer. Disse mønstre kan tilpasses til enhver Node.js-applikation:

SQLite-implementering til Node.js-produktion

Hvad vi bruger:

Vores konfiguration: ansible/playbooks/sqlite.yml

Vi bruger SQLite til brugerspecifikke data i vores Node.js-applikationer, fordi det leverer:

  • Dataisolering pr. bruger/lejer
  • Bedre ydeevne for forespørgsler fra én bruger
  • Forenklet backup og migrering
  • Reduceret kompleksitet sammenlignet med delte databaser

Dette mønster fungerer godt til SaaS-applikationer, systemer med flere lejere eller enhver Node.js-applikation, der har brug for dataisolering.

MongoDB-implementering til Node.js-produktion

Hvad vi bruger:

Vores opsætningsimplementering: helpers/setup-mongoose.js

Vores konfiguration: config/mongoose.js

Vi bruger MongoDB til applikationsdata i vores Node.js produktionsmiljø, fordi det leverer:

  • Fleksibelt skema til udviklende datastrukturer
  • Bedre ydeevne til komplekse forespørgsler
  • Horisontal skalering muligheder
  • Rigt forespørgselssprog

Note

Vores hybride tilgang optimerer til vores specifikke use case. Undersøg vores faktiske databasebrugsmønstre i kodebasen for at forstå, om denne tilgang passer til dine Node.js-applikationsbehov.

Node.js Produktionsbaggrundsjobbehandling

Vi byggede vores baggrundsjobarkitektur omkring Bree for pålidelig Node.js-produktionsimplementering. Dette gælder for alle Node.js-applikationer, der kræver baggrundsbehandling:

Vores Bree-serveropsætning til produktion

Vores primære implementering: bree.js

Vores Ansible-implementering: ansible/playbooks/bree.yml

Eksempler på produktionsjob

Sundhedsovervågning: jobs/check-pm2.js

Automatisering af oprydning: jobs/cleanup-tmp.js

Alle vores job: Gennemse vores komplette jobkatalog

Disse mønstre gælder for enhver Node.js-applikation, der har brug for:

  • Planlagte opgaver (databehandling, rapporter, oprydning)
  • Baggrundsbehandling (billedstørrelsesændring, afsendelse af e-mails, dataimport)
  • Tilstandsovervågning og vedligeholdelse
  • Udnyttelse af arbejdstråde til CPU-intensive opgaver

Vores jobplanlægningsmønstre for Node.js-produktion

Undersøg vores faktiske jobplanlægningsmønstre i vores jobkatalog for at forstå:

  • Hvordan vi implementerer cron-lignende planlægning i Node.js-produktion
  • Vores fejlhåndtering og gentagelseslogik
  • Hvordan vi bruger arbejdstråde til CPU-intensive opgaver

Automatiseret vedligeholdelse til Node.js-produktionsapplikationer

Vi implementerer proaktiv vedligeholdelse for at forhindre almindelige Node.js-produktionsproblemer. Disse mønstre gælder for alle Node.js-applikationer:

Vores oprydningsimplementering

Kilde: jobs/cleanup-tmp.js

Vores automatiserede vedligeholdelse af Node.js produktionsapplikationer har følgende mål:

  • Midlertidige filer ældre end 24 timer
  • Logfiler ud over opbevaringsgrænser
  • Cachefiler og midlertidige data
  • Uploadede filer, der ikke længere er nødvendige
  • Heap-snapshots fra performance debugging

Disse mønstre gælder for alle Node.js-applikationer, der genererer midlertidige filer, logfiler eller cachelagrede data.

Diskpladshåndtering til Node.js-produktion

Vores overvågningstærskler: helpers/monitor-server.js

  • Køgrænser for baggrundsbehandling
  • Advarselstærskel for 75% diskforbrug
  • Automatisk oprydning når tærsklerne overskrides

Automatisering af infrastrukturvedligeholdelse

Vores Ansible-automatisering til Node.js-produktion:

Implementeringsvejledning til Node.js-produktion

Undersøg vores faktiske kode for bedste praksis i produktionen

Start med disse nøglefiler til opsætning af Node.js produktionsmiljø:

  1. Konfiguration: config/index.js
  2. Overvågning: helpers/monitor-server.js
  3. Fejlhåndtering: helpers/is-code-bug.js
  4. Logføring: helpers/logger.js
  5. Procestilstand: jobs/check-pm2.js

Lær af vores blogindlæg

Vores tekniske implementeringsvejledninger til Node.js-produktion:

Infrastrukturautomatisering til Node.js-produktion

Vores Ansible-playbooks til at studere til Node.js-produktionsimplementering:

Vores casestudier

Vores virksomhedsimplementeringer:

Konklusion: Bedste praksis for Node.js-produktionsimplementering

Vores Node.js-produktionsinfrastruktur demonstrerer, at Node.js-applikationer kan opnå pålidelighed i virksomhedsklassen gennem:

  • Beviste hardwarevalg (AMD Ryzen for 573% single core-ydeevneoptimering)** Kamptestet Node.js-produktionsovervågning med specifikke tærskler og automatiserede svar**
  • Smart fejlklassificering for at forbedre hændelsesrespons i produktionsmiljøer** Avanceret ydeevnedebugging med v8-profiler-next og cpupro til OOM-forebyggelse**
  • Omfattende sikkerhedshærdning gennem Ansible-automatisering**
  • Hybrid databasearkitektur optimeret til applikationsbehov**
  • Automatiseret vedligeholdelse for at forhindre almindelige Node.js-produktionsproblemer

Vigtig konklusion: Undersøg vores faktiske implementeringsfiler og blogindlæg i stedet for at følge generiske bedste praksisser. Vores kodebase leverer virkelige mønstre til Node.js-produktionsimplementering, der kan tilpasses til enhver Node.js-applikation - webapps, API'er, mikrotjenester eller baggrundstjenester.

Komplet ressourceliste til Node.js-produktion

Vores kerneimplementeringsfiler

Vores serverimplementeringer

Vores infrastrukturautomatisering

Vores tekniske blogindlæg

Vores virksomhedscasestudier