Лекція 201: Введення в Event-Driven Architecture (EDA)

Уяви, що ти на театральній виставі. Актор на сцені експресивно читає монолог, а зал реагує аплодисментами — це й є події в дії. Те, що ми називаємо подіями, — це ключові моменти, які "перевертають" стан системи.

У випадку з Event-Driven Architecture додатки проектують так, щоб реагувати на події, а не зациклюватись у тісному циклі запитів-відповідей. Це архітектура, де події виступають у ролі тригерів для виконання дій або зміни станів у системі.

Відмінності від традиційної архітектури

Традиційна архітектура, наприклад REST API, — це як телефонний дзвінок: клієнт дзвонить серверу, сервер відповідає. Але що якщо сервер зайнятий? Прийдеться чекати. В EDA цей процес асинхронний: клієнт "кричить" свою прохання в загальний мікрофон (топік Kafka), і хтось обов'язково це почує.

Можна виділити кілька ключових відмінностей EDA:

• Асинхронність: події створюються й обробляються незалежно одна від одної.
• Слабка зв'язаність: компоненти не залежать від прямого виклику один одного.
• Реактивність: кожен компонент реагує на вхідні події.

Основні компоненти EDA

EDA базується на трьох основних компонентах:

1. Події (Events): це ключові зміни або важливі дії в системі. Наприклад, "користувач зареєструвався" або "платіж підтверджено".
2. Видавці (Producers): компоненти, які ініціюють події. У нашому додатку це може бути мікросервіс обробки замовлень, який створює подію "нове замовлення".
3. Підписники (Subscribers): компоненти, які слухають події й реагують на них. Наприклад, мікросервіс сповіщень, який відправляє e-mail "Дякуємо за ваше замовлення!".

Потік подій

Коли говорять про потік подій, його можна уявити як метафоричний водоспад. Вся система "слухає" цей потік і обробляє "краплі" (події) по мірі їх надходження. Для управління цим використовується брокер повідомлень — посередник між видавцями і підписниками. Таким брокером може виступати Apache Kafka.

Переваги Event-Driven Architecture

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

У традиційній архітектурі кожна система має постійно питати у інших: "Що у вас змінилось?". Це те саме, що кожну хвилину перевіряти, чи не пора вмикати світло або опалення. А в подієвій архітектурі системи просто реагують на те, що відбувається, щойно отримають сигнал.

Хочеш додати нову систему, наприклад автоматичні штори? Просто підключи їх до загальної мережі датчиків, і вони одразу почнуть реагувати на події освітленості або часу доби. Ось тобі й масштабованість системи (scalability) — нові компоненти легко додаються, не вимагаючи переналаштування інших.

Якщо якась система виходить з ладу, наприклад перестають працювати автоматичні штори, решта дому продовжує функціонувати. Коли їх полагодять, вони автоматично синхронізуються з поточним станом дому — це відмовостійкість (fault tolerance). При цьому кожну систему можна оновлювати незалежно: заміна датчиків руху ніяк не вплине на роботу клімат-контролю (loose coupling, тобто слабка зв'язаність компонентів).

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

особливо привабливою для сучасних систем.

Приклади використання EDA

EDA стає невід'ємною частиною багатьох сучасних систем. Ось кілька реальних прикладів:

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

Як працює потік подій

Ось приклад, щоб закріпити розуміння. Припустимо, наш магазин обробляє замовлення. Це приблизна взаємодія:

1. Покупець оформляє нове замовлення.
2. Мікросервіс замовлень публікує подію OrderCreated у топік Kafka.
3. Підписники беруть цю подію:
   • "Мікросервіс доставки" планує доставку.
   • "Мікросервіс сповіщень" відправляє e-mail клієнту з підтвердженням.
   • "Мікросервіс складу" оновлює кількість на складі.

Apache Kafka як брокер повідомлень

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

Реальні кейси

• Компанія Amazon широко використовує EDA, щоб обробка замовлень і оновлення інформації про товари відбувались миттєво. Наприклад, коли покупець додає товар у корзину, подія відправляється в брокер повідомлень, і інформацію одразу бачать інші сервіси.
• Netflix використовує EDA для керування рекомендаціями. Твій вибір наступного фільму стає подією, яка ініціює оновлення персоналізованих рекомендацій.

Як ми будемо застосовувати EDA

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

Практична схема EDA

Приклад подій:

• UserRegistered: коли користувач реєструється в системі.
• OrderPlaced: коли зроблено нове замовлення.
• PaymentProcessed: коли платіж успішно виконано.

Приклад проектування:

1. Створення подій: визначаємо структуру даних, які несе подія.
2. Публікація події: сертифікат, який створює подію.
3. Обробка події: сервіс, який "слухає" подію і виконує дію (наприклад, відправку e-mail).

Приклад структури події JSON:

{
   "eventId": "12345",
   "eventType": "OrderCreated",
   "createdAt": "2023-10-01T12:00:00Z",
   "data": {
      "orderId": "54321",
      "customerId": "98765",
      "orderAmount": 250.00
   }
}

Наступні кроки

Тепер, коли ти познайомився з основами подієво-орієнтованої архітектури, ми зможемо заглибитися в принципи асинхронної комунікації й почати проєктування наших перших подій. Готуйся, попереду багато цікавого!