de Saurabh Rayakwar

NodeJS: Cele mai bune practici pentru producție

NodeJS Cele mai bune practici pentru productie

Aceasta este o încercare de a înrola cele mai importante practici pentru dezvoltarea și implementarea pe NodeJs.

Lucrez la această tehnologie de ceva vreme. Îmi dau seama de potențialul și locul său uriaș în procesul de dezvoltare. Cu o concurență dură din limbi precum Python și Golang, NodeJS și-a dovedit utilitatea în cazuri de utilizare adecvate.

Înainte să aprofundez cele mai bune practici?, Aș dori să fac o scurtă introducere a ceea ce este un model de microserviciu. Apoi, duceți conversația mai departe de acolo.

NodeJS Cele mai bune practici pentru productie

Deci, ce sunt microserviciile?

Microserviciile – cunoscută și sub numele de arhitectură microservice – este un stil arhitectural care structurează o aplicație ca o colecție de servicii care sunt:

  • Foarte mentenabil și testabil
  • Slab cuplate
  • Implementabil independent
  • Organizat în jurul capacităților de afaceri.

Arhitectura microservice permite livrarea / implementarea continuă a aplicațiilor mari și complexe. De asemenea, permite unei organizații să-și dezvolte stiva de tehnologie.

Cum să decideți dacă aveți nevoie de microservicii

Inițial, când începeți să lucrați la MVP, este posibil să nu fie nevoie să utilizați microservicii. Este posibil ca scalarea axei Y să nu fie agenda dvs. chiar acum. Dar când produsul începe să se maturizeze și, uneori, prea devreme, în cazul în care trebuie să vă ocupați de scalare, descompunerea în module funcționale are mai mult sens pe măsură ce afacerea în sine se descompune. Acesta va fi punctul potrivit pentru a începe să căutăm în modelul de arhitectură de microservicii.

O carte pe care o recomand cu drag este de Chris Richardson aici: http://bit.ly/2EmJDYt.

Microserviciile sunt cel mai frecvent luate în considerare în timp ce înlocuiesc o aplicație monolitică care a fost destul de obișnuită până de curând, când soluțiile de containerizare precum Docker au început să conducă lumea DevOps. Dar mai multe despre asta mai târziu.

Ar fi nedrept dacă aș continua fără să menționez Domain Driven Design (DDD). Este o strategie foarte populară pentru descompunerea produsului dvs. în module funcționale. Prin urmare, este foarte util să creați microservicii.

Deci, ce este un domeniu conform DDD?

Fiecare problemă pe care încercați să o rezolvați este un domeniu.

Fiecare domeniu este subdivizat în contexte delimitate reciproc excluzive. Aceste contexte nu sunt altceva decât zone separate ale acelei probleme.

Într-un model de microserviciu, fiecare context delimitat se corelează cu un microserviciu. Modelele DDD vă ajută să înțelegeți complexitatea domeniului. Pentru modelul de domeniu pentru fiecare context delimitat, identificați și definiți
entități, obiecte de valoare și agregate care vă modelează domeniul.

În funcție de complexitatea software-ului dvs., puteți alege principiile DDD sau puteți efectua o abordare mai simplă.

Scopul este de a realiza un model de domeniu foarte coeziv și cuplat slab. Pentru aceasta urmați această abordare:

1611332948 661 NodeJS Cele mai bune practici pentru productie

Aceasta a fost o scurtă introducere despre DDD. Pentru a afla mai multe despre asta, vă recomand cu drag să citiți cartea excelentă a lui Eric Evans http://bit.ly/2Eoy17l.

Trecând peste.

Sper că ții cu mine. ?

Deci, de aici înainte, voi vorbi mai multe despre practicile specifice NodeJS. Și ceea ce vreau să spun este că microserviciile și DDD vă ajută să evaluați adevăratul potențial al NodeJS. Este complet în sine. Cum? Vom vedea.

Ce model de design să utilizați în timp ce utilizați NodeJs

1611332948 904 NodeJS Cele mai bune practici pentru productie

Modelele de proiectare se referă la proiectarea de software folosind anumite standarde cunoscute de un număr de dezvoltatori.

Există diferite modele de design pe care le putem folosi. Aș dori să introduc și / sau să recapitulez pentru dezvoltatorii care știu deja despre un model numit Repository Pattern.

Acest model facilitează separarea logicii MVC, facilitând în același timp gestionarea definiției modelului și a interacțiunii modelului cu restul logicii.

