NodeJS: beste praksis for produksjon

Dette er et forsøk på å verve de viktigste praksisene for å utvikle og distribuere på NodeJs.

Jeg har jobbet med denne teknologien en stund selv. Jeg innser det enorme potensialet og stedet i utviklingsprosessen. Med tøff konkurranse fra språk som Python og Golang, har NodeJS bevist sin nytteverdi i passende brukssaker.

Før jeg går nærmere inn på beste praksis , vil jeg gjerne gjøre en kort introduksjon til hva et mikroservicemønster er. Ta deretter samtalen videre derfra.

Så, hva er mikroservices?

Microservices - også kjent som mikroservice-arkitekturen - er en arkitektonisk stil som strukturerer en applikasjon som en samling av tjenester som er:

  • Meget vedlikeholdbar og testbar
  • Løst koblet
  • Uavhengig distribuerbar
  • Organisert rundt forretningsegenskaper.

Mikroservicearkitekturen muliggjør kontinuerlig levering / distribusjon av store, komplekse applikasjoner. Det gjør det også mulig for en organisasjon å utvikle sin teknologiback.

Hvordan bestemme om du trenger mikroservices

Til å begynne med, når du nettopp begynner å jobbe med MVP, trenger du kanskje ikke å bruke mikroservices. Skalering av Y-aksen er kanskje ikke din agenda akkurat nå. Men når produktet begynner å modnes og noen ganger for tidlig der du må takle skalering, er nedbrytningen til funksjonelle moduler mer fornuftig ettersom virksomheten i seg selv dekomponerer. Dette vil være det rette punktet for å begynne å se nærmere på mikroservices arkitekturmønster.

En bok som jeg anbefaler er av Chris Richardson her: http://bit.ly/2EmJDYt.

Mikroservices er ofte vurdert mens de erstatter en monolitisk applikasjon som pleide å være ganske vanlig inntil nylig da containeringsløsninger som Docker begynte å styre DevOps verden. Men mer om det senere.

Det ville være urettferdig hvis jeg fortsetter uten å nevne Domain Driven Design (DDD). Det er en veldig populær strategi for å dekomponere produktet ditt i funksjonelle moduler. Derfor er det veldig nyttig å lage mikroservices.

Så, hva er et domene per DDD?

Hvert problem du prøver å løse, er et domene.

Hvert domene er delt inn i gjensidig eksklusive avgrensede kontekster. Disse sammenhengene er bare separate områder av det aktuelle problemet.

I et mikroservice-mønster korrelerer hver avgrenset kontekst til en mikroservice. DDD-mønstre hjelper deg med å forstå kompleksiteten i domenet. For domenemodellen for hver bundet kontekst identifiserer og definerer du
enheter, verdiobjekter og aggregater som modellerer domenet ditt.

Avhengig av programvarens kompleksitet kan du velge DDD-prinsippene eller utføre en enklere tilnærming.

Målet er å oppnå en svært sammenhengende og løst koblet domenemodell. Følg denne tilnærmingen for det:

Dette var en kort introduksjon på DDD. For å lære mer om det, anbefaler jeg sterkt å lese Eric Evans sin utmerkede bok http://bit.ly/2Eoy17l.

Går videre.

Jeg håper du holder på med meg.

Så herfra vil jeg snakke mer om praksis som er spesifikk for NodeJS. Og det jeg mener er at mikroservices og DDD hjelper deg med å sammenligne det virkelige potensialet til NodeJS. Det er komplett i seg selv. Hvordan? Vi får se.

Hvilket designmønster du skal bruke når du bruker NodeJs

Designmønstre handler om å designe programvare ved å bruke visse standarder som er kjent for en rekke utviklere.

Det er forskjellige designmønstre vi kan bruke. Jeg ønsker å introdusere og / eller oppsummere for utviklere som allerede vet om et mønster som heter Repository Pattern.

Dette mønsteret gjør det lettere å skille MVC-logikken, samtidig som det gjør det enklere å håndtere modelldefinisjon og modellinteraksjon med resten av logikken.

Det består av:

  1. Kontroller: Den håndterer bare forespørsel og svar og tilhørende attributter. Det vil ikke ha noen forretningslogikk eller definisjon av modeller eller modellforeninger også. (mappenavn: kontrollere)
  2. Tjeneste: Den inneholder forretningslogikk for mikroservice. Kontrollen går fra kontroller til en tjeneste. Det er et 1: 1-forhold mellom en kontroller og dens tjeneste og et 1: mange forhold mellom tjeneste og depoter. (mappenavn: tjenester)
  3. Repository: Det samhandler med modellene som er en del av modellmappen. Eventuelle spørsmål til databasen gjennom modellsjiktet vil bli dannet her. Det vil ikke ha noen forretningslogikk. (mappenavn: depoter)
  4. Modell: Den inneholder modelldefinisjonen, assosiasjoner, virtuelle funksjoner (f.eks. I mongoose)
  5. Verktøy: Dette vil inneholde hjelperklasser / funksjoner som kan brukes som tjenester. F.eks: et Redis-verktøy som har alle funksjonene som kreves for å samhandle med Redis. (mappenavn: verktøy)
  6. Testtilfelle: Dette vil omfatte enhetstesttilfeller mot kontrollmetoder for å sikre maksimal kodedekning. (mappenavn: spesifikasjon)

