NodeJS: Кращі практики для виробництва

Це спроба зарахувати найважливіші практики розробки та розгортання в NodeJs.

Я певний час працював над цією технологією. Я усвідомлюю його величезний потенціал і місце в процесі розвитку. Завдяки жорсткій конкуренції з таких мов, як Python та Golang, NodeJS довів свою корисність у відповідних випадках використання.

Перш ніж поглибитися у кращі практики , я хотів би коротко ознайомитись із тим, що таке мікросервіс. Тоді ведіть розмову далі звідти.

Отже, що таке мікросервіси?

Мікросервіси - також відомі як архітектура мікросервісів - це архітектурний стиль, який структурує додаток як сукупність служб, які:

  • Високорентабельний і перевірений
  • Нещільно з'єднані
  • Незалежно розгортається
  • Організовано навколо можливостей бізнесу.

Архітектура мікросервісу забезпечує безперервну доставку / розгортання великих, складних додатків. Це також дозволяє організації розвивати свій набір технологій.

Як вирішити, чи потрібні мікросервіси

Спочатку, коли ви тільки починаєте працювати над своїм MVP, можливо, вам не знадобиться використовувати мікросервіси. Масштабування осі Y може бути не вашим порядку денним. Але коли продукт починає дозрівати і іноді занадто рано, коли вам доводиться мати справу зі масштабуванням, розкладання на функціональні модулі має більше сенсу, оскільки сам бізнес розкладається. Це буде правильним моментом, щоб почати вивчати схему архітектури мікросервісів.

Книга, яку я дуже рекомендую, - Кріс Річардсон тут: http://bit.ly/2EmJDYt.

Мікросервіси найчастіше розглядаються під час заміни монолітного додатку, який раніше був досить поширеним, коли рішення щодо контейнерної розробки, як Docker, почали керувати світом DevOps. Але про це пізніше.

Було б несправедливо, якби я продовжував, не згадуючи дизайн, керований доменом (DDD). Це дуже популярна стратегія розкладання продукту на функціональні модулі. Тому дуже корисно створювати мікросервіси.

Отже, що таке домен відповідно до DDD?

Кожна проблема, яку ви намагаєтеся вирішити, - це домен.

Кожен домен підрозділяється на взаємовиключні обмежені контексти. Ці контексти - це не що інше, як окремі сфери конкретної проблеми.

У шаблоні мікросервісів кожен обмежений контекст співвідноситься з мікропослугою. Шаблони DDD допомагають зрозуміти складність у домені. Для моделі домену для кожного обмеженого контексту ви визначаєте та визначаєте
сутності, цінні об'єкти та агрегати, що моделюють ваш домен.

Залежно від складності вашого програмного забезпечення ви можете вибрати принципи DDD або виконати більш простий підхід.

Метою є досягнення високо згуртованої та слабко поєднаної доменної моделі. Для цього дотримуйтесь такого підходу:

Це було коротке вступ до DDD. Щоб дізнатися більше про це, я настійно рекомендую прочитати чудову книгу Еріка Еванса http://bit.ly/2Eoy17l.

Жити далі.

Сподіваюся, ви тримаєтесь зі мною.

Тож звідси я розповім докладніше про практику, характерну для NodeJS. Я маю на увазі те, що мікросервіси та DDD все-таки допомагають вам орієнтуватися на справжній потенціал NodeJS. Це само по собі. Як? Побачимо.

Який шаблон дизайну використовувати під час використання NodeJs

Шаблони дизайну - це розробка програмного забезпечення з використанням певних стандартів, відомих багатьом розробникам.

Ми можемо використовувати різні шаблони дизайну. Я хотів би представити та / або резюмувати розробникам, які вже знають про шаблон, який називається Шаблон сховища.

Ця закономірність полегшує розділення логіки MVC, а також полегшує обробку визначення моделі та взаємодії моделі з іншою логікою.

Він складається з:

  1. Контролер: Він обробляє лише запит та відповідь та пов'язані з ними атрибути. Він також не матиме жодної бізнес-логіки, визначення моделі чи асоціацій моделей. (назва папки: контролери)
  2. Сервіс: Він містить логіку бізнесу для вашої мікросервісу. Управління переходить від контролера до служби. Це відносини 1: 1 між контролером та його службою та 1: безліч відносин між службою та сховищами. (назва папки: служби)
  3. Репозиторій: Він взаємодіє з моделями, що входять до папки моделі. Будь-який запит до бази даних через шар моделі буде сформований тут. Він не матиме жодної логіки бізнесу. (назва папки: сховища)
  4. Модель: вона містить визначення моделі, асоціації, віртуальні функції (наприклад, у мангуста)
  5. Утиліти: Це буде містити допоміжні класи / функції, які можна використовувати як сервіси. Наприклад: утиліта Redis, яка має всі функції, необхідні для взаємодії з Redis. (назва папки: утиліти)
  6. Тестовий випадок: Це включає в себе тестові випадки одиниць проти методів контролера, щоб забезпечити максимальне покриття коду. (назва папки: spec)

