Разберём паттерн «Saga» на примере бронирования номеров в отеле, начиная с базового функционала и переходя к развитию системы с ростом пользователей.
Телеграм-канал спикера Антона Цитульского «Backend Notes»: t.me/backend_architecture
СМОТРИТЕ ТАКЖЕ:
• Основы применения нота...
• Как мы проектировали с...
• Как работает платёжный...
• Разработка требований ...
• Нефункциональные требо...
Таймкоды:
00:00 Начало
00:10 О спикере
01:15 Цели вебинар
01:54 Задача вебинар
02:17 План вебинар
02:48 Блок «Описание задачи бронирования номера в отеле»
02:54 Бронирование номера в отеле, базовый функционал
04:28 Блок Развитие системы с ростом пользователя
04:37 Задача на самом первом шаге: Level 0
06:08 Level 1
08:29 Level 2
10:22 Level 3
11:10 Level 80 (имеем огромную систему)
11:47 Блок «Масштабирование»
11:49 Используем горизонтальное масштабирование, обычный куб
13:18 Как выделить микросервисы
14:25 Блок «Паттерн Сага»
14:38 Разбираем терминологию блока
15:44 Сравниваем архитектуру одного сервиса и микросервисов
17:00 Определение паттерна Сага и его задач
17:56 Блок «Проектирование задачи с использованием паттерна Сага»
17:58 Бизнесфлоу процесса брони
19:33 Создание брони
20:10 Резервирование номера
20:37 Запрос платежа
21:22 Списание денег
22:10 Подтверждение брони
22:30 API: полученная система
23:20 Смотрим, что внутри black box
24:44 Какие бывают Саги: хореография и оркестрация
25:18 Угадываем: хореография или оркестрация
26:00 Разбор полученного типа Саги
27:35 Верхнеуровневая схема
29:02 Блок «Если платеж не прошел/Отель уже занят»
29:12 Компенсация
30:08 Блок «Вывод»
30:30 Подводим итог было/стало
31:00 Резюмируем по Саге: что это, в чем ее суть
32:26 Ссылки на материалы по вебинар
Q&A
33:17 Вопрос 1: Почему в примере выбрана оркестрация, а не хореография? Какие их плюсы и минусы?
34:05 Вопрос 2: Можно рассмотреть пример одновременного бронирования с удаленных геолокаций?
34:30 Вопрос 3: Какими средствами организуется Сага?
34:41 Вопрос 4: Есть ли готовые реализации?
35:02 Вопрос 5: Про бесплатную/опенсорс реализацию
35:23 Вопрос 6: Чем сейчас заменен AWS в России?
36:00 Вопрос 7: Между сервисом отелей и бронированием есть жесткая связь (id отеля). Если, допустим, мы хотим удалить отель, то как поступить с id в сервисе бронирования. Триггер через брокер на удаление этих броней?
36:38 Вопрос 8: Если вдруг сломается компенсирующая транзакция?
37:23 Вопрос 9: Какие лучше применять способы мониторинга за целостностью данных при таком подходе?
37:55 Вопрос 10: Какие есть альтернативы паттерну saga?
Материалы со слайда:
Идея - • Интервью по System Des...
БД - blog.bytebytego.com/p/underst...
БД - dbdb.io/
System Design - habr.com/ru/articles/698734/
Interview - / system-design-intervie...
NALSD - sre.google/workbook/non-abstr...
DEEP System Design - github.com/donnemartin/system...
____________________
ЧТО ЖЕ ТАКОЕ Saga Pattern?
Сага - это последовательность локальных операций (транзакций). Как правило, применяется сага в микросервисной архитектуре, когда у каждого микросервиса своя БД. Каждая локальная транзакция обновляет базу данных и публикует сообщение или событие для запуска следующей локальной транзакции в саге. Если локальная транзакция терпит неудачу из-за нарушения бизнес-правил и нужно её откатить назад, то сага выполняет серию компенсирующих транзакций, которые отменяют изменения, внесенные предыдущими локальными транзакциями. Можно сказать, что это способ обработки ошибок, не нарушающий консистентность данных.
Есть разные сценарии обработки ошибок - Retry (повторная отправка), Circuit Breaker (при отказе или длительной недоступности другого сервиса) и др. В вебинаре был рассмотрен конкретный сценарий, где по мере роста и увеличения нагрузки на приложение рассматривалось применение саги .
____________________
📌 ПОДПИСАТЬСЯ НА Systems Education:
➛VK ssa.io/SStfuk
➛RU-vid: ssa.io/TlNXWE
➛Telegram - Новости Systems Education и расписание курсов t.me/systems_education
➛Telegram - Анонсы событий по системному анализу: t.me/itsysdes_events
➛Telegram - Как стать системным аналитиком: t.me/kak_stat_SA
18 июн 2024