For å lese mer om dette, kan du se på denne lenken: http://bit.ly/2TrSyRS

OK, Fortell meg om klyngemoduler

En enkelt forekomst av Node.js kjører i en enkelt tråd. For å dra nytte av flerkjernesystemer, vil brukeren noen ganger ønske å starte en klynge av Node.js-prosesser for å håndtere belastningen.

Klyngemodulen gjør det enkelt å lage barneprosesser som alle deler serverporter.

Vær oppmerksom på at det er ideelt å bruke en prosess per container mens du bruker Docker-containerisering for distribusjon gjennom mikroservices. Klyngemoduler er derfor ikke nyttige når du bruker docker-ization.

Hvordan håndtere kontrollstrøm i NodeJS

Følgende biblioteker kan være nyttige når du bruker tilbakeringinger eller løfter.

  1. Async (https://www.npmjs.com/package/async)
  2. Vasync (med bedre sporing av drift) https://www.npmjs.com/package/vasync
  3. Blåfugl (håndterer løfter f.eks. Løfte.all osv.) Https://www.npmjs.com/package/bluebird

Og sløyfer?

  • Seriesløyfe: utfører hvert trinn ett for ett i rekkefølge
  • Forsinket sløyfe: sløyfe med en timeout
  • Parallell loop: samle alle løfter i en loop og utfør parallelt

Og hva er noen nyttige fôringsverktøy?

Fôringsverktøy analyserer koden din statisk (uten å kjøre den). De identifiserer potensielle feil eller farlige mønstre. Mønstre som bruk av ikke-erklærte variabler, eller "case" -utsagn i en bryter uten "break" -uttalelse.

Aktivering av streng modus på kodebasen din med "bruk streng" kan hjelpe koden din å mislykkes raskt hvis JavaScript-parseren kan identifisere en lekker eller global dårlig oppførsel.

Eksempler på linter er Javascript lof og JS lof.

Ok, hvordan håndterer vi logging?

Noen ofte brukte npm-pakker er:

  • Winston (https://www.npmjs.com/package/winston)
  • Bunyan (https://www.npmjs.com/package/bunyan)

Mulig loggformat:

For distribuerte systemer som mikroservices, vil du utforske distribuert sporing ved hjelp av ZipKin etc.

Merknad om NPM-pakker: Du bør bare bruke en pakke hvis den løser et problem for deg som du ikke kan løse selv. Utfør regelmessig npm-revisjoner for å finne kritiske problemer med npm-avhengighetene dine.

Håndtering av usagte unntak

Som standard håndterer Node.js slike unntak ved å skrive ut stakelsporen til stderr og avslutte med kode 1, og tilsidesetter tidligere innstilt prosess.exitCode

Merk: Å legge til en behandler for hendelsen 'uncaughtException' overstyrer denne standardoppførselen.

Alternativt kan du endre process.exitCode i behandleren "uncaughtException" som vil resultere i at prosessen går ut med den oppgitte utgangskoden. Ellers, i nærvær av en slik behandler, vil prosessen avslutte med 0.

process.exit (0) - vellykket avslutning
process.exit (1) - mislykket avslutning

Håndtering av ubehandlede avslag

Løfter er allestedsnærværende i Node.js-kode og noen ganger lenket til en veldig lang liste over funksjoner som gir løfter og så videre.

Hvis du ikke bruker en riktig .catch (...) avvisingsbehandler, vil det føre til at en ubehandlet avvisningshendelse sendes ut. Hvis du ikke blir fanget og inspisert på riktig måte, kan du frarve deg din eneste sjanse til å oppdage og muligens løse problemet.

Ekstra Tips:

console.time () og console.timeEnd ()

Konsollobjektet har time () og timeEnd () metoder som hjelper deg med å analysere ytelsen til deler av koden din.

Dette er ikke en løsning for produksjon, men den kan brukes når du ikke har bedre verktøy.

Tusen takk for tiden din.
Registrer deg for mitt nyhetsbrev

Andre fantastiske artikler om lignende emner:

  1. https://microservices.io
  2. https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/ddd-oriented-microservice