A Végső Node.js gyártási ellenőrzőlista

A gyártás során csinálod ezt a Node dolgot? Lássuk néhány gyakori hibát, amelyet az emberek elkövetnek a Node futtatásakor a gyártás során (közvetlenül a saját projektjeimből származnak - például a codedamn), és hogyan lehet ezeket enyhíteni.

Ezt a Node alkalmazások telepítésekor használhatja ellenőrző listaként a gyártás során. Mivel ez a gyártásra kész gyakorlatokról szóló cikk, sokuk nem lesz érvényes, amikor alkalmazásokat fejlesztesz a helyi rendszereden.

Futtassa a csomópontot fürt módban / külön csomópont folyamatokban

Ne feledje, hogy a Node egyszálú. Sok mindent delegálhat (például a HTTP kéréseket és a fájlrendszer olvasását / írását) az operációs rendszer számára, amely egy többszálas környezetben kezeli azokat. De az Ön által írt kód, az alkalmazáslogika mindig egyetlen szálon fut.

Ha egyetlen szálon fut, akkor a Node folyamata mindig csak egyetlen magra korlátozódik a gépén. Tehát, ha több magos kiszolgálója van, akkor a Node-ot csak egyszer futtatja a számítási erőforrásokkal a szerverén.

Mit jelent a "Node egyszeri futtatása"? Látja, hogy az operációs rendszerekbe be van építve egy ütemező, amely felelős azért, hogy a folyamatok végrehajtása hogyan oszlik el a gép CPU-ján. Ha csak 2 folyamatot futtat egy kétmagos gépen, az operációs rendszer meghatározza, hogy a legjobb, ha mindkét folyamatot külön magokon futtatja a maximális teljesítmény kiszűrése érdekében.

Hasonló dolgot kell tenni a Node-tal is. Ebben a pillanatban két lehetőséged van:

  1. A csomópont futtatása fürt módban - A fürt mód egy olyan architektúra, amely magába a csomópontba kerül. Egyszerű szavakkal, a Node több saját folyamatot elágazik, és egyetlen terhelési folyamaton keresztül osztja el a terhelést.
  2. A csomópont-folyamatok független futtatása - Ez az opció némileg eltér a fentiektől abban az értelemben, hogy most nincs egy fő folyamat, amely a gyermek-csomópont-folyamatokat irányítja. Ez azt jelenti, hogy amikor különböző Node folyamatokat hoz létre, azok egymástól teljesen függetlenül fognak futni. Nincs megosztott memória, nincs IPC, nincs kommunikáció, nada.

A stackoverflow válasz szerint az utóbbi (2. pont) sokkal jobban teljesít, mint az előbbi (1. pont), de egy kicsit trükkös a beállításhoz.

Miért? Mivel a Node alkalmazásban nem csak az alkalmazás logikája létezik, hanem szinte mindig a szerverek Node kódban történő beállításakor meg kell kötnie a portokat. És egyetlen alkalmazás kódbázisa nem kötheti ugyanazt a portot kétszer ugyanazon az operációs rendszeren.

Ez a probléma azonban könnyen megoldható. A környezeti változók, a Docker konténerek, az NGiNX frontend proxy és így tovább néhány megoldás erre.

Rate Végpontok korlátozása

Nézzünk szembe a tényekkel. A világon nem mindenkinek van a legjobb szándéka az építészetével kapcsolatban. Persze, a DDoS-hez hasonló támadásokat egyszerűen nagyon bonyolult enyhíteni, és még a GitHub-hoz hasonló óriások is lemennek, ha ilyesmi történik.

De a legkevesebb, amit tehet, hogy megakadályozza, hogy egy szkript-gyerek elvigye a szervert, csak azért, mert egy drága API-végpont van kiszolgáltatva a szerverről anélkül, hogy a sebességet korlátozná.

Ha az Express with Node szolgáltatást használja, van 2 gyönyörű csomag, amelyek zökkenőmentesen működnek együtt a 7. réteg forgalmának korlátozásához:

  1. Expressz sebességhatár - //www.npmjs.com/package/express-rate-limit
  2. Express Slow Down - //www.npmjs.com/package/express-slow-down

Az Express Slow Down valójában növekményes késleltetést ad a kéréseinek ahelyett, hogy eldobná azokat. Ily módon a legit felhasználók, ha véletlenül DDoS-t tesznek (szuper tevékenység, ha ide-oda kattintanak a gombokra), egyszerűen lelassulnak, és nincs korlátozva az arányuk.

Másrészt, ha van egy szkript-gyerek, amely szkripteket futtat a szerver lebontására, akkor az Express sebességkorlátozó figyeli és az adott felhasználó sebességkorlátjait, a felhasználói IP-től, felhasználói fióktól vagy bármi mástól függően.

A sebességkorlátozás alkalmazható (kell!) A 4. rétegre is (a 4. réteg azt jelenti, hogy blokkolja a forgalmat, mielőtt felfedezné annak tartalmát - HTTP) az IP-címen keresztül. Ha akarja, beállíthat egy NGiNX szabályt, amely blokkolja a 4. réteg forgalmát, és elutasítja az egyetlen IP-ből érkező forgalom áradatát, ezáltal megmentve a kiszolgáló folyamatait.