Щоб дізнатись більше про це, ви можете звернутися за цим посиланням: http://bit.ly/2TrSyRS

Гаразд, розкажіть про кластерні модулі

Один екземпляр Node.js працює в одному потоці. Щоб скористатись багатоядерними системами, користувач іноді захоче запустити кластер Node.js процесів для обробки навантаження.

Модуль кластера дозволяє легко створювати дочірні процеси, якими користуються всі порти сервера.

Зауважте, що для розгортання через мікросервіси ідеально використовувати один процес на контейнер під час використання контейнерів Docker. Отже, кластерні модулі не корисні при використанні докер-ізації.

Як керувати потоком управління в NodeJS

Під час використання зворотних дзвінків або обіцянок наступні бібліотеки можуть бути корисними:

  1. Async (https://www.npmjs.com/package/async)
  2. Vasync (з кращим відстеженням роботи) https://www.npmjs.com/package/vasync
  3. Bluebird (виконайте обіцянки, наприклад, Promise.all тощо) https://www.npmjs.com/package/bluebird

А петлі?

  • Серія циклу: виконання кожного кроку по одному за порядком
  • Затримка циклу: петля з таймаутом
  • Паралельний цикл: збирання всіх обіцянок у циклі та виконання паралельно

А які корисні інструменти для підв’язки?

Інструменти для підключення аналізують ваш код статично (не запускаючи його). Вони визначають потенційних помилок або небезпечних моделей. Такі шаблони, як використання незадекларованих змінних або випадок "case" всередині комутатора без оператора "break".

Увімкнення суворого режиму на вашій кодовій базі з використанням "строгого використання" може допомогти вашому коду швидко вийти з ладу, якщо аналізатор JavaScript може виявити витік глобальної чи подібної поганої поведінки.

Прикладами лінерів є lint Javascript та JS lint.

Гаразд, як ми обробляємо журнал?

Деякі часто використовувані пакети npm:

  • Вінстон (https://www.npmjs.com/package/winston)
  • Бунян (https://www.npmjs.com/package/bunyan)

Можливий формат журналу:

Для розподілених систем, таких як мікросервіси, ви хочете вивчити розподілене трасування за допомогою ZipKin тощо.

Примітка щодо NPM-пакетів: Ви повинні використовувати пакет лише в тому випадку, якщо він вирішує проблему для вас, яку ви не можете вирішити самостійно. Регулярно виконайте аудит npm, щоб знайти критичні проблеми з вашими npm-залежностями.

Поводження з невиконаними винятками

За замовчуванням Node.js обробляє такі винятки, друкуючи слід стека в stderr та виходячи з кодом 1, переосмислюючи будь-який раніше встановлений process.exitCode

Примітка. Додавання обробника для події "uncaughtException" перекриває цю поведінку за замовчуванням.

Крім того, змініть process.exitCode в обробнику 'uncaughtException', що призведе до того, що процес вийде з наданого коду виходу. В іншому випадку, за наявності такого обробника, процес вийде з 0.

process.exit (0) - успішне припинення
process.exit (1) - невдале припинення

Поводження з необробленими відхиленнями

Обіцяння є всюдисущими в коді Node.js і іноді прикуті до дуже довгого переліку функцій, які повертають обіцянки тощо.

Якщо не використовувати належного обробника відхилення .catch (...), це призведе до викиду події без оброблення. Якщо вас не впіймають і не перевіряють належним чином, ви можете позбавити себе єдиного шансу виявити та, можливо, виправити проблему.

Додатковий рада:

console.time () та console.timeEnd ()

Об'єкт консолі має методи time () та timeEnd (), які допомагають аналізувати ефективність фрагментів вашого коду.

Це не рішення для виробництва, але його можна використовувати, коли у вас немає кращих інструментів.

Дуже дякую за ваш час.
Підпишіться на мій інформаційний бюлетень

Інші чудові статті з подібних тем:

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