Визначення архітектури на основі подій і чому воно має значення

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

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

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

Що таке подія?

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

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

• Платіж не вдається виконати або це успішно
• Користувач входить до системи або виходить з системи
• Запас опускається нижче порогового значення
• Відправка залишає склад або прибуває до місця призначення
• Порушення безпеки ініціює попередження
• Програма лояльності оновлює баланс балів
• Група підтримки створює тікет
• Клієнт оновлює свою адресу доставки
• Новий користувач створює обліковий запис
• Покупець подає огляд продукту
• Абонент оновлює або скасовує підписку

Основні компоненти архітектури, керованої подіями

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

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

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

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

Синхронна та асинхронна комунікація

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

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

Керовані запитом моделі порівняно з керованими подіями в архітектурі, керованій подіями

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

У моделі, керованій подіями, взаємодія починається з події — зміни стану або дії, яка ініціює обробку, і компоненти автоматично реагують, коли відбуваються події, наприклад, публікують/підписуються. Ця модель характерна на основі push-що означає, що система автоматично надсилає («штовхає») події або оновлення споживачам, як тільки вони відбуваються, не чекаючи, коли споживач запитує їх. Керовані подіями моделі є асинхронними, роз'єднаними та ідеальними для реагування в реальному часі.

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

Загальні шаблони архітектури, керованої подіями

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

Існує чотири основні шаблони передачі подій в архітектурі на основі подій:

• Публікація/підписка (також відома як «pub/sub»): з pub/sub, споживачі подій підписуються на повідомлення та канали, опубліковані виробниками подій. Коли подія публікується, вона надсилається безпосередньо всім абонентам за допомогою брокера подій. Щоб уникнути дублювання, події неможливо повторно відтворити або отримати доступ до них після використання, оскільки брокер їх видаляє.
• Стрімінг подій: з потоковою трансляцією подій продюсери публікують цілі потоки подій брокеру. Споживачі підписуються на потік і можуть читати з будь-якої його частини, споживаючи тільки ті події, які їм актуальні. При потоковій передачі подій події зберігаються у брокера навіть після їх споживання.
• Розділення відповідальності командного запиту (CQRS): за допомогою шаблону CQRS дизайн додатків та архітектурний рівень відокремлює операції читання та запису в різні моделі. Команди оновлюють стан під час читання запитів. В архітектурі, керованій подіями, шаблон CQRS часто працює з подіями, щоб поширювати зміни асинхронно, покращуючи масштабованість і продуктивність для складних систем.
• Визначення джерела поставки події: при визначенні джерела поставки система записує кожну зміну стану як подію в журналі лише для додатків замість того, щоб зберігати лише поточний стан сутності. Поточний стан можна перебудувати шляхом відтворення цих подій. Це надає повний контрольний журнал і підтримує сценарії відряджень у часі та відновлення.

Стилі обробки подій

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

1. Проста обробка подій: споживачі обробляють кожну подію в міру її отримання. Приклади:

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

2. Комплексна обробка подій: Споживачі обробляють ряд подій для виявлення шаблонів і виконання дій на основі результату. Приклади:

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

3. Обробка потоку подій: Споживачі обробляють і діють на постійний потік даних (дані в русі) в режимі реального часу за допомогою платформи потокового передавання даних. Приклади:

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

Компанії обирають свій стиль обробки подій у режимі реального часу на основі своїх індивідуальних потреб і випадків використання.

Як працює орієнтована на події архітектура

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

Нижче показано, як працює орієнтована на події архітектура, крок за кроком:

1. Подія відбувається: відбувається значуща зміна стану, наприклад, клієнт розміщує замовлення, датчик виявляє стрибок температури або платіж не вдається.
2. Продюсер події випускає подію: Заявка, де відбулася подія, діє як продюсер і публікує подію брокеру подій.
3. Брокер подій спрямовує захід: брокер подій виступає посередником для управління каналами подій та доставки події всім зацікавленим споживачам подій, що допомагає забезпечити надійну, масштабовану та роз'єднану комунікацію.
4. Споживачі подій реагують на подію: застосунки або сервіси, які підписалися на канал подій, обробляють подію та вживають відповідних заходів, таких як оновлення запасу, надсилання електронного листа з підтвердженням або ініціювання попередження.

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

