Microservices & Data Concistency
При використанні мікросервісної архітектури "гостро" постає питання відповідності даних. Так, оскільки при такій архітектурі неможливо використовувати ACID (через те що бізнес операція може складатися з багатьох бізнес моделей, які належать різним сервісам), то можливими варіантами є двохфазний коміт (2PC) та обмін подіями (event sourcing).
Двохфазний коміт (відомий також як XA-Transaction) полягає в синхронізації збереження даний між багатьма базами даних в розподіленій системі.
2PC складається з підготовчої фази та фази коміту. Підготовча фаза відбувається в момент, коли база даних лідер бажає внести зміни. Лідер надсилає запит усьому кластеру з питанням чи можуть вони закомітити наступні зміни. Якщо усі учасники підтвердили можливість коміту, лідер переходить до фази коміту.
Як можна розуміти з опису, такий архітектурний підхід має багато недоліків, серед яких затримки мережі, вимога консенсусу.
Обмін подіями дає нам більшу гнучкість. Так ми можено застосовувати ACID транзакції, оскільки кожен сервіс вілповідає лише за одну базу даних, та надіслати подію іншим сервісам (subscribers).
Основним недоліком такого підходу є збереження послідовності бізнес-логіки. Так наприклад, сервіс може надіслати подію, а зміни не будуть закомічені в власну базу даних. У таких випадках бажаною є наступна архітектура:
Як зображено на схемі сервіс вносить зміни в базу даних, а процес В опрацьовує ці зміни та повідомляє про них інші сервіси, вносячи повідомлення в шину.
Можливі два типи взаємодії:
Другий підхід є більш загальним та вимагає лише створення додаткової таблиці подій, де сервіс буде зберігати нові події, я процес оброблятиме їх.
Source: Base. An Acid Alternative
Двохфазний коміт (відомий також як XA-Transaction) полягає в синхронізації збереження даний між багатьма базами даних в розподіленій системі.
2PC складається з підготовчої фази та фази коміту. Підготовча фаза відбувається в момент, коли база даних лідер бажає внести зміни. Лідер надсилає запит усьому кластеру з питанням чи можуть вони закомітити наступні зміни. Якщо усі учасники підтвердили можливість коміту, лідер переходить до фази коміту.
Як можна розуміти з опису, такий архітектурний підхід має багато недоліків, серед яких затримки мережі, вимога консенсусу.
Обмін подіями дає нам більшу гнучкість. Так ми можено застосовувати ACID транзакції, оскільки кожен сервіс вілповідає лише за одну базу даних, та надіслати подію іншим сервісам (subscribers).
Основним недоліком такого підходу є збереження послідовності бізнес-логіки. Так наприклад, сервіс може надіслати подію, а зміни не будуть закомічені в власну базу даних. У таких випадках бажаною є наступна архітектура:
Як зображено на схемі сервіс вносить зміни в базу даних, а процес В опрацьовує ці зміни та повідомляє про них інші сервіси, вносячи повідомлення в шину.
Можливі два типи взаємодії:
- Процес читає лог файл бази даних.
- Процес читає дані з таблиці подій.
Другий підхід є більш загальним та вимагає лише створення додаткової таблиці подій, де сервіс буде зберігати нові події, я процес оброблятиме їх.
Source: Base. An Acid Alternative
Comments
Post a Comment