Модел Saga: Внедряване на разпределени трансакции за микроуслуги

В света на микроуслугите поддържането на консистентност на данните в множество услуги може да бъде значително предизвикателство. Традиционните ACID (Атомарност, Консистентност, Изолация, Устойчивост) трансакции, често използвани в монолитни приложения, обикновено са неподходящи за разпределени среди. Тук се намесва моделът Saga, който предоставя стабилно решение за управление на разпределени трансакции и гарантиране на целостта на данните в различните микроуслуги.

Какво представлява моделът Saga?

Моделът Saga е модел на проектиране, използван за управление на поредица от локални трансакции в множество микроуслуги. Той предоставя начин за постигане на евентуална консистентност, което означава, че докато данните може да са временно неконсистентни, те в крайна сметка ще се сближат до консистентно състояние. Вместо да разчита на една-единствена, атомарна трансакция, обхващаща множество услуги, моделът Saga разделя трансакцията на поредица от по-малки, независими трансакции, всяка от които се извършва от една услуга.

Всяка локална трансакция в рамките на Saga актуализира базата данни на една микроуслуга. Ако една от трансакциите се провали, Saga изпълнява поредица от компенсиращи трансакции, за да отмени промените, направени от предходните трансакции, като по този начин ефективно връща назад цялостната операция.

Защо да използваме модела Saga?

Няколко фактора правят модела Saga ценен инструмент за управление на трансакции в архитектури с микроуслуги:

• Слаба обвързаност (Decoupling): Моделите Saga насърчават слабата обвързаност между микроуслугите, позволявайки им да се развиват независимо, без да засягат други услуги. Това е ключово предимство на архитектурите с микроуслуги.
• Мащабируемост: Като избягват дълготрайни, разпределени трансакции, моделите Saga подобряват мащабируемостта и производителността. Всяка микроуслуга може да обработва собствените си трансакции независимо, намалявайки конфликтите и подобрявайки пропускателната способност.
• Устойчивост: Моделите Saga са проектирани да бъдат устойчиви на повреди. Ако дадена трансакция се провали, Saga може да бъде върната назад, предотвратявайки неконсистентност на данните и гарантирайки, че системата остава в консистентно състояние.
• Гъвкавост: Моделът Saga осигурява гъвкавост при управлението на сложни бизнес процеси, обхващащи множество услуги. Той ви позволява да дефинирате последователността на трансакциите и компенсиращите действия, които да се предприемат в случай на повреда.

ACID срещу BASE

Разбирането на разликата между ACID и BASE (Basically Available, Soft state, Eventually consistent) е от решаващо значение при вземането на решение дали да се използва моделът Saga.

• ACID (Атомарност, Консистентност, Изолация, Устойчивост): Гарантира, че трансакциите се обработват надеждно. Атомарността гарантира, че или всички операции в рамките на една трансакция успяват, или нито една. Консистентността гарантира, че трансакцията преобразува базата данни от едно валидно състояние в друго. Изолацията гарантира, че едновременните трансакции не си пречат взаимно. Устойчивостта гарантира, че след като една трансакция бъде потвърдена, тя остава такава дори в случай на системна повреда.
• BASE (Основно достъпна, Гъвкаво състояние, Евентуална консистентност): Това е различен подход, предназначен за разпределени системи. Основно достъпна означава, че системата е налична през повечето време. Гъвкаво състояние означава, че състоянието на системата може да се променя с течение на времето, дори без въвеждане на данни. Евентуална консистентност означава, че системата в крайна сметка ще стане консистентна, след като спре да получава входни данни. Моделът Saga е в съответствие с принципите на BASE.

Две основни стратегии за внедряване на Saga

Има два основни начина за внедряване на модела Saga: Хореография и Оркестрация.

1. Saga, базирана на хореография

В Saga, базирана на хореография, всяка микроуслуга участва в Saga, като слуша за събития, публикувани от други микроуслуги, и реагира съответно. Няма централен оркестратор; всяка услуга знае своите отговорности и кога да извърши своите действия.

Как работи:

1. Saga започва, когато микроуслуга публикува събитие, указващо началото на трансакцията.
2. Други микроуслуги се абонират за това събитие и след като го получат, извършват своята локална трансакция.
3. След като завършат своята трансакция, всяка микроуслуга публикува друго събитие, указващо успеха или провала на операцията си.
4. Други микроуслуги слушат за тези събития и предприемат подходящи действия, като или продължават към следващата стъпка в Saga, или инициират компенсиращи трансакции, ако възникне грешка.