Випадки використання та реальні приклади

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

Наступні приклади показують, як працює орієнтована на події архітектура на практиці.

Ресторанна промисловість

1. Студент коледжу робить замовлення на піцу за допомогою програми доставки їжі. Програма фіксує його основну інформацію — ім'я, адресу, платіжну інформацію та замовлення — і публікує подію «замовлення піци».
2. Піца-ресторан підписується на захід, виконує замовлення, публікує власний захід «готовий до замовлення» до служби доставки їжі.
3. Потім служба виділяє водія доставки, планує ЕТА та попереджає клієнта про те, що його пиріг на шляху.

Електронна комерція

1. Інтернет-покупець вводить дані своєї кредитної картки на сайті електронної комерції, який публікує подію «надісланий платіж».
2. Платіжна система підписується на подію, обробляє платіж і видає власну подію «платіж оброблено», що вказує на успіх або збій, і направляє його назад в інтерфейс сайту.
3. Інтерфейс користувача показує статус платежу клієнту та пропонує наступні кроки.

Деякі інші приклади архітектури на основі подій включають:

Телеметрія IoT

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

Аналітика та аналіз подій

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

Автоматизація

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

Фінансові операції

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

Логістичний ланцюг

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

ІТ-модернізація та роз'єднання попередньої системи

• Компанія вивантажує роботу зі свого мейнфрейму, публікуючи бізнес-події на сучасні хмарні сервіси для ключових функцій.
• Організація показує інтерфейси подій реального часу навколо застарілої ERP, щоб нові програми могли миттєво реагувати, не торкаючись бекенду.
• Бізнес відображає події зі старої CRM в сучасну SaaS-платформу, щоб під час поступової міграції підтримувати синхронізацію обох систем.

Сповіщення

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

Загальні випадки використання архітектури на основі подій включають в себе:

• Інтернет-покупець натискає продукт, і система реагує, генеруючи рекомендації щодо продуктів на основі подібних предметів.
• Роздрібний торгівець перевіряє глобальні транзакції для шахрайства та позначає будь-які підозрілі покупки компанії кредитної картки.
• Залучення клієнтів у режимі реального часу використовує потокове передавання даних про поведінку користувачів для ініціювання персоналізованих пропозицій або динамічного ціноутворення під час сеансу покупок.
• Моніторинг охорони здоров'я публікує життєво важливі ознаки пацієнта від підключених пристроїв, щоб миттєво попередити клініцистів, коли порогові значення перетинаються.
• Розумні міські операції керують світлофорами та графіками руху громадського транспорту на основі трафіку в режимі реального часу та погодних подій.
• Виявлення загроз кібербезпеки ідентифікує та реагує на підозрілу мережеву активність або спроби несанкціонованого доступу в режимі реального часу.
• Оптимізація хмарних ресурсів автоматично масштабує обчислювальні ресурси в багатохмарних середовищах, коли відбуваються зростання робочого навантаження.

Переваги архітектури, керованої подіями

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

