Подієва архітектура NestJS: проєктування з урахуванням збоїв, повторної обробки та змін

Подієва архітектура дає одній частині системи змогу зафіксувати факт, а іншим — відреагувати у зручний для них час. Таке розділення допомагає приймати раптові сплески навантаження, відокремлювати тимчасові збої залежностей, підключати кількох незалежних споживачів і зберігати послідовність фактів для подальшої обробки. Водночас замість видимого ланцюжка викликів з’являються контракти, черги, відставання, повторна доставка, частково завершені процеси, повторна обробка й окрема експлуатаційна відповідальність.

NestJS пропонує корисні засоби обміну повідомленнями та з’єднання з різними механізмами передавання, але жоден декоратор не обере належних гарантій доставки й не зробить розподілений процес правильним. Почніть зі шляху користувача або бізнесу: що має стати правдою до повідомлення про успіх, які наслідки можуть настати пізніше, яка затримка припустима, що можна безпечно повторити, як звіряти стан і хто діятиме, коли процес зупиниться. Додавайте події лише тоді, коли відповіді виправдовують появу складнішої системи.

Застосовуйте події лише там, де роз’єднання в часі дає користь

Подія предметної області — це сформульований у минулому часі бізнес-факт, яким володіє область, де він виник: OrderAccepted, PaymentCaptured або AccountSuspended. Подія описує те, що вже сталося, а не наказує невідомому споживачеві виконати дію. Команда виражає намір і зазвичай має одного відповідального виконавця. Інтеграційна подія переносить лише відібрані факти через межу системи та може відрізнятися від внутрішнього об’єкта, щоб не розкривати будову системи й чутливі дані.

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

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

Свідомо обирайте між синхронним викликом, командою та подією

Використовуйте синхронний API, коли стороні, що викликає, потрібна негайна й достовірна відповідь і вона здатна прийняти затримку та доступність залежної служби. У такій взаємодії успіх, відмова, перевірка прав і завершення часу очікування видимі одразу. Асинхронна команда доречна, коли роботу можна прийняти зараз, а завершити пізніше одним відповідальним виконавцем. Подію публікують після того, як джерело незворотно зафіксувало факт, на який зацікавлені споживачі можуть реагувати незалежно.

Не маскуйте обмін «запит-відповідь» під повідомлення. Такий спосіб роботи NestJS через брокер усе одно пов’язує сторону, що викликає, з відповіддю, граничним часом очікування, ідентифікатором зв’язку та доступністю виконавця, водночас додаючи поведінку брокера. У контрольованих умовах це може бути доречно, але варіант слід порівняти з HTTP або gRPC за затримкою, зручністю пошуку помилок, обмеженням навантаження, скасуванням, сумісністю та складністю експлуатації. Публікація події з подальшим опитуванням до завершення всіх наслідків так само створює розподілену транзакцію, лише не називає її своїм ім’ям.

Будуйте обіцянку користувачеві навколо справжнього поступу. API може повернути завершений результат, відхилити запит або прийняти його разом зі стійким ідентифікатором операції та ресурсом, де видно стан. Назвіть проміжні й кінцеві стани, строк дії, скасування, відшкодувальні дії, повідомлення та порядок підтримки. Не повідомляйте про успіх лише тому, що повідомлення потрапило до брокера: прийнято, доставлено, оброблено і завершено для бізнесу — це різні факти.

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

Добирайте Kafka, RabbitMQ або Amazon SQS за характером навантаження

Kafka — розподілений журнал лише для дописування, придатний для довговічних потоків подій, високої пропускної здатності, кількох груп споживачів, тривалого зберігання й повторної обробки. Порядок гарантовано лише в межах одного розділу, тому ключ події та кількість розділів є рішеннями для бізнесу, а не тільки налаштуваннями. Відставання споживачів, перерозподіл розділів, строк зберігання, ущільнення журналу, розвиток схем, копіювання даних і робота кластера мають бути частиною проєкту. Kafka не завжди є найпростішою чергою завдань.

RabbitMQ зручний для гнучкого спрямування та черг завдань, де точки обміну, прив’язки, підтвердження обробки, підтвердження публікації, попереднє отримання і різні види черг дають потрібний контроль. Підтвердження публікації та підтвердження обробки споживачем стосуються різних відрізків доставки; застосунок усе одно має вирішити, коли результат уже достатньо надійний для підтвердження. Повторна доставка після втрати з’єднання означає, що споживач повинен чекати дублікатів. Необмежене повернення до черги здатне створити нескінченний гарячий цикл.

