Development of a methodology for the implementation of transactions in distributed systems with microservice architectura
The paper describes the analysis of the problems of using microservice architecture in distributed systems. Emphasis is placed on flexibility in the choice of technologies, scalability and organization of teams working on given microservices, technical and domain problems of transaction implementati...
Збережено в:
| Дата: | 2024 |
|---|---|
| Автори: | , , |
| Формат: | Стаття |
| Мова: | Ukrainian |
| Опубліковано: |
Інститут програмних систем НАН України
2024
|
| Теми: | |
| Онлайн доступ: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/608 |
| Теги: |
Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
|
| Назва журналу: | Problems in programming |
| Завантажити файл: |  |
Репозитарії
Problems in programming| id |
pp_isofts_kiev_ua-article-608 |
|---|---|
| record_format |
ojs |
| resource_txt_mv |
ppisoftskievua/ad/c0c24c51f586f8a4e90913328079e1ad.pdf |
| spelling |
pp_isofts_kiev_ua-article-6082024-04-27T16:34:32Z Development of a methodology for the implementation of transactions in distributed systems with microservice architectura Розробка методології імплементації транзакцій в розподілених системах з мікросервісною архітектурою Glybovets, A.M. Glybovets, M.M. Chernova, T.A. distributed system; distributed transactions; microservice architecture; Transactional Outbox pattern; asynchronous communication; Kafka; Debeziu UDC 004.41 розподілена система; розподілені транзакції; мікросервісна архітектура; патерн Transactional Outbox; асинхронне спілкування; Kafka; Debezium УДК 004.41 The paper describes the analysis of the problems of using microservice architecture in distributed systems. Emphasis is placed on flexibility in the choice of technologies, scalability and organization of teams working on given microservices, technical and domain problems of transaction implementation in comparison with a monolithic system. The main focus is on transactions, as they ensure atomicity, consistency, isolation, and persistence across multiple services. In the process of analyzing modern approaches and solutions for working with transactions in distributed systems, it was found that one of the effective solutions is the use of the Transactional Outbox pattern. Its implementation in the form of Spring starter is presented. The latter is added to the system, configured and facilitates the use of transactions and the publication of events that are part of a transaction in a microservice architecture. The developed methodology for implementing distributed transactions based on message queues, using the above-mentioned starter, is described in detail. The basic configurations and settings of message queues for the correct operation of transactions in distributed systems are definedProblems in programming 2024; 1: 64-76 У роботі описано аналіз проблематики використання мікросервісної архітектури в розподілених системах. Наголос зроблено на гнучкості у виборі технологій, масштабованості та організації команд, які працюють над заданими мікросервісами, технічних і доменних проблемах реалізації транзакцій у порівнянні з монолітною системою. Основну увагу приділено транзакціям, оскільки вони забезпечують дотримання атомарності, консистентності, ізольованості та стійкості над декількома сервісами.У процесі аналізу сучасних підходів та рішень для роботи з транзакціями в розподілених системах було виявлено, що одним з ефективних рішень є використання патерну Transactional Outbox. Представлено його реалізацію у вигляді Spring starter. Останній додається до системи, конфігурується та полегшує використання транзакцій і публікацію подій, які є частинами транзакції у мікросервісній архітектурі.Problems in programming 2024; 1: 64-76 Інститут програмних систем НАН України 2024-04-01 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/608 10.15407/pp2024.01.064 PROBLEMS IN PROGRAMMING; No 1 (2024); 64-76 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 1 (2024); 64-76 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 1 (2024); 64-76 1727-4907 10.15407/pp2024.01 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/608/658 Copyright (c) 2024 PROBLEMS IN PROGRAMMING |
| institution |
Problems in programming |
| baseUrl_str |
https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| datestamp_date |
2024-04-27T16:34:32Z |
| collection |
OJS |
| language |
Ukrainian |
| topic |
distributed system distributed transactions microservice architecture Transactional Outbox pattern asynchronous communication Kafka Debeziu UDC 004.41 |
| spellingShingle |
distributed system distributed transactions microservice architecture Transactional Outbox pattern asynchronous communication Kafka Debeziu UDC 004.41 Glybovets, A.M. Glybovets, M.M. Chernova, T.A. Development of a methodology for the implementation of transactions in distributed systems with microservice architectura |
| topic_facet |
distributed system distributed transactions microservice architecture Transactional Outbox pattern asynchronous communication Kafka Debeziu UDC 004.41 розподілена система розподілені транзакції мікросервісна архітектура патерн Transactional Outbox асинхронне спілкування Kafka Debezium УДК 004.41 |
| format |
Article |
| author |
Glybovets, A.M. Glybovets, M.M. Chernova, T.A. |
| author_facet |
Glybovets, A.M. Glybovets, M.M. Chernova, T.A. |
| author_sort |
Glybovets, A.M. |
| title |
Development of a methodology for the implementation of transactions in distributed systems with microservice architectura |
| title_short |
Development of a methodology for the implementation of transactions in distributed systems with microservice architectura |
| title_full |
Development of a methodology for the implementation of transactions in distributed systems with microservice architectura |
| title_fullStr |
Development of a methodology for the implementation of transactions in distributed systems with microservice architectura |
| title_full_unstemmed |
Development of a methodology for the implementation of transactions in distributed systems with microservice architectura |
| title_sort |
development of a methodology for the implementation of transactions in distributed systems with microservice architectura |
| title_alt |
Розробка методології імплементації транзакцій в розподілених системах з мікросервісною архітектурою |
| description |
The paper describes the analysis of the problems of using microservice architecture in distributed systems. Emphasis is placed on flexibility in the choice of technologies, scalability and organization of teams working on given microservices, technical and domain problems of transaction implementation in comparison with a monolithic system. The main focus is on transactions, as they ensure atomicity, consistency, isolation, and persistence across multiple services. In the process of analyzing modern approaches and solutions for working with transactions in distributed systems, it was found that one of the effective solutions is the use of the Transactional Outbox pattern. Its implementation in the form of Spring starter is presented. The latter is added to the system, configured and facilitates the use of transactions and the publication of events that are part of a transaction in a microservice architecture. The developed methodology for implementing distributed transactions based on message queues, using the above-mentioned starter, is described in detail. The basic configurations and settings of message queues for the correct operation of transactions in distributed systems are definedProblems in programming 2024; 1: 64-76 |
| publisher |
Інститут програмних систем НАН України |
| publishDate |
2024 |
| url |
https://pp.isofts.kiev.ua/index.php/ojs1/article/view/608 |
| work_keys_str_mv |
AT glybovetsam developmentofamethodologyfortheimplementationoftransactionsindistributedsystemswithmicroservicearchitectura AT glybovetsmm developmentofamethodologyfortheimplementationoftransactionsindistributedsystemswithmicroservicearchitectura AT chernovata developmentofamethodologyfortheimplementationoftransactionsindistributedsystemswithmicroservicearchitectura AT glybovetsam rozrobkametodologííímplementacíítranzakcíjvrozpodílenihsistemahzmíkroservísnoûarhítekturoû AT glybovetsmm rozrobkametodologííímplementacíítranzakcíjvrozpodílenihsistemahzmíkroservísnoûarhítekturoû AT chernovata rozrobkametodologííímplementacíítranzakcíjvrozpodílenihsistemahzmíkroservísnoûarhítekturoû |
| first_indexed |
2024-09-16T04:08:53Z |
| last_indexed |
2024-09-16T04:08:53Z |
| _version_ |
1818568523440455680 |
| fulltext |
Агентно-орієнтовані інформаційні системи
64
© А. М. Глибовець, Т. А.Чернова, М. М. Глибовець, 2024
ISSN 1727-4907. Проблеми програмування. 2024. №1
УДК 004.41 http://doi.org/10.15407/pp2024.01.64
А. М. Глибовець, Т. А. Чернова, М. М. Глибовець
РОЗРОБКА МЕТОДОЛОГІЇ ІМПЛЕМЕНТАЦІЇ ТРАНЗАКЦІЙ
В РОЗПОДІЛЕНИХ СИСТЕМАХ З МІКРОСЕРВІСНОЮ
АРХІТЕКТУРОЮ
У роботі описано аналіз проблематики використання мікросервісної архітектури в розподілених сис-
темах. Наголос зроблено на гнучкості у виборі технологій, масштабованості та організації команд, які
працюють над заданими мікросервісами, технічних і доменних проблемах реалізації транзакцій у по-
рівнянні з монолітною системою. Основну увагу приділено транзакціям, оскільки вони забезпечують
дотримання атомарності, консистентності, ізольованості та стійкості над декількома сервісами.
У процесі аналізу сучасних підходів та рішень для роботи з транзакціями в розподілених системах
було виявлено, що одним з ефективних рішень є використання патерну Transactional Outbox. Предста-
влено його реалізацію у вигляді Spring starter. Останній додається до системи, конфігурується та поле-
гшує використання транзакцій і публікацію подій, які є частинами транзакції у мікросервісній
архітектурі.
Ключові слова: розподілена система, розподілені транзакції, мікросервісна архітектура, патерн
Transactional Outbox, асинхронне спілкування, Kafka, Debezium.
Вступ
Наразі для розробки складних про-
грамних систем дедалі частіше використо-
вується мікросервісна архітектура (МА). Це
рішення дозволяє розбивати систему на не-
великі незалежні компоненти (застосунки)
та отримувати швидку розгортку, масшта-
бованість та гнучкість. Однак в таких роз-
поділених системах (РС) виникають певні
труднощі керування транзакціями, оскі-
льки вони вимагають забезпечення атомар-
ності, консистентності, ізольованості та
стійкості над декількома сервісами [1-3].
Транзакції у базі даних – робоча опе-
раційна одиниця [2] для роботи із базою да-
них, певна послідовність змін, що викону-
ються в логічному порядку користувачем
або програмою, яка працює із базою даних.
Якщо відбувається будь-яка операція з ін-
терфейсом користувача, у базі даних вико-
нується транзакція. Основні концепції тра-
нзакцій описуються абревіатурою ACID -
Atomicity, Consistency, Isolation, Durability
(Атомарність, Узгодженість, Ізольованість,
Довговічність).
Атомарність гарантує, що будь-яка
транзакція буде зафіксована тільки цілком і
кожен крок транзакції виконається повні-
стю. Якщо ж одна з операцій в послідовно-
сті завершиться із помилкою, то вся транза-
кція буде скасована. Існує поняття «відкату
змін» (rollback), за якого всі зміни у зворот-
ному порядку скасовуватимуться. У разі
виникнення помилки під час проходження
транзакції, користувач не побачить ніяких
змін.
Узгодженість (консистентність) за-
безпечує те, що будь-яка завершена транза-
кція фіксує тільки допустимі результати.
Під час виконання принципу узгодженості,
база даних повинна завжди переходити із
одного несуперечливого стану в інший не-
суперечливий стан. Умова узгодженості є
необхідною для підтримки четвертої влас-
тивості транзакції - довговічності.
Ізольованість визначає те, що резуль-
тат кожної транзакції не повинен залежати
від виконання інших паралельних транзак-
цій. На практиці повна ізольованість важко
досяжна. Тому вводиться поняття «рівні ізо-
льованості». Послаблення ізольованості тра-
нзакцій призводить до відомих проблем:
«брудне читання» (dirty read), «втрачене
оновлення» (lost update), «брудний запис»
(dirty write), «невідтворюване читання»
(nonrepeatable read), «фантомне читання»
(phantom read), «перекошене читання або за-
пис» (read and write skew) [2]. У системах із
МА, де застосовуються транзакції, розподі-
лені між кількома сервісами, проблема ізо-
льованості постає особливо гостро.
Агентно-орієнтовані інформаційні системи
65
РС - це сукупність незалежних між
собою компонентів, які взаємодіють та ко-
ординують свої дії для досягнення спільної
мети [1]. Ці компоненти можуть бути апа-
ратними або програмними, можуть знахо-
дитись на різних комп'ютерах та бути пов'-
язані спільною мережею. Компоненти взає-
модіють між собою, передаючи повідом-
лення, використовуючи віддалені виклики
процедур або інші форми комунікації. Цей
принцип взаємодії дозволяє кожному ком-
поненту працювати незалежно і спільно.
Управління такою системою є складним
процесом, оскільки вимагає вирішення та-
ких проблем, як багатопоточність, консис-
тентність даних, стійкість до помилок, збе-
реження цілісності даних та масштабовано-
сті системи.
У МА застосунок – це набір невели-
ких, незалежних сервісів, кожен з яких має
певну бізнес-функціональність. Ці сервіси
можуть бути розроблені, розгорнуті та мас-
штабовані незалежно один від одного, що
дозволяє досягти більшої гнучкості та ди-
намічності порівняно з традиційними моно-
літними архітектурними рішеннями [2].
Спілкування між сервісами в МА ві-
дбувається за використанням чітко визна-
чених API, застосовуючи протоколи кому-
нікації, такі як REST, черги повідомлень.
Це дозволяє системі легше розвиватися та
масштабуватися, оскільки зміни в одному
сервісі не обов'язково потребують змін у
всій системі. Однак архітектура мікросерві-
сів також вносить власний набір викликів,
включаючи управління консистентністю
даних, балансування навантаження та моні-
торинг, трейсинг та логування [4]. Ці ви-
клики потрібно ретельно досліджувати для
забезпечення стійкості та масштабованості
системи.
Тому виникає необхідність ефектив-
них рішень для роботи з транзакціями в РС.
Виникли спеціалізовані патерни та методо-
логії, які пропонують використання окре-
мих підходів до реалізації такої роботи. На-
приклад, патерн "Transactional Outbox
(ТО)" розроблений для забезпечення атома-
рності операцій та публікації подій як час-
тини транзакційного процесу.
Метою цієї статті є опис аналізу іс-
нуючих загальних рішень імплементації
транзакцій в РС мікросервісного типу та
створеної методології реалізації розподіле-
них транзакцій на базі черг повідомлень.
Було виявлено, що одним з ефективних рі-
шень є використання патерну TO. Предста-
влено розроблену нами його реалізацію у
вигляді Spring starter. Останній додається
до системи, конфігурується та полегшує ви-
користання транзакцій і публікацію подій,
які є частинами транзакції в МА.
1. Проблеми в мікросервісній
архітектурі
Під час проєктування комунікації
між мікросервісами потрібно враховувати:
налаштування правильної комунікації між
сервісами, можливі затримки в мережі, про-
блеми з доступністю серверів та затримки
між запитами [5]. У разі налаштування ко-
мунікації між мікросервісами важливою
складовою є забезпечення відмовостійко-
сті. Потрібно враховувати і консистент-
ність даних. До прикладу, атомарне онов-
лення даних (або всі операції успішні, або
жодна не успішна) є не простим викликом
у побудові МА.
Управління консистентністю даних
включає розв'язання двох основних про-
блем: роботу з багатопоточністю та відмо-
востійкістю. В багатопоточному середо-
вищі, коли кілька процесів або потоків на-
магаються одночасно отримувати доступ та
змінювати ті самі дані, може виникати не-
консистентність даних, оскільки різні вузли
можуть мати різні варіації тих самих даних.
Відмова ж може відбуватися, коли вузол
або мережеве з'єднання зазнають пошко-
джень. Наприклад, сервіс в поточний мо-
мент часу не відповідає або повертає поми-
лку, що призводить до часткових або не-
консистентних оновлень даних.
Існує кілька підходів до управління
консистентністю даних. Один із підходів -
використання розподілених транзакцій
(РТ), які забезпечують виконання групи
операцій на кількох вузлах атомарно. РТ -
це транзакції, що охоплюють кілька баз да-
них або систем, які можуть знаходитися на
різних серверах або навіть у різних геогра-
фічних місцях.
Агентно-орієнтовані інформаційні системи
66
У РТ координатор транзакції відпові-
дає за координацію дій усіх вузлів системи.
Координатор спочатку запускає транзакцію,
а потім надсилає запити до учасників систем
для виконання потрібних операцій. Якщо всі
вузли успішно виконують свої операції, ко-
ординатор підтверджує транзакцію. Однак,
якщо будь-яка з систем не виконує свою
операцію, то координатор скасовує всю тра-
нзакцію, скасовуючи водночас усі зміни,
зроблені учасниками систем.
Хоча розподілені транзакції можуть
бути корисні для керування узгодженістю
даних у МА, вони також можуть створю-
вати власний набір проблем та труднощів,
таких як додаткове навантаження на проду-
ктивність та операційну складність.
2. Патерни, що полегшують
роботу з розподіленими
транзакціями
Розглянемо деякі відомі мікросерві-
сні патерни, що вирішують проблеми,
пов’язані з РТ та їх реалізації [6-7].
Шаблон двофазного коміту (2PC) є
класичним розподіленим транзакційним
шаблоном, який використовується для ко-
ординації транзакцій між декількома систе-
мами. У цьому патерні існує координатор,
що ініціює транзакцію, й інші учасники (мі-
кросервіси, вузли системи), що отримують
повідомлення від координатора та зберіга-
ють транзакцію [8]. Координатор визначає
готовність кожного вузла зберегти транзак-
цію і, у випадку готовності усіх сервісів,
відправляє друге повідомлення, аби вказати
всім сервісам зберегти транзакцію. Якщо
якийсь сервіс не готовий зберегти транзак-
цію, координатор відправляє повідомлення
про відмову від транзакції. Цей патерн ви-
рішує проблему консистентності даних в
РС забезпечуючи те, що всі сервіси здійс-
нюють або скасовують транзакцію у коор-
динований спосіб (за допомогою сервісу
координатора). Він уможливлює забезпе-
чення атомарності та консистентності між
кількома системами, але може спричиняти
проблеми, пов'язані з масштабованістю, до-
ступністю та продуктивністю.
Серед відомих реалізацій цього па-
терну можна виділити наступні: Atomikos
(система керування транзакціями, засно-
вана на Java), Bitronix (менеджер транзак-
цій, заснований на Java), NServiceBus (пла-
тформа для передачі повідомлень та інтег-
рації на основі .NET) .
Шаблон Saga є альтернативою шаб-
лону 2PC. Принцип роботи шаблону Saga
полягає у тому, що після виконання локаль-
ної транзакції база даних оновлюється, а
повідомлення про подію публікується для
ініціювання наступної локальної транзакції
до баз даних. У Saga використовуються такі
терміни, як: сompensating transaction (тран-
закція, що скасовує зміни, виконані попере-
дньою транзакцією), сountermeasure (ди-
зайн техніка, що використовується для ком-
пенсації нестачі рівня ізоляції),
сompensatable transaction (транзакція, яку
можна компенсувати), рivot transaction
(транзакція, що є маркером для саги: якщо
транзакція успішна, то сага продовжува-
тиме ряд дій для завершення послідовності
транзакцій) та retriable transaction (повторна
транзакція). Цей шаблон дозволяє забезпе-
чити правильність виконання розподіленої
між мікросервісами транзакції, а кожну ло-
кальну транзакцію можна компенсувати за
допомогою її компенсуючої транзакції.
Saga також гарантує, що всі операції будуть
завершені успішно або відповідні компен-
саційні транзакції будуть запущені для ска-
сування раніше виконаної роботи. Є два
види координації транзакцій у Saga: хорео-
графія та оркестрація.
Заслуговують на увагу такі реалізації
цього патерну: Uber Cadence (РС оркестру-
вання робочих процесів, яка містить підтри-
мку як саг на основі хореографії, так і саг на
основі оркестрації), AxonIQ (відкрита плат-
форма для створення мікросервісів, заснова-
них на подіях, яка включає підтримку саг),
Lightbend Akka (набір інструментів та сере-
довище виконання для побудови високопро-
дуктивних, розподілених та відмовостійких
систем, яка містить підтримку саг).
Окремо стоїть модель Eventual
consistency. Це спосіб управління консисте-
нтністю даних в РС без використання тра-
диційних транзакцій. У моделі дозволя-
ється сервісам незалежно оновлювати свої
локальні сховища даних, а послідовна кон-
систентність досягається за допомогою
Агентно-орієнтовані інформаційні системи
67
асинхронних оновлень та вирішення конф-
ліктів. Хоча цей підхід може бути більш ма-
сштабованим та гнучким, ніж традиційні
транзакції, він потребує обережного керу-
вання конфліктами даних та може призво-
дити до тимчасових неузгодженостей.
Компенсаційний патерн - це спосіб
скасувати наслідки невдалої транзакції без
потреби повного відкату системи. У цьому
патерні виконується компенсуюча транзак-
ція для скасування наслідків початкової
транзакції. Цей патерн часто використову-
ється в поєднанні з патерном саги для керу-
вання локальними транзакціями в межах
сервісу.
Патерн ТО надає спосіб забезпе-
чення консистентності даних у РС, коли
сервіс повинен публікувати події як час-
тину транзакції. Це легкий та ефективний
спосіб керування координацією подій між
декількома системами, не вводячи складно-
сті традиційних механізмів РТ. Він дозво-
ляє сервісу публікувати події у спосіб, який
консистентний з локальною базою даних,
не потребуючи механізмів 2PC або інших
складних механізмів, як от saga, чи компен-
саційний патерн. Це легкий і ефективний
спосіб керування координацією подій між
декількома системами.
Патерн часто реалізують на базі
фреймворку Spring Cloud Stream. Він приз-
начений для створення мікросервісних за-
стосунків, які працюють на основі подій.
Він дозволяє публікувати та отримувати
події за допомогою різних систем повідом-
лень, таких як Apache Kafka, RabbitMQ та
Google Pub/Sub. Його модель програму-
вання для реалізації патерну ТО базується
на API Spring Transaction.
Говорячи про відомі реалізацій да-
них мікросервісних патернів варто зазна-
чити, що їх можна реалізовувати різнома-
нітними способами, підлаштовуючись під
клієнтські запити та технічну базу застосу-
нку. Наприклад, Eventuate.io є платфор-
мою для створення та управління мікро-
сервісами, що працюють за принципом
event-driven applications. Вона включає й
підтримку шаблону ТО, надає набір кліє-
нтських бібліотек для Java та Spring, які
спрощують інтеграцію шаблону ТО в за-
стосунки Spring Boot.
3. Transactional Outbox як
асинхронний спосіб вирішення
проблеми обміну даними в
розподілених системах
Під час використання МА пошире-
ним є послуговування своїми локальними
сховищами даних - database per service.
Наприклад, сервіс, що відповідає за
створення замовлень, зберігає замовлення в
реляційній базі даних. Водночас сервіс
може бажати надіслати подію про нове за-
мовлення до Apache Kafka, щоб поширити
цю інформацію на інші зацікавлені сервіси.
Виконання цих двох дій може призвести до
неузгодженості даних: нове замовлення
буде збережене в локальній базі даних, але
відповідного повідомлення до Kafka не
буде надіслано (наприклад, через проблему
з мережею). Або навпаки, ми можемо наді-
слати повідомлення до Kafka, але не змо-
жемо зберегти замовлення в локальній базі
даних. Обидві ситуації є небажаними та мо-
жуть призвести до того, що нібито успішно
створене замовлення не буде відправлене.
Або буде створений запит на відправку, але
в самому сервісі замовлень не буде відомо-
стей про відповідне замовлення.
Оптимальним рішенням цієї про-
блеми була б зміна лише одного ресурсу:
або ж збереження даних на сервері, або ж
відправка повідомлення і в подальшому
оновлювати інший ресурс на основі успіш-
ності першого. Якщо розглянути спершу
зміну ресурсу Apache Kafka, то послідов-
ність подій виглядатиме наступним чином:
сервіс, що відповідає за збереження замов-
лень, не буде зберігати замовлення в базі,
натомість відправить подію в брокер пові-
домлень та підпишеться на цей же топік для
отримання результату про успішну або не-
успішну відправку. Отож, змінюється лише
один ресурс за раз, і, якщо щось піде не так,
ми одразу дізнаємося про це та повідомимо
замовнику, що запит не вдалося виконати.
Оскільки сервіс підписується на топік в
Kafka, він буде отримувати сповіщення про
доставку нового повідомлення в цей же то-
пік і зможе зберегти нове замовлення на за-
купівлю у своїй базі даних.
Чим погане таке рішення? Якщо в
системі виникатиме потреба додати функ-
Агентно-орієнтовані інформаційні системи
68
ціонал на зчитування усіх замовлень в базі,
то наш сервіс не зможе читати свої власні
записи (read your own write semantic). При-
пустимо, що сервіс замовлень також має
API для пошуку всіх замовлень певного клі-
єнта. У разі виклику цього API безпосеред-
ньо після розміщення нового замовлення
через асинхронну обробку повідомлень з
топіка Kafka може статися так, що замов-
лення на закупівлю ще не було збережено в
базі даних сервісу і, отже, його не буде по-
вернуто цим топіком. Це може призвести
до плутанини. Наприклад, користувачі мо-
жуть пропустити новостворені замовлення
в своїй історії покупок та загалом втратити
вкрай важливу інформацію про замов-
лення.
Існують способи впоратися з цією
ситуацією. Так, сервіс може зберігати нові
замовлення на закупівлю в оперативній па-
м'яті та відповідати на наступні запити на
основі цих даних. Однак це швидко стає не-
простою задачею у разі реалізації складні-
ших запитів або врахуванні того, що сервіс
замовлень може складатися з кількох вузлів
у кластерному середовищі, що потребува-
тиме передачі цих даних в межах кластера.
Більш слушним рішенням буде зміна спе-
ршу стану бази, а потім відправка повідом-
лення, базуючись на зміні цього ресурсу.
Дане рішення якраз таки можна імплемен-
тувати, використовуючи патерн ТО [9].
Патерн ТО вирішує завдання збере-
ження консистентності та надійності даних
у розподілених транзакційних середовищах
шляхом збереження даних та подій,
пов’язаних з ними в межах однієї бази да-
них, та гарантує публікацію збережених по-
дій. Публіковані події відображають зміни
стану системи, які потрібно повідомити ін-
шим вузлам розподіленої системи. Дода-
ючи події в таблицю "outbox", патерн забез-
печує їх надійне зберігання в межах тієї са-
мої атомарної транзакції разом із основною
операцією бізнес логіки. Цей підхід надає
гарантії консистентності даних, оскільки
або всі зміни комітяться разом, або жодна з
них не виконується (із скасуванням однієї
скасовуються усі). Існує й окремий фоно-
вий процес, відомий як "паблішер" подій
або диспетчер подій. Він читає події з таб-
лиці "outbox" та публікує їх у відповідний
посередник повідомлень або систему об-
міну повідомленнями – це може бути
Apache Kafka, RabbitMQ та інші. Шляхом
розподілення процесу публікації подій від
основної транзакції, шаблон ТО допомагає
покращити продуктивність, масштабова-
ність та стійкість системи.
Один із базових підходів реалізації
патерну ТО є розробка та використання
власних сервісів, що будуть зчитувати події
з таблиці Outbox, менеджити їхній подаль-
ший життєвий цикл та керувати обробкою
різноманітних помилкових сценаріїв. Осно-
вна перевага такого підходу є його гнуч-
кість, оскільки він дозволяє налаштувати
логіку обробки повідомлень відповідно до
конкретних вимог.
У патерні кожен мікросервіс підтри-
мує таблицю "outbox" у власній локальній
базі даних. Ця таблиця є своєрідним буфе-
ром, де зберігаються події та повідомлення
до їх поширення у зовнішні системи (на-
приклад, до публікування у меседж бро-
кер).
Структура таблиці outbox table зазвичай за-
лежить від конкретної реалізації та вимог
МА. Однак є кілька загальних атрибутів, які
часто присутні в таблиці вихідної скриньки,
такі як message_id, message_payload, status,
timestamp та інші. Конкретна структура та
додаткові поля можуть варіюватися зале-
жно від деталей реалізації та вимог архіте-
ктури мікросервісів.
У такій реалізації патерну існують
спеціальні консьюмери, які відповідають за
періодичні запити до таблиці "outbox" для
отримання не переданих та не зчитаних ра-
ніше повідомлень. Цими консьюмерами
можуть бути окремі мікросервіси або ок-
ремі модулі власного застосунку. Після
отримання повідомлення з таблиці "outbox"
спеціальний консьюмер обробляє його від-
повідно до визначеної бізнес-логіки. Цей
процес може включати форматування пові-
домлення, виклик API або сервісів та обро-
бку можливих помилок чи повторних
спроб. У розробці такого консьюмера варто
зважати на необхідність надання гарантова-
ного читання, відправки та підтвердження
оброблених повідомлень. Підтвердження
читання, до прикладу, можна реалізовувати
оновлюючи статус у таблиці "outbox" .
Агентно-орієнтовані інформаційні системи
69
Підхід із використанням спеціаль-
них консьюмерів надає деталізований кон-
троль і налаштування споживання та обро-
бки повідомлень. Він дозволяє адаптувати
логіку обробки під задоволення конкретних
вимог, таких як перетворення даних, пере-
вірка безпеки або правил валідації.
Хоча даний варіант реалізації пате-
рну сприяє гнучкості і можливості налаш-
тування, він також має кілька потенційних
недоліків, які варто врахувати. Серед ваго-
мих недоліків можна вважати збільшений
обсяг розробки та потреби підтримки в екс-
плуатації. Необхідно проєктувати, реалізо-
вувати, тестувати та підтримувати компо-
ненти власних консьюмерів. А це збільшує
загальний обсяг роботи з розробки та пот-
ребує більше зусиль для їхньої підтримки.
Масштабування власних споживачів може
також викликати певні складнощі, особ-
ливо у роботі з великою кількістю повідом-
лень та подій або одночасним доступом до
таблиці outbox. Потрібно використовувати
відповідні механізми балансування наван-
таження та дбати про ефективну та масшта-
бовану обробку повідомлень.
4. Поняття WAL та CDC
Change Data Capture (CDC) та Write-
Ahead Log (WAL) є пов'язаними концепці-
ями в контексті систем баз даних, але вони
служать різним цілям.
"Write-Ahead Log" (WAL) є техні-
кою, яка часто використовується в систе-
мах баз даних для забезпечення стійкості
даних та підтримки консистентності тран-
закцій. Вона передбачає запис змін, пов'яза-
них із транзакціями, у журнальний файл пе-
ред їхнім застосуванням до фактичних фай-
лів даних бази даних. WAL виступає як по-
слідовний журнал усіх змін, зроблених у
базі даних, як успішно здійснених, так і не-
завершених транзакцій [10].
Коли транзакція змінює дані в базі
даних, відповідні зміни спочатку запису-
ються в WAL. Це гарантує безпечне збері-
гання журналу на надійному носії, перш
ніж модифікації застосовуються до самої
бази даних. Завдяки цьому підходу система
бази даних гарантує, що в разі збою або ава-
рії системи зміни, записані в WAL, можуть
бути відтворені та застосовані для віднов-
лення бази даних у консистентний стан.
WAL надає кілька переваг. Вона по-
кращує продуктивність бази даних, дозво-
ляючи буферизувати модифікації в пам'яті
та записувати їх на диск у ефективнішому
послідовному порядку. Вона також забез-
печує цілісність даних, надаючи надійний
запис транзакцій, що дозволяє відновлення
після збоїв та скасування операцій. Крім
того, WAL дозволяє реплікацію бази даних
та реалізацію резервних серверів, репліку-
ючи журнал на інші системи для потреб си-
нхронізації.
Загалом використання WAL підви-
щує стійкість, надійність та можливість від-
новлення систем баз даних, роблячи його фу-
ндаментальною технікою для забезпечення
консистентності та доступності даних.
Change Data Capture (CDC) - це тех-
ніка, що використовується у галузі інтегра-
ції та синхронізації даних для захоплення та
передачі змін даних у реальному часі з баз
даних до цільових систем [11]. CDC дозво-
ляє постійно відстежувати та витягувати
зміни даних, такі як вставки, оновлення та
видалення, у міру їх виникнення в джерелі
бази даних. Ці зловлені зміни даних потім
перетворюються у формат, який може бути
використаний іншими застосунками або ре-
плікований до інших баз даних. CDC дозво-
ляє ефективну та майже в реальному часі
реплікацію даних, синхронізацію та інтег-
рацію між різноманітними системами, за-
безпечуючи консистентність та актуаль-
ність даних у екосистемі. Це широко вико-
ристовується в сценаріях, де своєчасна та
точна передача даних є критичною.
Зв'язок між CDC та WAL полягає в
тому, що CDC часто використовує інфор-
мацію, записану в WAL, для захоплення та
відстеження змін. Оскільки WAL містить
послідовний журнал усіх модифікацій,
зроблених у базі даних, його можна вико-
ристовувати як надійне джерело для видо-
бутку окремих змін та їх передачі іншим си-
стемам або споживачам.
Аналізуючи WAL, механізми CDC
можуть ідентифікувати конкретні зміни,
що сталися, включаючи редаговані рядки,
стовпці та значення. Потім вони можуть за-
фіксувати ці зміни та перетворити їх у фор-
Агентно-орієнтовані інформаційні системи
70
мат, придатний для передачі, як наприклад,
створення подій зміни або оновлення реп-
лік бази даних.
5. Debezium як спосіб
імплементації транзакцій
Debezium - це розподілена платфо-
рма з відкритим кодом, яка використовує
техніку Capture Data Capture (CDC) для
отримання та передачі змін даних у реаль-
ному часі із журналів транзакцій бази даних
(використовуючи WAL) [12]. Вона інтегру-
ється з різноманітними популярними ба-
зами даних, такими як MySQL, PostgreSQL,
MongoDB та інші за рахунок конекторів до
баз даних. А також надає незамінні функції,
такі, як здатність захоплювати зміни в усіх
аспектах обробки даних включно із встав-
ками, оновленням та видаленням. Під час
налаштування для роботи з певною базою
даних Debezium підключається до журналу
транзакцій бази даних, який, як правило,
реалізується за допомогою WAL. WAL ре-
єструє всі модифікації, зроблені в базі да-
них, включаючи вставки, оновлення та ви-
далення, в послідовному та стійкому жур-
нальному файлі. Debezium зчитує зміни, за-
писані в WAL, та перетворює їх у потік по-
дій змін. Ці події змін потім перетворю-
ються в стандартизований формат, такий як
JSON або Avro, і стають доступними для
споживання застосунками або системами
вниз по ланцюжку.
Завдяки використанню підходу CDC
на основі WAL, Debezium забезпечує надій-
ний та мінімальний вплив захоплення да-
них, не навантажуючи додатково джерело
бази даних [13]. Така ефективність допов-
нюється легко розширюваною архітекту-
рою, яка може пристосовуватися до ситуа-
цій стійкості до відмов, сприяючи простій
синхронізації та інтеграції з численними
платформами. Тому внесок Debezium у
створення процесів стрімінгу в реальному
часі, разом із наданням масштабованих ре-
активних потоків для сучасних розподіле-
них фреймворків, неможливо недооцінити.
Цей підхід мінімізує вплив на продуктив-
ність джерела бази даних та забезпечує
майже реальний час та точну реплікацію та
інтеграцію даних між різними системами.
Debezium побудований на основі
Apache Kafka. На відміну від підходу, за-
снованого на пулінгу даних, Debezium
отримує події з дуже низьким навантажен-
ням на систему та практично в режимі реа-
льного часу [12]. Debezium поставляється з
CDC-конекторами для кількох баз даних,
таких як MySQL, Postgres та SQL Server і
після отримання даних може передавати їх
іншим сервісам, зокрема, може публікувати
подію в меседж брокер. Надійність та запо-
бігання втрати даних є важливими характе-
ристиками платформи.
Debezium надає пріоритет надійно-
сті, використовуючи журнали транзакцій,
такі як Write-Ahead Log, що надаються сис-
темами баз даних, з якими він інтегрується.
Ці журнали є надійним та міцним джерелом
для отримання інформації про зміни даних.
Debezium підключається до журналу тран-
закцій і зчитує записані в ньому зміни, га-
рантуючи, що жодні зміни не пропуска-
ються або не втрачаються. Під час захоп-
лення змін з журналу транзакцій Debezium
запам’ятовує свою останню оброблену по-
дію, щоб у разі перезапуску або відмови си-
стеми, Debezium міг продовжити читати
події з того місця, де він зупинився, і про-
довжити читання змін без дублювання,
тобто не читати повторно одні й ті ж дані.
Цей механізм забезпечує цілісність даних
та запобігає втраті даних у разі будь-яких
збоїв або відмов.
Apache Kafka, брокер повідомлень,
який використовується разом з Debezium, та-
кож відіграє важливу роль у забезпеченні на-
дійності та стійкості даних. Він реплікує дані
на кількох брокерах у кластері, забезпечуючи
їхню обробку в разі відмов. Кожне повідом-
лення або подія, яка публікується в Kafka,
зберігається у сховищі, яке називається "то-
піками". Топіки розбиваються на частини, і
кожна частина реплікується на кількох бро-
керах. Цей механізм реплікації забезпечує
ситуацію, коли навіть у разі відмови деяких
брокерів або вузлів, дані все ще доступні і мо-
жуть споживатися користувачами.
Debezium використовує ці та інші
можливості надійності Kafka, публікуючи
отримані з таблиці outbox зміни подій в то-
піки Kafka. Після публікації Kafka відпові-
дає за забезпечення їхньої міцності та дос-
Агентно-орієнтовані інформаційні системи
71
тупності. Події можуть бути споживані
консьюмерами або оброблені іншими за-
стосунками.
6. Spring Boot Starter та його
роль в реалізації транзакцій
Spring Boot Starter - є ключовою
складовою частиною фреймворку Spring
Boot, що надає спрощений спосіб налашту-
вання та запуску застосунків через об'єд-
нання залежностей та налаштувань для кон-
кретних функціональностей або компонен-
тів. Зазвичай Spring Boot Starter за замовчу-
ванням включає підібраний набір бібліотек,
класів автоконфігурації та налаштувань,
необхідних для включення певної функції
або інтеграції з певною технологією [14].
За допомогою Spring Boot Starter ро-
зробники можуть швидко додавати необ-
хідні можливості та функціонал до своїх за-
стосунків, не потребуючи ручного налаш-
тування залежностей або написання станда-
ртного коду. Ці стартери упаковують необ-
хідні залежності та конфігурацію, що до-
зволяє розробникам зосередитися на напи-
санні бізнес-логіки, а не гаяти час на склад-
нощі налаштування та інтеграції різних
компонентів.
Spring Boot Starter надає широкий
спектр функціоналу включно із підключен-
ням до баз даних, веб-розробкою, безпе-
кою, обміном повідомленнями, кешуван-
ням тощо. Кожен стартер дотримується пе-
вного підходу і надає послідовний спосіб
інтеграції пов'язаних технологій у застосу-
нки Spring Boot. На прикладі стартеру
"spring-boot-starter-web" можна побачити
залежності та конфігурації, необхідні для
розробки веб-застосунків з використанням
Spring MVC, який включає в себе цей стар-
тер. При доданні spring-boot-starter-web у
проєкт, автоматично імпортується кілька
інших залежностей, таких як:
• Spring MVC: основний компонент фрей-
мворку Spring для створення веб-застосун-
ків, що надає архітектуру MVC та обробляє
відображення маршрутів запитів, обробку
запитів та генерацію відповідей.
• Embedded Servlet Container: вбудований
контейнер сервлетів (наприклад, Tomcat,
Jetty або Undertow), що дозволяє запус-
кати веб-застосунки без потреби в зовніш-
ній конфігурації сервера.
• Spring Web: модуль, що надає додаткові
функції та утиліти для роботи з вебом,
включно із обробкою HTTP-запитів та ві-
дповідей, обробкою форм, зв'язуванням
даних, валідацією та обробкою помилок.
• Jackson JSON: бібліотека включена для
підтримки серіалізації та десеріалізації да-
них у форматі JSON (JavaScript Object
Notation). Вона дозволяє легко конверту-
вати об'єкти Java в JSON та навпаки.
Крім наданих стартерів, розробники
також можуть створювати власні стартери
для упакування уже використовуваних ком-
понентів або бібліотек, специфічних для їх-
ніх застосунків чи домену. Це сприяє моду-
льності коду, повторному використанню та
стандартизації в проєктах організації.
7. Методологія імплементації
транзакцій
Проаналізувавши проблематику тра-
нзакцій в РС, ми розробили власну методо-
логію імплементації транзакцій на базі па-
терну ТО та черг повідомлень, яка спрямо-
вана на їх вирішення з наголосом на забез-
печенні послідовності, консистентності та
надійності даних у множинних сервісах. На
рисунку 1 наведена структура запропонова-
ної методології на прикладі розробленої си-
стеми для предметної області – замовлень
товарів.
Рис. 1. Методологія імплементації
транзакцій
Нехай система замовлень реалізо-
вана у вигляді двох мікросервісів: Order
Service, що отримує замовлення товарів, та
Stock Service, який на базі цих замовлень
здійснює певні перевірки товару та інші ма-
Агентно-орієнтовані інформаційні системи
72
ніпуляції для успішного завершення життє-
вого циклу замовлення. Обидва мікросер-
віси реалізовані на Java. Вони використову-
ють Spring Boot Framework, JPA/Hibernate
для доступу до своїх баз даних, які реалізо-
вані на MySQL. Проте для нашої методоло-
гії немає чіткої прив’язки до бази даних чи
то фреймфорку, оскільки вона дозволяє ре-
алізацію з використанням різноманітних
технологій, зокрема, таких як: CDI,
PostgreSQL, WildFly та інших.
Сервіс замовлень надає простий
REST API для створення замовлень. Сервіс
складу за допомогою Apache Kafka отримує
події, експортовані сервісом замовлень та
створює відповідні записи у власній базі да-
них MySQL.
Для експортування подій у Apache
Kafka сервіс замовлень використовує розро-
блений Spring Boot Starter, що дбає про на-
лаштування таблиці outbox. Запис подій до
таблиці відбувається в межах тієї ж транзак-
ції, що і збереження замовлення в базі да-
них. Стартер самостійно дбає про моніто-
ринг та зчитування даних таблиці outbox,
використовуючи WAL, CDC, Debezium, та
публікацію зчитаних даних до Apache Kafka.
Після зчитування подій з Apache
Kafka, сток сервіс сповіщає про вдале або
провальне зчитування та обробку даних,
використовуючи Apache Kafka. Ці події пі-
зніше сервіс замовлень читає та змінює ста-
тус замовлення з pending на closed /
canceled. Також цей сервіс дбає про відмо-
востійкість завдяки повторному читанню
даних, гарантує обробку даних та відповідь
у вигляді публікації статусу обробки у від-
повідний топік в Apache Kafka.
Дотримуючись цієї методології,
можна забезпечити надійний обмін да-
ними між мікросервісами, обробку опера-
цій у межах транзакції та відповідних по-
дій, відправлених іншим сервісам, атома-
рно та послідовно. Навіть у разі виник-
нення проблеми під час надсилання подій,
їх можна спробувати повторно відпра-
вити, або відтворити з таблиці outbox, за-
безпечуючи потрібну послідовність в РС.
Цим можна скористатися і для збере-
ження цілісності та послідовності даних,
одночасно дозволяючи асинхронну кому-
нікацію між сервісами.
8. Практична реалізація
На основі запропонованої методоло-
гії був розроблений Spring boot Starter, який
полегшує конфігурацію роботи з транзакці-
ями в РС, що публікують події як частину
транзакції. Він має вигляд спеціальної біб-
ліотеки для полегшення впровадження па-
терну Transactional Outbox в застосунок, по-
будований на основі Java. Основною метою
стартера є спрощення процесу збереження
та публікації подій у РС.
Стартер включає необхідні залежно-
сті та конфігурації, а також надає зручні ме-
тоди для збереження подій у відведеній таб-
лиці (outbox) і передачі їх у Debezium для
подальшого розповсюдження. Використо-
вуючи цей стартер, розробники можуть ефе-
ктивно впроваджувати патерн ТО, поклада-
ючись на потужність Debezium для зчиту-
вання та розповсюдження подій у РС, а та-
кож на гарантовану доставку та цілісність
даних за рахунок використання Apache
Kafka як базової технологій для Debezium.
Інтеграція застосунку зі стартером
розпочинається з його підключення у ви-
гляді залежності (Рис. 2.):
Рис. 2. Підключення стартеру до клі-
єнтського застосунку
Риc. 3. – Підключений стартер
Агентно-орієнтовані інформаційні системи
73
Рисунок 3 відображає доданий стар-
тер до застосунку. Для коректної роботи ста-
ртеру та підтримки роботи з outbox table та
Apache Kafka, необхідно передати наступні
конфігурації, що будуть зчитані стартером
під час ініціалізації проєкту. Сonnector.class -
вказує клас конектора, який використову-
ється для підключення до джерела даних (на-
приклад, значення конектор класу
io.debezium.connector.mysql.MySqlConnector,
означає підключення до MySQL бази даних).
database.hostname - вказує ім'я хоста, на
якому розташована база даних клієнта.
atabase.port – визначає порт, на якому до-
ступна база даних клієнта. database.user - уто-
чнює ім'я користувача для підключення до
бази даних клієнта. database.password - вказує
пароль для підключення до бази даних кліє-
нта. database.server.id - задає унікальний іден-
тифікатор сервера, який використовується
для розпізнавання транзакцій.
database.server.name - визначає унікальне ім'я
сервера, яке застосовується для ідентифікації
каналу змін даних у Debezium.
database.history.kafka.bootstrap.servers - вка-
зує адресу та порт сервера Apache Kafka,
який використовується для зберігання історії
змін бази даних (до прикладу “broker:9092”).
database.history.kafka.topic - уточнює тему
Kafka, де зберігається історія змін бази да-
них. key.converter.schema.registry.url: вказує
адресу та порт сервера реєстрації схем Avro.
value.converter.schema.registry.url - визначає
адресу та порт сервера реєстрації схем Avro.
Ці конфігурації мають бути надані у
yaml файлі й використовуються для налаш-
тування Debezium з метою підключення до
бази даних MySQL, зчитування змін у реа-
льному часі та перетворення їх на події, які
можна розповсюджувати через Apache
Kafka. Приклад конфігурації наведено на
рисунку 4.
Для керування підключенням чи від-
ключенням роботи стартера під час запуску
застосунку необхідно також задати зна-
чення true/false для конфігурацї
transactionaloutbox.enabled.
Для збереження подій до outbox
table, зчитування подій з outbox table та пу-
блікацію їх до Apache Kafka, необхідно до-
дати до методу сервісу анотацію
@WithTransactionalOutbox (рис.5).
Риc. 5. Використання анотації
WithTransactionalOutbox доданого стартера
В цьому прикладі стартер в межах
однієї транзакції зі збереженням замов-
лення до бази збереже подію до таблиці
outbox. Для реалізації такого функціоналу
стартер використовує можливості Spring, а
саме Spring AOP (рис.6).
Рис. 6. Spring AOP для реалізації ло-
гіки стартера
Застосувавши усі необхідні налаш-
тування стартера, можна інтегрувати засто-
Рис. 4. Приклад конфігурації стар-
тера в yaml файлі
Агентно-орієнтовані інформаційні системи
74
сунок із патерном ТО і таким чином забез-
печити атомарність операцій та консистен-
тність даних між різними сервісами. Більше
того, додаючи стартер до свого застосунку,
можна отримати ряд можливостей, які на-
даються технологіями Debezium та Apache
Kafka.
9. Рекомендації щодо
налаштування системи на базі
розробленої методології
Під час проектування та реалізації
РС, які використовують методологію імп-
лементації транзакцій, варто врахувати кі-
лька рекомендацій.
Насамперед, важливо перекона-
тися, що компоненти системи мають слабку
зв'язність та спілкуються за допомогою
асинхронного обміну повідомленнями для
розділення транзакційної обробки від зов-
нішніх сервісів. Такий підхід спілкування
сприяє стійкості та масштабованості [15-
16]. Не менш важливим є використання на-
дійного брокеру повідомлень для комуніка-
ції між мікросервісами та гарантованої на-
дійної доставки повідомлень. У ролі такого
брокеру можуть бути Kafka або RabbitMQ.
Однією з важливих компонент у ро-
зробці дистрибутивної системи є впрова-
дження механізмів обробки помилок та по-
вторного читання даних у разі помилок, уп-
равління відмовами та забезпечення конси-
стентності даних. Із цією метою можна ви-
користовувати механізми Retryable Topic та
Dead Letter Topic [17-18].
Також важливо належну увагу при-
ділити надійності консьюмерів [19]. Оскі-
льки консьюмери виконують обробку пові-
домлень із черги та виконують певні опера-
ції або змінюють стан системи на основі
цих повідомлень, важливо забезпечити,
щоб ці операції гарантували безпеку та на-
дійність системи, приводили обробку да-
них до однакового результату незалежно
від кількості повторних повідомлень. Це
важливо для забезпечення консистентності
даних та уникнення небажаних побічних
ефектів. Наприклад, якщо консьюмер ство-
рює запис у базі даних на основі отрима-
ного повідомлення, то необхідно гаранту-
вати, щоб у базі даних було створено тільки
один унікальний запис, навіть якщо повідо-
млення буде оброблено кілька разів. Також
важливим у проєктуванні консьюмерів є
використання унікальних ідентифікаторів
для оброблених повідомлень або збере-
ження стану процесу обробки, що забезпе-
чить ідемподентну обробку.
10. Тестування
Основними аспектами тестування
була перевірка вдалої інтеграції Debezium з
існуючими компонентами та технологіями
в системі. Це включило перевірку забезпе-
чення правильної конфігурації та налашту-
вання стартера, який базується на імплеме-
нтації ТО патерну. Також було оцінено ін-
теграцію з брокером повідомлень Kafka та
перевірено публікацію повідомлень до бро-
керу, наявність повторного читання даних
за необхідності.
На нашому прототипі були здійснені
перевірки поведінки системи у випадку на-
ступних сценаріїв виникнення помилки:
- у разі спроби збереження замов-
лення до клієнтської бази та перевірки сис-
теми на скасування публікації повідом-
лення;
- у разі публікації повідомлення до
брокера повідомлень та перевірки системи
на скасування збереження даних про замо-
влення до клієнтської бази;
- у разі повідомлення консьюмером
у сток сервісі та перевірки системи на по-
вторне читання з використанням retryable
механізму;
- після кількох невданих спроб обро-
бки повідомлень, коли консьюмер в сток
сервісі не може обробити повідомлення та
перевірити систему на відправку повідом-
лення до DLT топіку;
- після успішної обробки повідом-
лення сток сервіс відправив статус успіш-
ної обробки до відповідного топіку і сервіс
замовлень, базуючись на даній відповіді,
змінив статус замовлення на завершений;
- після неуспішної обробки повідо-
млення сток сервіс відправив статус про-
блеми обробки до відповідного топіку і
сервіс замовлень, базуючись на даній від-
повіді, змінив статус замовлення на скасо-
ваний.
Агентно-орієнтовані інформаційні системи
75
Як результат оцінювання система
коректно відпрацювала в обох успішних та
помилкових сценаріях. Варто зазначити,
що даний прототип має правильно налаш-
товані механізми повторної спроби читання
та обробки даних, оскільки у випадку вини-
кнення помилки, спроєктований механізм
повторної спроби автоматично повторював
операцію, для подолання тимчасових про-
блем, таких як проблеми з мережею або
тимчасова недоступність ресурсів. Повто-
рні спроби обробки виконувались із вико-
ристанням стратегій публікацій подій до
DLT топіку, щоб уникнути перевантаження
системи та забезпечити затримку між пос-
лідовними спробами.
Висновки
У процесі аналізу сучасних підходів
та рішень для роботи з транзакціями в РСах
було виявлено, що одним із ефективних рі-
шень є використання патерну Transactional
outbox. Він дозволяє зберігати події, пов'я-
зані з транзакціями, в окремій таблиці, що
уможливлює їхню подальшу інтеграцію з
іншими сервісами через застосунки або ме-
ханізми, як-от, через брокер повідомлень
Apache Kafka.
Проведений аналіз дозволив розро-
бити методологію імплементації транзак-
цій в РС, а також створити стартер для по-
легшення такої роботи з розподіленими
транзакціями та публікацією подій, що є ча-
стинами транзакції в чергу повідомлень.
Цей стартер надає зручний і стандартизова-
ний спосіб інтеграції патерну ТО в Spring
Boot застосунки, забезпечуючи автомати-
чне керування транзакціями та публікацію
подій.
Оцінювання прототипу показало
ефективність впровадження даного підходу
в РС. Розроблена методологія та стартер
можуть допомогти забезпечити надійну об-
робку розподілених транзакцій та публіка-
цію подій.
Література
1. Maarten van Steen, Andrew S. Tanenbaum.
"A brief introduction to distributed systems."
Web. 2016. https://www.distributed-
systems.net/my-
data/papers/2016.computing.pdf
2. Fowler M. Microservices [Електронний ре-
сурс] / M. Fowler, J. Lewis. – 2014. – Режим
доступу до ресурсу:
https://martinfowler.com/articles/microservice
s.html.
3. Яшина О.М., Кравчук О.А. Дослідження мі-
кросервісної архітектури, архітектурний
стиль REST та їх сучасна реалізація на Java.
Вісник ХНУ: технічні науки, Номер: №5,
2020, с. 106-114.
4. Trzaska, Mariusz. “Technical challenges of
creating an IT system in microservices archi-
tectural style using cloud services” Web. 2022
https://users.pja.edu.pl/~mtrzaska/Files/Prace
Magisterskie/220217-Grabowski.pdf
5. Newman S. Monolith To Microservices / Sam
Newman., 2019. – 301 с. – (2).
6. Fowler, Martin. “How to break a Monolith into
Microservices” Web. 2018
https://martinfowler.com/articles/break-
monolith-into-microservices.html
7. Richardson C. Microservices Patterns With
examples in Java / Chris Richardson., 2018. –
520 с.
8. Fowler, Martin “Two Phase Commit” Web.
https://martinfowler.com/articles/patterns-of-
distributed-systems/two-phase-commit.html
9. Transactional Outbox Pattern
https://www.linkedin.com/pulse/transactional-
outbox-pattern-distributed-pratik-pandey
(дата звернення 08.07.23)
10. Chola, Abhinal “Understanding Write Ahead
Logging: 4 Comprehensive Aspects” Web.
https://hevodata.com/learn/write-ahead-
logging/
11. Spring Blog. “Case Study: Change Data
Capture (CDC) Analysis with CDC Debezium
source and Analytics sink in Real-Time” Web.
https://spring.io/blog/2020/12/14/case-study-
change-data-capture-cdc-analysis-with-cdc-
debezium-source-and-analytics-sink-in-real-
time
12. Debezium Documentation. Web.
https://debezium.io/documentation/reference/s
table/index.html
13. Hevodata. “3 Easy Steps to Decode CDC
Using Debezium Spring Boot” Web.
https://hevodata.com/learn/debezium-spring-
boot/
14. Spring Boot Starters documentation. Web
https://docs.spring.io/spring-
boot/docs/current/reference/htmlsingle/#using
.build-systems.starters
Агентно-орієнтовані інформаційні системи
76
15. Rajabi M. How to Avoid Coupling in
Microservices Design [Електронний ресурс]
/ Mariam Rajabi. – 2020. – URL:
https://www.capitalone.com/tech/softwareeng
ineering/how-to-avoid-loose-coupled-
microservices/. (дата звернення 15.09.21)
16. Walpita P. Coupling and Cohesion in
Microservices [Електронний ресурс] / Priyal
Walpita. – 2020. – URL:
https://priyalwalpita.medium.com/coupling-
and-cohesion-inmicroservices-235ed9203843.
(дата звернення 18.09.21)
17. Baeldung Blog “Implementing Retry in Kafka
Consumer” Web.
https://www.baeldung.com/spring-retry-
kafka-consumer
18. Medium. “Dead Letter Queue (DLQ) in
Kafka” Web.
https://towardsdatascience.com/dead-letter-
queue-dlq-in-kafka-29418e0ec6cf
19. Richardson, Chris. “Pattern: Idempotent
Consumer” Web.
https://microservices.io/patterns/communicati
on-style/idempotent-consumer.html
Одержано: 01.02.2024
Про авторів:
Глибовець Андрій Миколайович,
доктор технічних наук, професор,
декан факультету інформатики
Національного університету
«Києво-Могилянська академія».
Кількість наукових публікацій
в українських виданнях – понад 40.
Кількість наукових публікацій
в зарубіжних виданнях – 8.
Індекс Хірша – 3.
https://orcid.org/0000-0003-4282-481X,
Глибовець Микола Миколайович,
доктор фізико-математичних наук,
професор факультету інформатики
Національного університету
«Києво-Могилянська академія».
Кількість наукових публікацій
в українських виданнях – понад 200.
Кількість наукових публікацій
в зарубіжних виданнях – більше 10.
Індекс Хірша – 12, https://orcid.org/0000-
0002-3853-2171
Чернова Тетяна Андріївна,
магістр факультету інформатики
Національного університету
«Києво-Могилянська академія»
Місце роботи авторів:
Національний університет
«Києво-Могилянська академія»,
04070, м. Київ, вул. Сковороди 2.
E-mail: a.glybovets@ukma.edu.ua,
glib@ukma.edu.ua, t.chernova@ukma.edu.ua
|