В основі подієвої архітектури лежить одна з найбільш популярних підходів у сучасному світі програмного забезпечення. Однак під час використання цієї потужної архітектури є деякі «красиві» помилки, які, з одного боку, можуть перетворити вашу систему на хаос, а з іншого — зробити життя вашої команди програмістів справжньою комедією помилок.
Ось найкращі помилки, які можна зробити в подієвій архітектурі:
1- Надмірне використання Event'ів: «Усе — Event, скрізь — Event»
Подієва архітектура — це підхід, який орієнтований на події. Однак моделювання кожної операції як події може призвести до зайвої складності. Створення події для кожної маленької зміни в системі може спричинити неконтрольований ріст кількості подій і ускладнити розуміння системи.
Ключовим моментом є правильне визначення, які операції справді потребують асинхронного підходу.
Надмірне використання event'ів може знизити продуктивність і надмірно ускладнити архітектуру системи.
2- Надмірне збільшення розміру Event'ів: «Що ж тут тільки немає!»
Події — це пакети даних, що представляють певну подію. Однак додавання зайвої інформації до події може негативно вплинути на продуктивність і спричинити непотрібні трансфери даних.
Наприклад, під час створення події замовлення, достатньо лише ID замовлення та ID клієнта, а додавання всіх деталей замовлення і даних клієнта буде зайвим. Необхідну додаткову інформацію можна отримати пізніше за допомогою ID замовлення від відповідних сервісів.
Великі події збільшують мережевий трафік, подовжують час обробки та створюють непотрібне навантаження на систему. Тому вміст події має бути якомога коротшим і відповідним.
3- Не використовувати Dead Letter Queue (DLQ): «Насправді, все добре!»
Dead Letter Queue (DLQ) — це черга, в яку потрапляють події, що не можуть бути оброблені. Коли подія не може бути оброблена (наприклад, через помилку або тимчасову недоступність сервісу), вона потрапляє в DLQ.
Не використання DLQ може призвести до втрати помилкових подій та неузгодженості даних у системі.
Завдяки DLQ проблемні події можна знову проаналізувати, виправити та повторно обробити. Це підвищує надійність системи та цілісність даних. DLQ також допомагає виявляти та аналізувати помилки в системі.
4- Не логувати Event'и: «Чи справді ця подія відбулась?»
Не логування подій ускладнює відслідковування подій у системі і ускладнює процес відлагодження помилок.
Логи показують, які події сталися, коли, які сервіси їх обробляли та чи виникли помилки.
Завдяки логам можна легше визначити причини проблем у системі та вирішити їх. Логи також використовуються для аналізу поведінки системи і покращення її продуктивності. Ефективна стратегія логування значно підвищує відслідковуваність і керованість системи.
5- Використовувати один Topic для всіх Event'ів: «Давайте створимо Event-метро!»
У подієвій архітектурі події публікуються через логічні канали, звані "topic". Використання одного topic для всіх подій може погіршити масштабованість і продуктивність системи.
Різні типи подій, які публікуються через один і той самий topic, можуть призвести до зайвих фільтраційних операцій і зниження продуктивності.
Наприклад, використання окремого topic для подій замовлення та окремого topic для подій реєстрації користувачів дозволяє системі працювати більш ефективно.
Використання різних topic дозволяє краще організувати події та дає змогу відповідним сервісам обробляти тільки ті події, які їм потрібні.
Це, в свою чергу, підвищує загальну продуктивність і масштабованість системи.
Перекладено з: Event Bazlı Mimaride Yapılabilecek En Güzel Hatalar