Amazon SQS надає керовану чергу з невеликим обсягом експлуатаційної роботи в AWS. Стандартні черги орієнтовані на пропускну здатність і доставку щонайменше один раз; черги FIFO мають інші правила порядку й усунення дублікатів, обмеження яких слід звірити з навантаженням. Термін невидимості, тривале опитування, затримка, зберігання, повторне спрямування з карантину, права доступу, шифрування, квоти, розмір повідомлення та кількість одночасних споживачів залишаються турботою застосунку навіть за керованих серверів.

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

Залишайте код передавання NestJS на межі системи

Не пов’язуйте поведінку предметної області з конкретним механізмом передавання NestJS. Тонкий контролер або обробник повідомлення має перевірити оболонку події, установити особу й відомості для трасування, перетворити помилки передавання, викликати прикладний сценарій і підтвердити повідомлення відповідно до результату. Код предметної області не повинен залежати від позицій у Kafka, позначок доставки RabbitMQ або квитанцій Amazon SQS. Так надійність кожного механізму залишається явною, а інфраструктурні поняття не розповзаються всією моделлю.

Визначте оболонку події з ідентифікатором, типом, версією схеми, часом виникнення, джерелом, об’єктом предметної області або бізнес-ключем, ідентифікаторами зв’язку та причини, клієнтом за потреби й корисними даними. Не копіюйте до кожного повідомлення ключі доступу, необмежені особисті дані або змінні внутрішні об’єкти. Перевіряйте джерела, керуйте правами на публікацію і споживання, шифруйте передавання та зберігання, обмежуйте керування темами й чергами, реєструйте привілейовану повторну обробку та встановлюйте строки зберігання і видалення регульованих даних.

Конвеєри перетворення, перевірки доступу, перехоплювачі, фільтри, впровадження залежностей і модулі NestJS залишаються корисними, але кожен механізм передавання має власні правила підтвердження, повторних спроб, перетворення даних, групування, розподілу та завершення роботи. Сховайте ці відмінності в адаптерах і перевіряйте їх зі справжнім брокером. Спільний тип TypeScript не захищає незалежно випущені служби під час виконання: перевіряйте схеми, публікуйте правила сумісності й випробовуйте контракти між джерелом і споживачем. Додатково прочитайте посібник із визначення архітектурних меж.

Проєктуйте публікацію, ідемпотентність і повторні спроби разом

Проблема подвійного запису виникає, коли служба окремо зберігає стан предметної області й публікує подію: вона може записати замовлення, але не надіслати подію, або надіслати її до скасування транзакції. Транзакційна таблиця вихідних подій зберігає зміну стану й майбутню подію в одній транзакції бази даних. Окремий процес згодом публікує запис і позначає поступ. Він може опублікувати подію більше одного разу, тому цей спосіб усуває втрату між зміною стану та публікацією, але все одно потребує ідемпотентних споживачів.

Надайте кожній події сталий ідентифікатор, а кожній побічній дії — межу ідемпотентності. Споживач може записати оброблений ідентифікатор у тій самій транзакції, що й зміну стану, вимагати унікальності бізнес-ключа, скористатися ідемпотентним запитом постачальника або порівняти очікуваний стан і версію. Строк зберігання даних для усунення дублікатів має охоплювати найдовший можливий період повторної доставки та обробки. Перевірка в пам’яті перед записом не забезпечує ідемпотентності: два примірники можуть змагатися, а збій — статися між дією та її фіксацією.

Перед повторною спробою визначте вид помилки. Тимчасова втрата мережі, обмеження частоти або недоступна залежність можуть виправдовувати дедалі довшу затримку з випадковим відхиленням і верхньою межею. Хибна схема, заборонена дія, порушена незмінна умова або непідтримувана версія потребують карантину чи втручання людини. Обмежуйте кількість спроб і загальний вік роботи; зберігайте причину помилки без розкриття таємниць. Буря повторних спроб здатна посилити збій, вичерпати з’єднання й змінити порядок роботи, тому обмежуйте одночасність і вхідне навантаження, за потреби автоматично припиняйте виклики до несправної залежності та відновлюйтеся з урахуванням її стану.

Підтверджуйте повідомлення лише після стійкої побічної дії або запису про ідемпотентність, яких вимагає домовленість із бізнесом. Перевіряйте збої до і після кожної межі: фіксації транзакції бази даних, вибірки вихідної події, підтвердження брокером, дії споживача, підтвердження повідомлення та відповіді зовнішньої служби. Для поєднання таких процесів з API перегляньте посібник зі шлюзу NestJS, де розглянуто суміжні питання запитів і спрямування.