Se compune din:

  1. Controlor: Gestionează numai cererea și răspunsul și atributele asociate. Nu va avea nici o logică de afaceri, nici o definiție a modelului, nici asociații de modele. (numele folderului: controlere)
  2. Serviciu: Conține logică de afaceri pentru microserviciul dvs. Controlul trece de la controler la un serviciu. Este o relație 1: 1 între un controler și serviciul său și o relație 1: multe între serviciu și depozite. (numele folderului: servicii)
  3. Repertoriu: Interacționează cu modelele care fac parte din folderul modelului. Orice interogare către baza de date prin stratul model va fi formată aici. Nu va avea nicio logică de afaceri. (numele folderului: depozite)
  4. Model: Conține definiția modelului, asociațiile, funcțiile virtuale (de exemplu, în mangustă)
  5. Utilități: Acesta va conține clase / funcții de ajutor care pot fi utilizate ca servicii. De exemplu: un utilitar Redis care are toate funcțiile necesare pentru a interacționa cu Redis. (numele folderului: utilități)
  6. Caz de testare: Aceasta va include cazuri de testare a unității împotriva metodelor controlerului pentru a asigura o acoperire maximă a codului. (numele folderului: spec.)

Pentru a citi mai multe despre acest lucru, puteți consulta acest link: http://bit.ly/2TrSyRS

Ok, spune-mi despre modulele cluster

O singură instanță a Node.js rulează într-un singur fir. Pentru a profita de sistemele multi-core, utilizatorul va dori uneori să lanseze un cluster de procese Node.js pentru a gestiona sarcina.

Modulul cluster permite crearea ușoară a proceselor secundare care partajează toate porturile serverului.

Vă rugăm să rețineți că este ideal să utilizați un proces per container în timp ce utilizați containerizarea Docker pentru implementare prin microservicii. Prin urmare, modulele cluster nu sunt utile atunci când se utilizează docker-ization.

Cum să gestionați fluxul de control în NodeJS

În timp ce utilizați apeluri inversă sau promisiuni, următoarele biblioteci ar putea fi utile:

  1. Asincronizat (https://www.npmjs.com/package/async)
  2. Vasync (cu o mai bună urmărire a operației) https://www.npmjs.com/package/vasync
  3. Bluebird (gestionează promisiunile, de ex. Promise.all etc.) https://www.npmjs.com/package/bluebird

Și bucle?

  • Buclă de serie: executând fiecare pas unul câte unul în ordine
  • Buclă întârziată: buclă cu un timeout
  • Buclă paralelă: colectarea tuturor promisiunilor într-o buclă și executarea în paralel

Și care sunt câteva instrumente utile de scame?

Instrumentele Linting analizează codul dvs. static (fără a-l rula). Identifică potențialele erori sau tipare periculoase. Modele precum utilizarea variabilelor nedeclarate sau instrucțiunile „case” în interiorul unui switch fără o instrucțiune „break”.

Activarea modului strict pe baza de coduri cu „utilizați strict” vă poate ajuta codul să eșueze rapid dacă analizorul JavaScript poate identifica un comportament defectuos global sau similar.

Exemple de scame sunt scame Javascript și scame JS.

Ok, cum ne descurcăm jurnalizarea?

Unele pachete npm utilizate în mod obișnuit sunt:

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

Format posibil de înregistrare:

Pentru sistemele distribuite precum microserviciile, ați dori să explorați urmărirea distribuită utilizând ZipKin etc.

O notă despre pachetele NPM: ar trebui să utilizați un pachet numai dacă vă rezolvă o problemă pe care nu o puteți rezolva singur. Efectuați periodic audituri npm pentru a găsi probleme critice cu dependențele dvs. npm.

Gestionarea excepțiilor neprinse

În mod implicit, Node.js gestionează astfel de excepții imprimând urmele stivei în stderr și ieșind cu codul 1, suprascriind orice proces setat anterior.

Notă: adăugarea unui handler pentru evenimentul „uncaughtException” suprascrie acest comportament implicit.

Alternativ, modificați process.exitCode în handlerul „uncaughtException”, ceea ce va duce la ieșirea procesului cu codul de ieșire furnizat. În caz contrar, în prezența unui astfel de handler, procesul va ieși cu 0.

process.exit (0) – încetarea cu succes
process.exit (1) – încetarea nereușită

Gestionarea respingerilor nesoluționate

Promisiunile sunt omniprezente în codul Node.js și uneori sunt legate de o listă foarte lungă de funcții care returnează promisiuni și așa mai departe.

Dacă nu utilizați un manipulator de respingere corespunzător .catch (…), va fi emis un eveniment de respingere ne-gestionat. Dacă nu sunteți prins și inspectat în mod corespunzător, vă puteți jefui singura șansă de a detecta și, eventual, de a remedia problema.

Sfat suplimentar:

console.time () și console.timeEnd ()

Obiectul consolă are metode time () și timeEnd () care vă ajută să analizați performanța unor piese din codul dvs.

Aceasta nu este o soluție pentru producție, dar poate fi utilizată atunci când nu aveți instrumente mai bune.

Iti multumesc foarte mult pentru timpul acordat.
Înscrieți-vă la Newsletter-ul meu

Alte articole minunate pe subiecte similare:

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