1. Реагування в режимі реального часу та інтелектуальні робочі процеси: архітектура, керована подіями, дозволяє системам миттєво реагувати на події в міру їх виникнення, запускаючи автоматизовані робочі процеси та рішення в режимі реального часу. Це особливо важливо під час пікового попиту, наприклад, під час великих подій продажів або святкових днів. Організації можуть застосовувати цю здатність до повсякденних операцій, покращуючи все, починаючи від автоматизації ланцюжка поставок та виявлення шахрайства до персоналізованого залучення клієнтів.
2. Швидкість та ефективність за допомогою асинхронної комунікації: Додатки в архітектурі, керованій подіями, спілкуються асинхронно, що означає, що виробники публікують повідомлення про події, не чекаючи, поки споживачі їх отримають. Цей неблокуючий підхід покращує продуктивність, зменшує затримку та дозволяє системам обробляти масові об'єми подій без вузьких місць.
3. Гнучкість та масштабованість за допомогою роз’єднання та слабкого з’єднання: Компоненти в архітектурі, керованій подіями, роз’єднані або слабко з’єднані, тому вони працюють незалежно, не покладаючись на доступність один одного або внутрішню логіку. Це дозволяє легко оновлювати, тестувати та розгортати сервіси, не порушуючи всю систему. Роз'єднання також дозволяє легко додавати додаткових виробників і споживачів за потреби, забезпечуючи безперешкодне масштабування в міру зростання потреб бізнесу.
4. Стійкість і ізоляція несправностей: З роз'єднаними сервісами, збої в одному компоненті не каскадуються по всій системі. Кожна послуга може вийти з ладу самостійно, що робить архітектуру більш міцною і відмовостійкою, ніж традиційні щільно з'єднані моделі.
5. Майбутня інтеграція: Вільне з'єднання та асинхронний дизайн роблять керовану подіями архітектуру ідеальною для модернізації ІТ, роз'єднання застарілих систем та багатохмарних операцій. Організації отримують гнучкість для інтеграції нових технологій, таких як автоматизація на основі ШІ та аналіз подій, без переписування основних систем.

Виклики, обмеження та найкращі практики

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

Проблеми

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

Як сітка подій вписується в

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

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

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

Керовані подіями обмеження архітектури

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

Найкращі практики архітектури на основі подій

• Стандартизація схем і контрактів на події: використовуйте реєстри схем і примусово виконуйте перевірку, щоб підтримувати узгодженість між виробниками та споживачами.
• Впроваджуйте сильне управління: визначайте чіткі політики для володіння подіями, безпеки та відповідності. Використовуйте інструменти для аудиту та контролю доступу.
• Підвищення спостережуваності: Розгорніть рішення для моніторингу та трасування, щоб відстежувати потоки подій, виявляти аномалії та спрощувати налагодження.
• Дизайн для масштабованості та стійкості: Використовуйте функції сітки подій, такі як динамічна маршрутизація та тонка фільтрація для оптимізації продуктивності та відмовостійкості.
• Автоматизуйте за допомогою ШІ та аналітики подій: Incorporate AI-керовану аналітику та автоматизацію, щоб прогнозувати проблеми, оптимізувати маршрутизацію та покращити прийняття рішень у режимі реального часу.

Характеристики архітектури, керованої подіями

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

• Асинхронна комунікація: фундаментальна характеристика подієво-орієнтованої архітектури. Замість того, щоб чекати прямої відповіді, як у традиційних моделях, що керуються запитами, додатки публікують події та продовжують працювати без затримок. Цей стиль, що не блокує, забезпечує взаємодію в режимі реального часу між розподіленими системами та покращує швидкість реагування навіть при великому навантаженні.
• Вільне з'єднання: Додатки не повинні знати про доступність один одного, структуру API або внутрішню логіку; вони просто спілкуються через події, направлені брокером подій або сіткою подій. Забезпечуючи незалежно діяльність виробників і споживачів подій, команди можуть додавати, оновлювати або замінювати послуги, не порушуючи ширшу систему, підвищуючи маневреність і відмовостійкість.
• Незалежне масштабування: оскільки компоненти роз'єднані, окремі сервіси можуть масштабуватися вгору або вниз на основі потреби — не вимагаючи змін у додатках вище або нижче у потоці. SAP виділяє це як основну користь інтеграції на основі подій, особливо в гібридних і багатохмарних середовищах, де піковими навантаженнями та розподіленими робочими навантаженнями необхідно ефективно керувати.

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

Запитання та відповіді