Крайният списък за производство на Ultimate Node.js

Правите ли това нещо с Node точно в производството? Нека да видим някои често срещани грешки, които хората правят при изпълнението на Node в производството (идващи направо от собствените ми проекти - като codedamn) и как могат да бъдат смекчени.

Можете да използвате това като свой контролен списък при производството, когато внедрявате приложения на Node. Тъй като това е статия с практически практики , много от тях няма да се прилагат, когато разработвате приложения в локалната си система.

Изпълнете възел в режим на клъстер / отделни процеси на възел

Не забравяйте, че Node е с единична резба. Той може да делегира много неща (като HTTP заявки и четене / запис на файлова система) на операционната система, която го обработва в многонишкова среда. Но все пак кодът, който ВИ пишете, логиката на приложението, винаги работи в една нишка.

Като се изпълнява в една нишка, вашият Node процес винаги е ограничен само до едно ядро ​​на вашата машина. Така че, ако имате сървър с множество ядра, губите изчислителна мощност, изпълнявайки Node само веднъж на вашия сървър.

Какво означава „стартиране на Node само веднъж“? Виждате ли, операционните системи имат вграден планировчик, който отговаря за това как изпълнението на процесите се разпределя между процесорите на машината. Когато стартирате само 2 процеса на двуядрена машина, ОС определя, че е най-добре да изпълнявате двата процеса на отделни ядра, за да изтласкате максимална производителност.

Подобно нещо трябва да се направи с Node. В този момент имате две възможности:

  1. Стартирайте Node в клъстерния режим - Клъстерният режим е архитектура, която се пече в самия Node. С прости думи, Node разклонява повече собствени процеси и разпределя натоварването чрез един главен процес.
  2. Стартирайте Node процеси независимо - Тази опция е малко по-различна от горната, в смисъл, че сега нямате главен процес, контролиращ дъщерните Node процеси. Това означава, че когато създавате различни процеси на Node, те ще работят напълно независимо един от друг. Няма споделена памет, няма IPC, няма комуникация, нада.

Според отговора на stackoverflow последният (точка 2) се представя далеч по-добре от първия (точка 1), но е малко трик за настройка.

Защо? Тъй като в приложението Node не само има логика на приложението, но и почти винаги, когато настройвате сървъри в Node код, трябва да свържете портове. И една кодова база на приложение не може да свързва един и същи порт два пъти в една и съща операционна система.

Този проблем обаче е лесно отстраним. Променливи на околната среда, контейнери на Docker, интерфейсен прокси NGiNX и т.н. са някои от решенията за това.

Ограничаване на вашите крайни точки

Нека си го кажем. Не всеки по света има най-добри намерения за вашата архитектура. Разбира се, атаките като DDoS са много сложни за смекчаване и дори гиганти като GitHub намаляват, когато се случи нещо подобно.

Но най-малкото, което можете да направите, е да предотвратите скрипт-киди да свали вашия сървър, само защото имате скъпа крайна точка на API, изложена от вашия сървър, без да има ограничение на скоростта.

Ако използвате Express с Node, има 2 красиви пакета, които работят безпроблемно, за да определят лимита на трафика на слой 7:

  1. Express Limit Limit - //www.npmjs.com/package/express-rate-limit
  2. Експресно забавяне - //www.npmjs.com/package/express-slow-down

Express Slow Down всъщност добавя постепенно забавяне към вашите заявки, вместо да ги пусне. По този начин легитимни потребители, ако те DDoS случайно (супер активност на щракване бутони тук и там), просто се забавят и не са ограничени.

От друга страна, ако има скрипт-киди, който изпълнява скриптове за сваляне на сървъра, Express limiter наблюдава и ограничава скоростта на този конкретен потребител, в зависимост от потребителския IP, потребителския акаунт или каквото и да е друго, което искате.

Ограничаването на скоростта би могло (трябва!) Да се ​​приложи и на слой 4 (слой 4 означава блокиране на трафика преди откриване на съдържанието му - HTTP) чрез IP адрес. Ако искате, можете да настроите правило NGiNX, което блокира трафика на слой 4 и отхвърля потока от трафик, идващ от един IP, като по този начин спасявате сървърните процеси от преобладаване.

Използвайте интерфейсен сървър за SSL прекратяване

Node предоставя готовата поддръжка за SSL ръкостискания с браузъра, използвайки httpsсървърния модул, комбиниран с необходимите SSL сертификати.

