Den ultimative Node.js produktionscheckliste

Gør du denne Node-ting lige ved produktion? Lad os se nogle almindelige fejl, som folk laver ved at køre Node på produktion (kommer direkte fra mine egne projekter - som codedamn), og hvordan de kan afhjælpes.

Du kan bruge dette som din tjekliste til produktion, når du implementerer Node-apps. Da dette er en artikel, der er klar til produktion , er mange af dem ikke gældende, når du udvikler apps på dit lokale system.

Kør node i klyngetilstand / separate node-processer

Husk, at Node er enkelt gevind. Det kan delegere mange ting (som HTTP-anmodninger og filsystem læse / skrive) til operativsystemet, der håndterer det i et multitrådet miljø. Men stadig kører koden, du skriver, applikationslogikken, altid i en enkelt tråd.

Ved at køre i en enkelt tråd er din Node-proces altid begrænset til kun en enkelt kerne på din maskine. Så hvis du har en server med flere kerner, spilder du beregningskraft, der kører Node, kun en gang på din server.

Hvad betyder "kører Node bare en gang"? Ser du, operativsystemer har en scheduler indbygget i dem, som er ansvarlig for, hvordan udførelsen af ​​processer fordeles på maskinens CPU'er. Når du kun kører 2 processer på en maskine med 2 kerner, bestemmer operativsystemet, at det er bedst at køre begge processer på separate kerner for at presse maksimal ydelse ud.

En lignende ting skal gøres med Node. Du har to muligheder på dette tidspunkt:

  1. Kør node i klyngetilstand - Klyngetilstand er en arkitektur, der kommer ind i selve Node. Med enkle ord forkaster Node flere egne processer og distribuerer belastning gennem en enkelt masterproces.
  2. Kør Node-processer uafhængigt - Denne indstilling er lidt forskellig fra ovenstående i den forstand, at du nu ikke har en masterproces, der styrer de underordnede Node-processer. Dette betyder, at når du gyder forskellige Node-processer, kører de helt uafhængigt af hinanden. Ingen delt hukommelse, ingen IPC, ingen kommunikation, nada.

Ifølge et stackoverflow-svar fungerer sidstnævnte (punkt 2) langt bedre end det tidligere (punkt 1), men er lidt sværere at opsætte.

Hvorfor? Fordi der i en Node-app ikke kun er applikationslogik, men næsten altid når du opretter servere i Node-kode, skal du binde porte. Og en enkelt applikations codebase kan ikke binde den samme port to gange på det samme operativsystem.

Dette problem kan dog let løses. Miljøvariabler, Docker-containere, NGiNX frontend-proxy og så videre er nogle af løsningerne til dette.

Rate Begrænsning af dine slutpunkter

Lad os se det i øjnene. Ikke alle i verden har de bedste intentioner for din arkitektur. Sikker på, angreb som DDoS er simpelthen meget komplicerede at afbøde, og selv giganter som GitHub går ned, når noget lignende sker.

Men det mindste du kan gøre er at forhindre en script-kiddie i at tage din server ned, bare fordi du har et dyrt API-slutpunkt eksponeret fra din server uden nogen hastighedsbegrænsning på plads.

Hvis du bruger Express med Node, er der to smukke pakker, der fungerer problemfrit sammen for at bedømme begrænsning af trafik på lag 7:

  1. Express Rate Limit - //www.npmjs.com/package/express-rate-limit
  2. Express Slow Down - //www.npmjs.com/package/express-slow-down

Express Slow Down tilføjer faktisk inkrementel forsinkelse til dine anmodninger i stedet for at droppe dem. På denne måde er legitime brugere, hvis de DDoS ved et uheld (superaktivitet ved at klikke på knapper her og der), simpelthen bremset og er ikke satsbegrænset.

På den anden side, hvis der er en script-kiddie, der kører scripts for at fjerne serveren, overvåger og begrænser ekspressfrekvensbegrænser den pågældende bruger afhængigt af brugerens IP, brugerkonto eller noget andet, du ønsker.

Hastighedsbegrænsning kunne (skulle!) Også anvendes på lag 4 (lag 4 betyder blokering af trafik, før det opdages indholdet af det - HTTP) via IP-adresse. Hvis du vil, kan du konfigurere en NGiNX-regel, der blokerer trafik på lag 4 og afviser oversvømmelsen af ​​trafik fra en enkelt IP, hvilket sparer dine serverprocesser fra overvældende.

Brug en frontend-server til SSL-afslutning