Пример: Поставяне на поръчка в електронна търговия (Хореография)

1. Услуга за поръчки: Получава заявка за нова поръчка и публикува събитие `OrderCreated`.
2. Услуга за инвентар: Абонира се за `OrderCreated`. При получаване на събитието, тя проверява наличността. Ако е достатъчна, резервира артикулите и публикува `InventoryReserved`. Ако е недостатъчна, публикува `InventoryReservationFailed`.
3. Услуга за плащания: Абонира се за `InventoryReserved`. При получаване на събитието, тя обработва плащането. Ако е успешно, публикува `PaymentProcessed`. Ако се провали, публикува `PaymentFailed`.
4. Услуга за доставка: Абонира се за `PaymentProcessed`. При получаване на събитието, тя подготвя пратката и публикува `ShipmentPrepared`.
5. Услуга за поръчки: Абонира се за `ShipmentPrepared`. При получаване на събитието, тя маркира поръчката като завършена.
6. Компенсация: Ако бъде публикувано `PaymentFailed` или `InventoryReservationFailed`, другите услуги слушат и извършват компенсиращи трансакции (напр. освобождаване на резервирания инвентар).

Предимства на хореографията:

• Простота: По-лесна за внедряване при прости работни процеси.
• Децентрализация: Насърчава слабата обвързаност и независимото развитие на микроуслугите.

Недостатъци на хореографията:

• Сложност: Може да стане сложна за управление с увеличаване на броя на участниците в Saga.
• Видимост: Трудно е да се проследи общият напредък и състоянието на Saga.
• Обвързаност: Въпреки че насърчава слабата обвързаност, услугите все още трябва да са наясно със събитията, публикувани от други услуги.

2. Saga, базирана на оркестрация

В Saga, базирана на оркестрация, централен оркестратор (често реализиран като специализирана услуга или машина на състоянията) управлява Saga и координира изпълнението на локални трансакции от участващите микроуслуги. Оркестраторът казва на всяка услуга какво да прави и кога да го прави.

Как работи:

1. Saga започва, когато клиент поиска от оркестратора да инициира трансакцията.
2. Оркестраторът изпраща команди до участващите микроуслуги да извършат своите локални трансакции.
3. Всяка микроуслуга извършва своята трансакция и уведомява оркестратора за успеха или провала.
4. Въз основа на резултата, оркестраторът решава дали да продължи към следващата стъпка или да инициира компенсиращи трансакции.

Пример: Поставяне на поръчка в електронна търговия (Оркестрация)

1. Оркестратор на поръчки: Получава заявка за нова поръчка.
2. Оркестратор на поръчки: Изпраща команда до Услугата за инвентар да резервира артикули.
3. Услуга за инвентар: Резервира артикулите и уведомява Оркестратора на поръчки.
4. Оркестратор на поръчки: Изпраща команда до Услугата за плащания да обработи плащането.
5. Услуга за плащания: Обработва плащането и уведомява Оркестратора на поръчки.
6. Оркестратор на поръчки: Изпраща команда до Услугата за доставка да подготви пратката.
7. Услуга за доставка: Подготвя пратката и уведомява Оркестратора на поръчки.
8. Оркестратор на поръчки: Маркира поръчката като завършена.
9. Компенсация: Ако някоя стъпка се провали, Оркестраторът на поръчки изпраща компенсиращи команди до съответните услуги (напр. освобождаване на резервирания инвентар).

Предимства на оркестрацията:

• Централизиран контрол: По-лесно управление и наблюдение на Saga от централна точка.
• Подобрена видимост: Оркестраторът предоставя ясен поглед върху общия напредък и състоянието на Saga.
• Намалена обвързаност: Микроуслугите трябва да комуникират само с оркестратора, което намалява преките зависимости между тях.

Недостатъци на оркестрацията:

• Сложност: Може да бъде по-сложна за първоначално внедряване, особено при прости работни процеси.
• Единична точка на отказ: Оркестраторът може да се превърне в единична точка на отказ, въпреки че това може да бъде смекчено с мерки за резервираност и отказоустойчивост.

Внедряване на компенсиращи трансакции

Ключов аспект на модела Saga е внедряването на компенсиращи трансакции. Тези трансакции се изпълняват, за да отменят ефектите от предварително завършени трансакции в случай на повреда. Целта е системата да се върне в консистентно състояние, дори ако цялостната Saga не може да бъде завършена.

Ключови съображения за компенсиращи трансакции:

• Идемпотентност: Компенсиращите трансакции трябва да бъдат идемпотентни, което означава, че могат да бъдат изпълнявани многократно без да променят резултата. Това е важно, защото повреди могат да възникнат във всеки един момент и компенсиращата трансакция може да бъде повторена.
• Обработка на повреди: Компенсиращите трансакции също могат да се провалят. Трябва да имате стратегия за обработка на повреди в компенсиращите трансакции, като например повторни опити, регистриране на грешки и уведомяване на администраторите.
• Консистентност на данните: Компенсиращите трансакции трябва да гарантират, че данните остават консистентни. Това може да включва възстановяване на данните до предишното им състояние, изтриване на новосъздадени данни или актуализиране на данни, за да се отрази отмяната на трансакцията.

Примери за компенсиращи трансакции:

• Услуга за инвентар: Ако Услугата за инвентар е резервирала артикули, но плащането е неуспешно, компенсиращата трансакция ще бъде да освободи резервираните артикули.
• Услуга за плащания: Ако Услугата за плащания е обработила плащане, но доставката е неуспешна, компенсиращата трансакция може да включва възстановяване на сумата.

Предизвикателства и съображения

Въпреки че моделът Saga предлага значителни предимства, той също така поставя някои предизвикателства и съображения:

• Сложност: Внедряването на модела Saga може да бъде сложно, особено при заплетени бизнес процеси. Необходимо е внимателно планиране и проектиране.
• Евентуална консистентност: Моделът Saga осигурява евентуална консистентност, което означава, че данните може да са временно неконсистентни. Това може да бъде проблем за приложения, които изискват силни гаранции за консистентност.
• Тестване: Тестването на моделите Saga може да бъде предизвикателство поради тяхната разпределена природа и потенциала за повреди в различни точки.
• Наблюдение: Наблюдението на напредъка и състоянието на моделите Saga е от решаващо значение за идентифициране и разрешаване на проблеми. Трябва да имате подходящи инструменти и процеси за наблюдение.
• Идемпотентност: Гарантирането, че трансакциите и компенсиращите трансакции са идемпотентни, е от решаващо значение за предотвратяване на неконсистентност на данните.
• Изолация: Тъй като моделите Saga включват множество локални трансакции, изолацията може да бъде проблем. Може да са необходими стратегии като семантични заключвания или оптимистично заключване.

Случаи на употреба и примери

Моделът Saga е много подходящ за различни случаи на употреба, особено в разпределени системи и архитектури с микроуслуги. Ето някои често срещани примери:

• Управление на поръчки в електронната търговия: Както е илюстрирано в примерите по-горе, моделът Saga може да се използва за управление на целия жизнен цикъл на поръчката, от създаването на поръчката до обработката на плащането и доставката.
• Финансови трансакции: Моделът Saga може да се използва за управление на сложни финансови трансакции, които включват множество системи, като преводи на средства, заявления за заем и застрахователни искове.
• Управление на веригата за доставки: Моделът Saga може да се използва за координиране на дейности между множество субекти във веригата за доставки, като производители, дистрибутори и търговци на дребно.
• Здравни системи: Моделът Saga може да се използва за управление на пациентски досиета и координиране на грижите между различни отделения и доставчици на услуги.

Пример: Глобална банкова трансакция

Представете си сценарий, включващ глобална банкова трансакция между две различни банки, намиращи се в различни държави, подложени на различни регулации и проверки за съответствие. Моделът Saga може да гарантира, че трансакцията следва определените стъпки:

1. Иницииране на трансакция: Клиентът инициира превод на средства от сметката си в Банка А (намираща се в САЩ) към сметката на получател в Банка Б (намираща се в Германия).
2. Банка А - Валидиране на сметка: Банка А валидира сметката на клиента, проверява за достатъчни средства и гарантира, че няма задържания или ограничения.
3. Проверка за съответствие (Банка А): Банка А извършва проверка за съответствие, за да гарантира, че трансакцията не нарушава регулациите за борба с прането на пари (AML) или други международни санкции.
4. Превод на средства (Банка А): Банка А дебитира сметката на клиента и изпраща средствата към клирингова къща или посредническа банка.
5. Обработка в клирингова къща: Клиринговата къща обработва трансакцията, извършва обмяна на валута (USD в EUR) и насочва средствата към Банка Б.
6. Банка Б - Валидиране на сметка: Банка Б валидира сметката на получателя и гарантира, че тя е активна и може да получава средства.
7. Проверка за съответствие (Банка Б): Банка Б извършва собствена проверка за съответствие, спазвайки германските и европейските регулации.
8. Заверяване на сметка (Банка Б): Банка Б заверява сметката на получателя.
9. Потвърждение: Банка Б изпраща съобщение за потвърждение до Банка А, която след това уведомява клиента, че трансакцията е завършена.