Но нека бъдем честни тук, вашето приложение така или иначе не трябва да се занимава със SSL. Това не е нещо, което логиката на приложението трябва да прави. Вашият Node код трябва да носи отговорност само за това, което се случва със заявката, а не за предварителната обработка и последващата обработка на данните, влизащи и излизащи от вашия сървър.

Прекратяването на SSL се отнася до преобразуване на трафик от HTTPS към HTTP. И за това има много по-добри инструменти от Node. Препоръчвам NGiNX или HAProxy за него. И двете разполагат с безплатни версии, които свършват работата и разтоварват прекратяването на SSL от Node.

Използвайте преден сървър за статично обслужване на файлове

Отново, вместо да използвате вградени методи като express.staticобслужване на статични файлове, използвайте челни обратни прокси сървъри като NGiNX, за да обслужвате статични файлове от диск.

На първо място, NGiNX може да направи това по-бързо от Node (защото е изграден от нулата, за да прави само това). Но също така разтоварва файл, обслужващ от еднонишковия Node процес, който може да използва своите тактови цикли за нещо по-добро.

Не само това - интерфейсните прокси сървъри като NGiNX също могат да ви помогнат да доставяте съдържание по-бързо, използвайки GZIP компресия. Можете също така да зададете заглавки за изтичане на срока на действие, кеш данни и много други, което не е нещо, което трябва да очакваме от Node да прави (но Node все още може да го направи).

Конфигурирайте обработката на грешки

Правилното обработване на грешки може да ви спести от часове за отстраняване на грешки и опит за възпроизвеждане на трудни грешки. На сървъра е особено лесно да настроите архитектура за обработка на грешки, защото вие сте тази, която я изпълнява. Препоръчвам инструменти като Sentry with Node, които ви записват, отчитат и изпращат имейли, когато сървърът се срине поради грешка в изходния код.

След като това е на място, сега е време да рестартирате сървъра, когато се срине, така че целият сайт не просто да падне с часове, докато не го вземете отново ръчно.

За това можете да използвате диспечер на процеси като PM2. Или дори по-добре, използвайте докерзирана среда на контейнер с политики като restart: alwaysправилна настройка на ограниченията на паметта и диска.

Настройката на Docker гарантира, че дори ако вашият контейнер работи в OME, процесът се завърта отново (което може да не се случи в среда PM2, тъй като операционната система може да убие PM2, ако има изтичане на памет някъде в работещ процес).

Конфигурирайте правилно регистрационните файлове

Всички отговори са в дневници. Хакове на сървъри, сривове на сървъри, подозрително поведение на потребителя и т.н. За това трябва да се уверите, че:

  1. Всеки опит за заявка се регистрира с достъп до IP адреса / метода на заявката / пътя, основно толкова информация, колкото можете да регистрирате (с изключение на лична информация като пароли и информация за кредитна карта, разбира се)
  2. Това може да се постигне чрез пакета morgan
  3. Инсталирайте регистрационни файлове на файлови потоци в продукция, вместо на конзола Това е по-бързо, по-лесно да се види и ви позволява да експортирате регистрационни файлове в онлайн услуги за преглед на дневници.
  4. Не всички регистрационни съобщения имат еднакво тегло. Някои регистрационни файлове са само там за отстраняване на грешки, докато ако някои от тях са налице, това може да показва ситуация на панталони (като хакер на сървъра или неоторизиран достъп). Използвайте winston-logger за регистриране на различни нива на регистрационни файлове.
  5. Настройте ротация на регистрационния файл, така че да не получите размер на регистрационния файл в GB след около месец, когато видите сървъра.
  6. GZIP вашите регистрационни файлове след завъртане. Текстът е евтин и е силно сгъстим и лесен за съхранение. Никога не трябва да се сблъсквате с проблеми с текстовите дневници, стига да са компресирани и използвате сървър с прилично дисково пространство (25GB +).

Заключение

Лесно е да се отбележат няколко практики в производството, които могат да ви спестят сълзи и часове на отстраняване на грешки по-късно. Уверете се, че спазвате тези най-добри практики и ми кажете какво мислите, като кажете „Здравейте“ на ръкохватката ми в Twitter.

Ако тази статия ви е харесала, нека се запознаем в социалните медии. Ето моите Instagram и Twitter. Супер активен съм и бих се радвал да си поговорим! Да се ​​свържем.

Мир!

Мехул