Node giver ud af boksen understøttelse af SSL-håndtryk med browseren ved hjælp af httpsservermodulet kombineret med de krævede SSL-certifikater.

Men lad os være ærlige her, din ansøgning skal alligevel ikke være beskæftiget med SSL. Dette er ikke noget, applikationslogikken skal gøre. Din nodekode skal kun være ansvarlig for hvad der sker med anmodningen, ikke forbehandling og efterbehandling af data, der kommer ind og ud af din server.

SSL-afslutning henviser til konvertering af trafik fra HTTPS til HTTP. Og der er meget bedre værktøjer til rådighed end Node til det. Jeg anbefaler NGiNX eller HAProxy til det. Begge har gratis tilgængelige versioner, der får jobbet gjort og aflader SSL-opsigelse fra Node.

Brug en frontend-server til statisk filvisning

Igen, i stedet for at bruge indbyggede metoder som express.staticat servere statiske filer, skal du bruge frontend reverse proxy-servere som NGiNX til at servere statiske filer fra disken.

Først og fremmest kan NGiNX gøre det hurtigere end Node (fordi det er bygget fra bunden for kun at gøre det). Men det downloader også filbetjening fra en enkelt-trådet Node-proces, som kunne bruge dens urcyklusser på noget bedre.

Ikke kun dette - frontend-proxyservere som NGiNX kan også hjælpe dig med at levere indhold hurtigere ved hjælp af GZIP-komprimering. Du kan også indstille udløbsoverskrifter, cache-data og meget mere, hvilket ikke er noget, vi skal forvente, at Node skal gøre (Node kan dog stadig gøre det).

Konfigurer fejlhåndtering

Korrekt fejlhåndtering kan spare dig for timevis af fejlretning og forsøg på at reproducere vanskelige fejl. På serveren er det især let at konfigurere arkitektur til fejlhåndtering, fordi det er dig, der kører den. Jeg anbefaler værktøjer som Sentry med Node, der registrerer, rapporterer og e-mails dig, når serveren går ned på grund af en fejl i kildekoden.

Når det er på plads, er det nu tid til at genstarte serveren, når den går ned, så hele webstedet ikke bare går ned i timevis, indtil du manuelt tager det op igen.

Til dette kan du bruge en procesmanager som PM2. Eller endnu bedre, brug et dockeriseret containermiljø med politikker som restart: alwaysmed korrekt opsætning af hukommelse og diskgrænser .

Docker-opsætning sikrer, at selvom din container kører i OME, spinder processen op igen (hvilket muligvis ikke sker i et PM2-miljø, da OS muligvis dræber PM2, hvis der er en hukommelseslækage et eller andet sted i en kørende proces).

Konfigurer logfiler korrekt

Alle svar ligger i logfiler. Serverhacks, servernedbrud, mistænkelig brugeradfærd osv. For det skal du sørge for at:

  1. Hvert anmodningsforsøg er logget med IP-adressen / metoden til anmodning / adgang til stien, dybest set så mange oplysninger som du kan logge på (bortset fra private oplysninger som adgangskoder og kreditkortoplysninger, selvfølgelig)
  2. Dette kan opnås gennem Morgan-pakken
  3. Opsæt filstream-logfiler ved produktion i stedet for konsoloutput. Dette er hurtigere, lettere at se og giver dig mulighed for at eksportere logfiler til online logvisningstjenester.
  4. Ikke alle logbeskeder har samme vægt. Nogle logfiler er bare der til debugging, mens hvis nogle er til stede, kan det indikere en pants-on-fire-situation (som et serverhack eller uautoriseret adgang). Brug winston-logger til at logge forskellige niveauer af logfiler.
  5. Konfigurer logrotation, så du ikke får en logstørrelse i GB'er efter en måned eller deromkring, når du ser serveren.
  6. GZIP dine logfiler efter rotation. Teksten er billig og er meget komprimerbar og let at gemme. Du bør aldrig stå over for problemer med tekstlogfiler, så længe de er komprimeret, og du kører en server med en anstændig diskplads (25 GB +).

Konklusion

Det er let at tage nogle få praksis i produktion til efterretning, som kan spare dig for tårer og timevis af fejlretning senere. Sørg for at følge disse bedste fremgangsmåder, og lad mig vide, hvad du synes, ved at sige Hej på mit twitterhåndtag.

Hvis du kunne lide denne artikel, lad os mødes på sociale medier. Her er min Instagram og Twitter. Jeg er superaktiv og vil meget gerne snakke! Lad os forbinde.

Fred!

Mehul