Целостность данных в микросервисной архитектуре / Николай Голов (Avito) 

Следующий доклад про оркестратор послушай

Вроде нет. При старте микросервис отправляет в Сагу свои параметры (после кого запускается, обязательный или нет). Все микросервисы используют единый (общий) канал связи. Для примера возьмем регистрацию. При поступлении события 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-событии.

Если не составит труда, дайте, пожалуйста, ссылки на ещё видео по сагам. Не могу найти :(

Докладчику просто самому интересно какой сейчас уровень у разраблтчиков

Наливает воду в доклад

Попробуйте это в своих докладах, поймете зачем