Керуйте карантином і повторною обробкою як контрольованими операціями

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

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

Строк зберігання також визначає можливості відновлення. Журнал Kafka може дати змогу наново побудувати похідне подання, тоді як черга завдань може видалити підтверджені повідомлення. Зберігайте первинні дані, визначення схем, версії перетворень, точки продовження повторної обробки та порядок звіряння відповідно до потреб відновлення. Перевіряйте повну перебудову похідних даних і спорожнення накопиченої черги під навантаженням. Посібник із фонових завдань пояснює процеси, для яких звичайна черга завдань є прямішою моделлю.

Стежте за перебігом бізнес-процесу, а не лише за станом брокера

Простежуйте одну бізнес-операцію через API, транзакцію бази даних, таблицю вихідних подій, джерело, брокер, споживача, подальший API та кінцевий стан за допомогою ідентифікаторів зв’язку й причини. Зберігайте як структуровані поля ідентифікатор події, тип, версію, бізнес-ключ, джерело, споживача, номер спроби, часові позначки, розділ або чергу та результат. Передавайте відомості для трасування, де це підтримується, але не покладайтеся на вибірково записані траси як на єдиний доказ для перевірки чи звіряння.

Вимірюйте затримку публікації, прийняття брокером, відставання споживача або вік черги, пропускну здатність, повторну доставку, вік повторних спроб, повідомлення в карантині, час обробки, причини помилок, вичерпання ресурсів і час до завершення для бізнесу. Додайте показники предметної області: замовлення, що очікують оплати; прострочені повідомлення; неузгоджені між системами записи; операції, які треба виправити. Справний брокер може переносити дедалі більшу чергу роботи, результату якої не отримує жоден клієнт.

Серед типових помилок робочих систем — події до фіксації транзакції, дані без версій, змінні пакети на кшталт «об’єкт змінено», припущення про загальний порядок, необмежені повторні спроби, передчасні підтвердження, неідемпотентні зовнішні виклики, одна спільна черга для непов’язаних ризиків, відсутність обмеження вхідного навантаження, мовчазна зупинка споживача, ручна повторна обробка без запису та панелі без показника віку. Окремо призначте відповідальних за джерело, контракт, брокер, споживача й бізнес-процес, щоб кожен збій мав визначений шлях рішення.

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

Як безпечно впровадити подієву архітектуру в NestJS

Зовнішній огляд корисний, коли доставка подій проходить через кілька команд, баз даних, хмарних служб або постачальників; після аварій стан бізнесу залишається невизначеним; обговорюється зміна брокера; або ніхто не відповідає за повторну обробку й звіряння. Під час оцінювання слід скласти схему бізнес-процесів, гарантій, контрактів, транзакцій, брокерів, споживачів, класів даних, історії збоїв, діагностичних відомостей, місткості та експлуатаційних повноважень.

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

• Доведіть користь асинхронної межі: назвіть бізнес-факт, відповідального, припустиму затримку, джерело достовірного стану, часткові стани, спосіб звіряння, наслідки збою та вимірювану користь роз’єднання.
• Оберіть вид взаємодії: застосовуйте синхронні виклики для негайних відповідей, асинхронні команди — для відкладеної роботи одного відповідального, а події — для зафіксованих фактів із незалежними споживачами.
• Добирайте брокер за властивостями роботи: порівняйте межі порядку, розгалуження доставки, зберігання, повторну обробку, спрямування, пропускну здатність, затримку, поділ клієнтів, безпеку, досвід команди, обмеження й вартість експлуатації.
• Захистіть межу транзакції: використовуйте транзакційну таблицю вихідних подій або іншу доведену гарантію публікації, надавайте контрактам версії, перевіряйте їх і не впускайте подробиці передавання до поведінки предметної області.
• Передбачте повторення роботи: зробіть споживачів і зовнішні дії ідемпотентними, розрізняйте види помилок, обмежуйте кількість і вік повторних спроб, стримуйте вхідне навантаження та підтверджуйте повідомлення лише після стійкого успіху.
• Керуйте відновленням: призначте відповідального за розбір карантину, дозволяйте лише обмежену повторну обробку, зберігайте докази для перевірки й звіряння, вимірюйте вік і завершення бізнес-процесів та відпрацьовуйте спорожнення накопиченої черги.