SSL feloldásához használjon frontend szervert

A Node dobozon kívül támogatja az SSL kézfogásokat a böngészővel a httpsszerver modul segítségével , a szükséges SSL tanúsításokkal kombinálva.

De legyünk itt őszinték, az alkalmazásodnak egyébként sem kellene foglalkoznia az SSL-lel. Az alkalmazási logikának nem ezt kell tennie. A csomópont-kódja csak a kéréssel történõért felelõs, és nem a szerverrõl be- és kilépõ adatok elõzetes és utólagos feldolgozásáért.

Az SSL megszüntetése a forgalom HTTPS-ről HTTP-re történő konvertálására utal. Ehhez a Node-nál sokkal jobb eszközök állnak rendelkezésre. Az NGiNX-et vagy a HAProxy-t ajánlom hozzá. Mindkettő ingyenes verzióval rendelkezik, amelyek elvégzik a munkát, és az SSL megszüntetését a Node-ból töltik le.

Statikus fájlok kiszolgálásához használjon frontend szervert

A express.staticstatikus fájlok kiszolgálásához használt beépített módszerek használata helyett ismét használjon olyan frontend fordított proxy szervereket, mint az NGiNX, hogy a statikus fájlokat lemezről kiszolgálja.

Először is, az NGiNX ezt gyorsabban képes megtenni, mint a Node (mert a semmiből épül fel, hogy csak ezt tegye). De az egyszálú Node folyamatból is letölti a fájlmegjelenítést, amely az óraciklusait valami jobbra használhatja.

Nem csak ez - a frontend proxy szerverek, például az NGiNX, a GZIP-tömörítéssel is segíthetnek a tartalom gyorsabb eljuttatásában. Beállíthat lejárati fejléceket, gyorsítótáradatokat és még sok minden mást is, amire nem számítanunk kell, hogy a Node meg fogja tenni (azonban a Node továbbra is meg tudja csinálni).

Konfigurálja a hibakezelést

A megfelelő hibakezelés megspórolhatja az órákon át tartó hibakeresést és a nehéz hibák reprodukálását. A szerveren különösen könnyű beállítani az architektúrát a hibakezeléshez, mert te futtatod. Olyan eszközöket ajánlok, mint a Sentry with Node, amely rögzíti, jelentéseket és e-maileket küld Önnek, amikor a szerver összeomlik a forráskód hibája miatt.

Ha ez a helyén van, akkor itt az ideje a kiszolgáló újraindításának, amikor összeomlik, így az egész webhely nem csak órákig megy le, amíg manuálisan nem veszi fel újra.

Ehhez használhat olyan folyamatkezelőt, mint a PM2. Vagy még jobb, ha dokkolt konténerkörnyezetet használ, házirendekkel, például restart: alwaysmegfelelő memóriával és lemezkorlátokkal .

A Docker beállítása biztosítja, hogy még ha a tároló az OME-ben is fut, a folyamat újra felpörög (ami előfordulhat, hogy nem történik meg egy PM2 környezetben, mivel az operációs rendszer megöli a PM2-t, ha memóriaszivárgás van valahol egy futó folyamatban).

Konfigurálja a naplókat megfelelően

Minden válasz naplókban rejlik. A szerver feltörése, a szerver összeomlása, a gyanús felhasználói viselkedés stb. Ehhez meg kell győződnie arról, hogy:

  1. Minden egyes kérési kísérletet naplóznak az elérett IP-címmel / kérés módszerével / elérési útjával, alapvetően annyi információval, amennyit naplózni tud (kivéve a magánadatokat, például a jelszavakat és a hitelkártya-információkat)
  2. Ez a morgan csomag segítségével érhető el
  3. A telepítési fájlfolyam naplózza a gyártást a konzol kimenete helyett. Ez gyorsabb, könnyebben áttekinthető, és lehetővé teszi a naplók exportálását az online napló-megtekintési szolgáltatásokba.
  4. Nem minden naplóüzenet súlya egyenlő. Egyes naplók csak a hibakereséshez vannak, míg ha vannak ilyenek, akkor ez azt jelentheti, hogy a nadrág tüzet okoz (például szerver-feltörés vagy illetéktelen hozzáférés). Különböző szintű naplók naplózásához használja a winston-logger programot.
  5. Beállítás log forgató úgy, hogy nem kap a napló mérete GB után egy hónap múlva, amikor azt látja a szervert.
  6. GZIP a naplófájlokat forgatás után. A szöveg olcsó, nagyon összenyomható és könnyen tárolható. Soha ne szembesüljön a szöveges naplók problémájával, amennyiben azok tömörítve vannak, és megfelelő kiszolgálóval (25 GB +) rendelkező kiszolgálót futtat.

Következtetés

Könnyű figyelembe venni a termelés néhány gyakorlatát, amelyek később könnyeket és órányi hibakeresést takaríthatnak meg Önnek. Ügyeljen arra, hogy betartsa ezeket a bevált gyakorlatokat, és tudassa velem, mit gondol, azzal, hogy szia a twitter kezelőmön.

Ha tetszett ez a cikk, találkozzunk a közösségi médiában. Itt van az Instagramom és a Twitterem. Nagyon aktív vagyok, és szívesen beszélgetnék! Csatlakozzunk.

Béke!

Mehul