Архітектура, керована подіями (EDA) — це шаблон проектування програмного забезпечення, який надає структуру для проектування та впровадження програм або систем, які реагують на зміни в середовищі. Ця реактивна поведінка зазвичай охоплює події отримання, обробки та відправлення, що дозволяє компонентам системи функціонувати відокремлено, таким чином підвищуючи масштабованість і адаптивність.
Генезис архітектури, керованої подіями
Програмування, кероване подіями, бере свій початок із перших днів графічних інтерфейсів користувача (GUI) і бере свій початок у кінці 1960-х та на початку 1970-х років. Патерн проектування виник як природне рішення для керування діями, ініційованими користувачем, такими як натискання кнопок або клавіш, які за своєю суттю є непередбачуваними та асинхронними. У цьому контексті виникла ідея програмування, керованого подіями, для роботи з потоком програми, який визначається діями користувача, подіями, створеними системою, або повідомленнями від інших програм.
Зростання розподілених систем і сервісів наприкінці 1990-х і в 2000-х роках викликало потребу в складніших архітектурах, керованих подіями, для обробки зростаючої складності взаємодій, що зрештою призвело до створення систем, які могли б реагувати як на внутрішні, так і на зовнішні події.
Представлена архітектура, керована подіями
Архітектура, керована подіями (EDA) — це архітектурна парадигма програмного забезпечення, яка зосереджена на виробництві, виявленні, споживанні та реакції на події. Ці події позначають зміну стану, спричинену дією користувача, наприклад клацанням миші чи натисканням клавіші, або дією системи, як-от отримання повідомлення від іншої системи.
У EDA компоненти системи взаємодіють один з одним, створюючи та споживаючи події, де подія визначається як значна зміна стану. Ці компоненти функціонують у відокремлений спосіб, що дозволяє системам бути більш гнучкими, масштабованими та адаптованими до мінливих вимог або умов середовища.
Структура та функціонування архітектури, керованої подіями
Внутрішня структура архітектури, керованої подіями, складається з чотирьох основних компонентів:
- Продюсери події: Компоненти, які створюють події та публікують їх у каналі подій.
- Канал події: Канал поширення подій.
- Споживачі подій: Компоненти, які підписуються на канал подій для споживання подій.
- Процесори подій: Компоненти, які реагують на події, зазвичай виконуючи певну дію.
Процес EDA складається з таких кроків:
- Виробник подій виявляє зміну стану та створює подію.
- Подія опублікована на Event Channel.
- Споживачі подій, які підписані на канал подій, споживають подію.
- Процесори подій обробляють подію та, можливо, ініціюють інші дії.
Цей процес забезпечує асинхронне та слабке зв’язування служб у реальному часі, що сприяє швидкому реагуванню, масштабованості та стійкості системи.
Ключові особливості архітектури, керованої подіями
EDA демонструє кілька відмінних характеристик:
- Асинхронність: Виробникам і споживачам подій не потрібно взаємодіяти чи навіть бути активними одночасно.
- Роз'єднання: Виробники та споживачі подій не пов’язані безпосередньо, що сприяє незалежності та ізоляції.
- Відповідь у реальному часі: EDA дозволяє системам негайно реагувати на інформацію в реальному часі.
- Масштабованість: Завдяки своїй асинхронній та відокремленій природі, EDA може легко масштабуватися для більшої кількості виробників, споживачів або подій.
- Стійкість: Збій в одній частині системи не обов’язково порушує всю систему.
Типи керованої подією архітектури
Існує кілька типів керованих подіями архітектур, які відрізняються головним чином способом обробки подій:
- Сповіщення про подію: Найпростіший тип EDA, у якому виробник події просто надсилає сповіщення про те, що подія сталася, але жодних дій явно не вимагається.
- Передача стану на основі події: Подія несе зміну стану в корисному навантаженні, яку споживачі можуть використовувати для оновлення власного стану.
- Джерело події: Усі зміни стану програми зберігаються як послідовність подій. Потім ці події можна запитувати, або стан можна відновити шляхом повторного відтворення подій.
- CQRS (розподіл відповідальності за командний запит): Більш складний EDA, де модель для оновлення стану відокремлена від моделі для зчитування стану. Це може покращити продуктивність, масштабованість і безпеку.
| Види ЕДА | Ключова функція |
|---|---|
| Сповіщення про подію | Просте сповіщення, жодних дій не потрібно |
| Передача стану на основі події | Зміна стану корисного навантаження |
| Пошук подій | Збережена послідовність подій |
| CQRS | Окремі моделі для оновлення та стану читання |
Впровадження та керування архітектурою, керованою подіями
EDA зазвичай використовуються в сценаріях, де дані в реальному часі та швидкість реагування є вирішальними, наприклад у системах торгівлі акціями, платформах електронної комерції або системах Інтернету речей. Однак керування та налагодження EDA може бути складним через їх асинхронну та розподілену природу.
Ключові проблеми включають відстеження подій, узгодженість даних і порядок подій. Ці проблеми можна пом’якшити за допомогою належного журналювання, кореляційних ідентифікаторів для відстеження ланцюжків подій, забезпечення ідемпотентності та впровадження надійних процедур обробки помилок і відновлення.
Порівняння та відмінності
EDA відрізняється від більш традиційних архітектур, керованих запитами, таких як Service Oriented Architecture (SOA) або Representational State Transfer (REST). У той час як SOA та REST зазвичай передбачають синхронне пряме спілкування та жорстко визначені контракти, EDA наголошує на асинхронній непрямій взаємодії та гнучких контрактах на події.
| Архітектура | спілкування | Взаємодія | Договір |
|---|---|---|---|
| SOA | Синхронний | Прямий | Жорсткий |
| ВІДПОЧИНОК | Синхронний | Прямий | Жорсткий |
| EDA | Асинхронний | Непрямий | гнучкий |
Майбутні перспективи та технології в архітектурі, керованій подіями
Зростаюча тенденція до мікросервісів і розподілених систем у поєднанні зі зростанням обробки даних у реальному часі робить EDA все більш актуальними. Очікується, що нові технології, такі як безсерверні обчислення, аналітика в реальному часі та IoT, сприятимуть подальшому впровадженню EDA.
У майбутньому ми можемо очікувати покращення інструментів керування подіями, можливостей налагодження та трасування, а також передових архітектурних шаблонів для кращої підтримки EDA.
Проксі-сервери та керована подіями архітектура
Проксі-сервери діють як посередники для запитів від клієнтів, які шукають ресурси з інших серверів, забезпечуючи різні рівні функціональності, безпеки та конфіденційності. У контексті EDA проксі-сервери можуть грати роль в управлінні трафіком подій, балансуванні навантажень і забезпеченні додаткових заходів безпеки. Наприклад, керований подіями проксі-сервер може динамічно маршрутизувати події на основі їх вмісту, навантаження чи інших факторів, таким чином підвищуючи адаптивність і надійність системи.
Пов'язані посилання
Щоб отримати додаткові відомості про архітектуру, керовану подіями, зверніться до таких ресурсів:
