Знаете, чем мне понравился собес в Сбере? Тем, что не было дебильных и заезженных вопросов из серии "Чем REST отличается от SOAP." 😃
Всё шло хорошо, пока мы не дошли до обсуждения архитектуры, где меня поймали за руку, как дешёвку, спросив, как работают транзакции в микросервисах 😨
Я не знала, как отвечать, поэтому первые несколько секунд сидела с каменным €bal’ником, как актерская игра Кристен Стюарт.
А этот вопрос, между прочим, отличный, учитывая, что сейчас микросервисы в тренде, и всё больше компаний, особенно, бигтех, либо начали переход на MSA, либо уже давно внедрили этот подход в свои продукты 💥🟢
❔ Я не буду сейчас детально расписывать ответ на вопрос, потому что тема распределенных транзакций слишком многогранна. Однако, я дам вам некоторую справку и вектор того, что можно почитать, чтобы не оконфузиться на собесе.
❔ Этот вопрос редко встречается на джуновских собесах, либо вы будете везунчиком, как я 🤡 Но если претендуете на middle и выше, то надо быть готовым к такой дискуссии.
Итак, при переходе на микросервисную архитектуру возникает серьезная проблема - поддержание консистентности данных. В монолитных приложениях это проще, поскольку все данные хранятся в одной БД, и любые изменения выполняются в рамках одной ACID транзакции. Но если возьмем каноничные микросервисы, где каждый сервис имеет свою собственную БД, там уже такое провернуть не получится, потому что транзакции существуют на уровне одной БД, а не нескольких 💻
✈️ Мне на собесе дали кейс с покупкой авиабилета в приложении. И представим, что один из MS отвечает за бронирование мест на рейсе, другой - за оплату. Но что, если после успешного бронирования места произойдет сбой в процессе оплаты? 🔴
Поскольку базы данных разделены и ни черта друг о друге не знают, откат бронирования не произойдет автоматически. Вот и потенциальное возникновение неконсистентности данных: место забронировано, но билет не оплачен. Что делать в таком случае? 🤔 Выкинуть в мусорку эту говёную затею и не связываться с модными микросервисами (шутка, а может и нет).
✅ Чтобы решить эту проблему, разработчики могут использовать паттерн SAGA - это последовательность отдельных транзакций, выполняемых в разных микросервисах, которые вместе формируют одну логически завершенную операцию. Бронирование места и оплата заказа - это две отдельные транзакции, но вместе они составляют одну операцию🔅
❓
Зашибись! Идея прекрасная! Но при реализации сразу возникает много неудобных вопросов: как понять, что возникла проблема в транзакции? Кто должен это понять и т.д.?
🚬
Вот как раз для координации этих транзакций создается специальный микросервис-координатор 😎 Этот компонент отслеживает все шаги операции, контролирует их выполнение и управляет откатами в случае сбоев. Такой подход называется оркестрацией с регистратором.
________________________
Чувствуете, как много вопросов и подводных камней появляется? 😂 А это я только пару слов сказала. Я сама посвятила не один вечер, чтобы после собеса хоть как-то вникнуть в эту тему.
Сагу тоже можно реализовать по-разному: оркестрация с регистратором и без, хореография с регистратором и без него и т.д.
А есть вообще другие паттерны и подходы к организации распределенных транзакций: Two-Phase Commit, Event Sourcing, CQRS, Workflow и др.
Я потом, кстати, спросила нашего бэкендера, как у нас будут работать транзакции, мы ведь переходим с монолита на MSA, ответ был интересным и неоднозначным, но это уже другая история 🤓
В общем, IT это мир чудес и волшебства ✨
🟢А с какими паттернами или подходами работали вы в микросервисной архитектуре? Или может сидите на монолите и радуетесь жизни?))
📎В комментах к посту оставляю полезные ссылки на материалы к данной теме. Конечно же, там будут ссылки на все части сумерек 💪
Эх, и почему мне такой пост не попался, когда я ходила по собесам? 🤣🤣
Желаю всем прекрасных выходных и пусть всё у вас будет 🔤🅰️🔤🔤🔤🔤🔤🅰️
#собеседования
@vitazaebymba