Целостность данных в микросервисной архитектуре / Николай Голов (Avito)
Vložit
- čas přidán 13. 01. 2019
- Приглашаем на конференцию Saint HighLoad++ 2024, которая пройдет 24 и 25 июня в Санкт-Петербурге!
Программа, подробности и билеты по ссылке: vk.cc/cuyIqx
--------
--------
HighLoad++ Siberia 2018
Тезисы и презентация:
www.highload.ru/siberia/2018/a...
На дворе 2018 - все любят микросервисы и пилить монолиты.
При этом у монолита с единой базой есть плюс - целостность и согласованность данных о, например, списании денег за услугу и применении услуги можно гарантировать обычной транзакцией на уровне СУБД (PostgreSQL, Oracle и т.п.).
…
--------
Нашли ошибку в видео? Пишите нам на support@ontico.ru
Хороший доклад по очень важной теме, спасибо!
Спасибо за базовые идеи. Можно увидеть лез за деревьями
Супер лекция. Спасмибо!!!
23:23 гарантировать отменяемость можно только в случае, если данные еще не были использованы другой транзакцией перед их отменой. Поэтому либо собираем на коленках свой 2PC, либо менеджим транзакции по принципу blockchain.
Saga: choreography based Персистентная шина RabbitMQ подойдет? или все таки Kafka?
Здравствуйте Николай. А как реализовано ведение документации DWH (S2T)б как происходит синхронизация с кодом?
Доклад Константина czcams.com/video/OOP_4kuzaWI/video.html
Отлично изложена теория
30:36
Не понятно, про какой сервис саг говорит докладчик для саги на хореографии?
Если, который откатывает и монитрит саги, то это получается оркестратор, а это уже другой подход
Следующий доклад про оркестратор послушай
Не надо говорить, что чего-то нельзя.
Всё можно, надо знать плюсы и минусы.
и не надо становиться авито - авито - это УГ какое-то неюзабильное.
Огромное спасибо! Таки взрыв мозгов :)
хорошо, что на русском! :)
Я правильно понимаю, что если Service1 посылает событие в шину, то это событие примет Saga по каналу Service1-Saga и перешлет в Service2 по каналу Saga-Service2, далее результат Service2 отправит в Service2-Saga и т.д.?
Все взаимодействие делается через Saga с помощью шины, т.к. только она знает структуру зависимостей?
Вроде нет. При старте микросервис отправляет в Сагу свои параметры (после кого запускается, обязательный или нет). Все микросервисы используют единый (общий) канал связи. Для примера возьмем регистрацию. При поступлении события new_user микросервис, ответственный за это событие, обрабатывает событие и кидает событие new_user_ok (типа выполнил), микросервис, который стоит за ним, например, рассылка, ловит уже событие new_user_ok, отправляет email пользователю и шлёт событие reg_email_ok (на случай, если кто-то хочет подписаться за этим сервисом). В свою очередь, Сага тоже читает все события и смотрит, если микросервис 1 обязательный и в канале не было события new_user_ok, то отменяет все действия. Сага читает канал наравне со всеми и если сервис Саги сломался, отменить действия он сможет после починки, но вся система при этом не выходит из строя. Из минусов, то что все события летают ко всем сервисам. Нужна какая-то шина доставки данных с фильтрами. Но это я так понял и я мог совсем не так понять концепцию. То что Вы описали, больше подходит под описание оркестрируемой саги. Не знаю почему все так за хореографическую, по моему мнению, в ней очень много мест для непредсказуемого поведения и канал связи тоже может подвести, как и оркестрируемая сага. Из плюсов только гибкость системы, но хорошо продуманная оркестрируемая сага может обладать хорошей гибкостью. Надеюсь, Авито обнародует результаты своей работы.
@@ivangorsky7537 я вообще не понял, что за бред нес докладчик про какое-то вписывание чего-то там в хореографическую сагу, когда во всех статьях, хореография описывается просто как набор событий, на которые подписываются другие сервисы и выполняют свою логику. Откат также происходит по событию, просто при ошибке вместо reg_email_ok отправляется reg_email_fail. И всё. Нет больше ничего. Нет по-сути никакой саги вообще. Оркестрируемая сага там да, она представляет из себя некую сущность, в которой описывается последовательность шагов и компенсирующих шагов на случай сбоя.
Хореография - сервисы выполняют некую логику по событию.
Оркестровка - некая сущность сама вызывает нужные сервисы и после сбоя помнит с какого шага продолжить и в каком направлении.
Кроме того, в этих же статьях пишут, что хореография - это ад, если бизнес-процесс состоит из 3 и более шагов и что в таком случае, лучше использовать более продвинутый подход - оркестрацию.
Видимо мы с докладчиком разные интернеты читаем. При хореографии если сервис не обязательный, он просто не генерирует события при неудачах и на это просто никто не будет реагировать. Вот и всё. Всё управляется событиями. Не нужно тут лепить еще какую-то хрень в которую сервис отправляет свои параметры (после кого запускается, обязательный или нет). Зачем?
@@xfg9183 а если сервис не в состоянии сообщить об ошибке? Внезапно умер.
@@ivangorsky7537 если сервис умер, то событие для него останется лежать в очереди. Сервис поднимется, обработает событие и в свою очередь сгенерирует успешное событие reg_email_ok или не успешное событие reg_email_fail и так далее по цепочке. Падение сервиса ничего не ломает.
@@xfg9183 а если задача должна быть выполнена за 10 минут, а сервис поднялся через 20? То мы fail получим только через 20 минут. Но это пол беды. При таком подходе каждый сервис должен хранить логику обработки ошибок.
Например, при использовании саги, сервисы должны уметь только обрабатывать событие и откатываться. Решение кому и когда откатываться принимает сага.
Если же сервисы сами ловят fail-события, то логика работы системы становится размазанной по сервисам, менее прозрачной и неизвестно что и как себя поведет при очередном fail-событии.
Никакой конкретики
Ещё один доклад о сагах, ничего нового.
Если не составит труда, дайте, пожалуйста, ссылки на ещё видео по сагам. Не могу найти :(
еба крист новоселич
как же бесит, когда в докладах спрашивают у зала - кто знает это, кто знает то, кто участвовал в этом, кто не участвовал и т.д. Я не думаю, что у докладчика есть несколько способов изложения своего доклада в зависимости от ответа зала.
Докладчику просто самому интересно какой сейчас уровень у разраблтчиков
Наливает воду в доклад
Попробуйте это в своих докладах, поймете зачем