Самый важный паттерн МСА на примере неудавшегося отпуска
Представь, ты собрался в отпуск – забронировал авиабилеты, отель и даже экскурсию. Ты молодец - все спланировал заранее и теперь не нужно париться🌴
Но что-то пошло не так, и ты вынужден все отменить, то есть вернуть деньги за авиабилеты, отель и экскурсию. В идеале баланс на банковском счете не изменится, а в отпуск в следующий раз
🔹 Локальные транзакции
В примере оформление отпуска, авиабилеты, отель и экскурсии – это локальные транзакции. Каждая завершенная локальная транзакция инициирует запуск следующей. Их последовательность образует бизнес-процесс, т.е. весь отпуск
В системах несколько сервисов могут участвовать в одном бизнес-процессе, и под локальной транзакцией понимают изменение в БД или публикацию события
Например, в Uber 🚕 нужно создать заказ, назначить водителя, запустить поездку и обработать оплату
🔹 Компенсирующие транзакции
В нашем примере отпуск сорвался, но мы еще можем спасти деньги. То есть вернуться к состоянию до начала планирования, компенсировать затраты. В нашем примере это возврат денег за авиабилет и отель
В Saga это действие называется компенсирующими транзакциями – операции, которые отменяют или корректируют эффект предыдущих шагов, чтобы система осталась согласованной
Например, в Uber Saga координирует цепочку: принятие заказа → назначение водителя → поездка → оплата. Если водитель отменит заказ, система компенсирует изменения (вернет заказ в очередь)
🔹 Поворотные транзакции
А теперь представим, что с отпуском все хорошо. Какое самое важное действие? Прилететь и пройти таможню. Отель можно поменять, а экскурсии отменить – однако деньги за билет уже не вернешь
В системах подобные транзакции называются поворотными. После поворотной транзакции полная компенсация невозможна (только частичная)
В примере с Uber поворотная транзакции – начало поездки. До этого момента заказ можно отменить без штрафа, после компенсация будет частичная (например, пассажир получит штраф 🤑)
🔹 Координация транзакций
Два способа координации транзакциями в системах:
1. Хореография
2. Оркестровка
При хореографии сервисы обмениваются событиями (например, через Kafka), и каждый решает, как реагировать. Это как если бы самостоятельно планировали отпуск – забронировали авиабилеты, получили событие в мозг, пошли бронировать отель (не обязательно сразу)
При оркестровке есть некий участник-оркестратор, который говорит сервисам, какие транзакции должны быть запущены. Он же, в случае сигнала «Галя, отмена», запускает компенсирующие транзакции. Это как если бы мы планировали отпуск через тур-оператора, который сам бронирует авиабилеты, отели и экскурсии
📌 Кратко о важном
– Saga – шаблон для обеспечения согласованности в рамках одного бизнес-процесса
– Локальная транзакция – действия в рамках одного сервиса
– Компенсирующая транзакция – операция для отката изменений
– Поворотная транзакция – операция, после которой полный откат невозможен (только частичный)
– Два способа координации транзакция: хореография и оркестровка
————
Теперь яснее, как мы обеспечиваем согласованность данных в микросервисах?
👍 Да, гораздо
🤔 Нужно разобраться
P.S. Пока писал пост, увидел новый конкурс авторских ТГ-каналов. На этот раз от ребят из System Education, куда мой канал вписывается куда лучше, чем в предыдущем конкурсе
В этом конкурсе несколько номинаций. Думаю, этот пост отлично вписывается в «Ясное объяснение». Оставлю пометку, что участвую в конкурсе от @systems_education
#полезное_системный_анализ
#продолжи_мысль_SE
Представь, ты собрался в отпуск – забронировал авиабилеты, отель и даже экскурсию. Ты молодец - все спланировал заранее и теперь не нужно париться🌴
Но что-то пошло не так, и ты вынужден все отменить, то есть вернуть деньги за авиабилеты, отель и экскурсию. В идеале баланс на банковском счете не изменится, а в отпуск в следующий раз
Шаблон «Saga» (или «Повествование») – шаблон, обеспечивающий согласованность данных в микросервисной архитектуре в конечном счете. То есть, если бизнес-процесс затрагивает три сервиса, то после его выполнения данные должны быть актуальными и правильными
🔹 Локальные транзакции
В примере оформление отпуска, авиабилеты, отель и экскурсии – это локальные транзакции. Каждая завершенная локальная транзакция инициирует запуск следующей. Их последовательность образует бизнес-процесс, т.е. весь отпуск
В системах несколько сервисов могут участвовать в одном бизнес-процессе, и под локальной транзакцией понимают изменение в БД или публикацию события
Например, в Uber 🚕 нужно создать заказ, назначить водителя, запустить поездку и обработать оплату
🔹 Компенсирующие транзакции
В нашем примере отпуск сорвался, но мы еще можем спасти деньги. То есть вернуться к состоянию до начала планирования, компенсировать затраты. В нашем примере это возврат денег за авиабилет и отель
В Saga это действие называется компенсирующими транзакциями – операции, которые отменяют или корректируют эффект предыдущих шагов, чтобы система осталась согласованной
Например, в Uber Saga координирует цепочку: принятие заказа → назначение водителя → поездка → оплата. Если водитель отменит заказ, система компенсирует изменения (вернет заказ в очередь)
🔹 Поворотные транзакции
А теперь представим, что с отпуском все хорошо. Какое самое важное действие? Прилететь и пройти таможню. Отель можно поменять, а экскурсии отменить – однако деньги за билет уже не вернешь
В системах подобные транзакции называются поворотными. После поворотной транзакции полная компенсация невозможна (только частичная)
В примере с Uber поворотная транзакции – начало поездки. До этого момента заказ можно отменить без штрафа, после компенсация будет частичная (например, пассажир получит штраф 🤑)
🔹 Координация транзакций
Два способа координации транзакциями в системах:
1. Хореография
2. Оркестровка
При хореографии сервисы обмениваются событиями (например, через Kafka), и каждый решает, как реагировать. Это как если бы самостоятельно планировали отпуск – забронировали авиабилеты, получили событие в мозг, пошли бронировать отель (не обязательно сразу)
При оркестровке есть некий участник-оркестратор, который говорит сервисам, какие транзакции должны быть запущены. Он же, в случае сигнала «Галя, отмена», запускает компенсирующие транзакции. Это как если бы мы планировали отпуск через тур-оператора, который сам бронирует авиабилеты, отели и экскурсии
📌 Кратко о важном
– Saga – шаблон для обеспечения согласованности в рамках одного бизнес-процесса
– Локальная транзакция – действия в рамках одного сервиса
– Компенсирующая транзакция – операция для отката изменений
– Поворотная транзакция – операция, после которой полный откат невозможен (только частичный)
– Два способа координации транзакция: хореография и оркестровка
В итоге Saga – это не про идеальный сценарий, а про то, как грамотно откатиться при ошибках и поддержать данные в целостности
————
Теперь яснее, как мы обеспечиваем согласованность данных в микросервисах?
👍 Да, гораздо
🤔 Нужно разобраться
P.S. Пока писал пост, увидел новый конкурс авторских ТГ-каналов. На этот раз от ребят из System Education, куда мой канал вписывается куда лучше, чем в предыдущем конкурсе
В этом конкурсе несколько номинаций. Думаю, этот пост отлично вписывается в «Ясное объяснение». Оставлю пометку, что участвую в конкурсе от @systems_education
#полезное_системный_анализ
#продолжи_мысль_SE