Компенсиращи трансакции:

• Ако проверката за съответствие в Банка А се провали, трансакцията се анулира и сметката на клиента не се дебитира.
• Ако проверката за съответствие в Банка Б се провали, средствата се връщат в Банка А и сметката на клиента се заверява обратно.
• Ако има проблеми с обмяната на валута или маршрутизирането в клиринговата къща, трансакцията се обръща и средствата се връщат в Банка А.

Инструменти и технологии

Няколко инструмента и технологии могат да помогнат при внедряването на модела Saga:

• Опашки за съобщения: Apache Kafka, RabbitMQ и Amazon SQS могат да се използват за публикуване и абониране за събития в Saga, базирана на хореография.
• Системи за управление на работни процеси: Camunda, Zeebe и Apache Airflow могат да се използват за внедряване на оркестратори и управление на сложни работни процеси.
• Извличане на събития (Event Sourcing): Извличането на събития може да се използва за проследяване на историята на събитията в Saga и улесняване на връщането назад в случай на повреда.
• Мениджъри на разпределени трансакции: Някои мениджъри на разпределени трансакции, като Atomikos, могат да се използват за координиране на трансакции между множество услуги. Въпреки това, те може да не са подходящи за всички архитектури с микроуслуги поради присъщите им ограничения в разпределени среди.
• Saga Frameworks: Съществуват и рамки (frameworks) за Saga, които предоставят абстракции и инструменти за внедряване на модела Saga.

Най-добри практики за внедряване на модела Saga

За ефективно внедряване на модела Saga, вземете предвид следните най-добри практики:

• Внимателно проектиране: Анализирайте обстойно вашите бизнес изисквания и проектирайте Saga съответно. Идентифицирайте участващите микроуслуги, последователността на трансакциите и компенсиращите действия.
• Идемпотентност: Уверете се, че всички трансакции и компенсиращи трансакции са идемпотентни.
• Обработка на грешки: Внедрете стабилни механизми за обработка на грешки, за да се справите с повреди във всяка точка на Saga.
• Наблюдение и регистриране: Внедрете цялостно наблюдение и регистриране, за да проследявате напредъка и състоянието на моделите Saga.
• Тестване: Тествайте обстойно вашите модели Saga, за да се уверите, че функционират правилно и обработват повредите грациозно.
• Семантични заключвания: Внедрете семантични заключвания, за да предотвратите едновременни актуализации на едни и същи данни от различни модели Saga.
• Оптимистично заключване: Използвайте оптимистично заключване, за да откривате и предотвратявате конфликти между едновременни трансакции.
• Изберете правилната стратегия за внедряване: Внимателно обмислете компромисите между хореография и оркестрация и изберете стратегията, която най-добре отговаря на вашите нужди.
• Определете ясни политики за компенсация: Установете ясни политики за обработка на компенсации, включително условията, при които се задейства компенсация, и конкретните действия, които трябва да се предприемат.

Заключение

Моделът Saga е мощен инструмент за управление на разпределени трансакции в архитектури с микроуслуги. Чрез разделяне на трансакциите на поредица от по-малки, независими трансакции и предоставяне на механизъм за компенсиране на повреди, моделът Saga ви позволява да поддържате консистентност на данните и да изграждате устойчиви, мащабируеми и слабо обвързани системи. Въпреки че моделът Saga може да бъде сложен за внедряване, предимствата, които предлага по отношение на гъвкавост, мащабируемост и устойчивост, го правят ценен актив за всяка архитектура с микроуслуги.

Разбирането на нюансите на модела Saga, компромисите между хореография и оркестрация и значението на компенсиращите трансакции ще ви даде възможност да проектирате и внедрявате стабилни разпределени системи, които отговарят на изискванията на днешните сложни бизнес среди. Възприемането на модела Saga е стъпка към изграждането на наистина устойчиви и мащабируеми архитектури с микроуслуги, способни да се справят с увереност дори с най-сложните разпределени трансакции. Не забравяйте да вземете предвид вашите специфични нужди и контекст, когато прилагате този модел, и непрекъснато усъвършенствайте вашето внедряване въз основа на реален опит и обратна връзка.