0: Всем привет. Предлагаю как обычно, минутку или 2 подождать, пока все подключаются и начнём.

1: Так, давайте экран пошарю и будем начинать.

2: Скажите, экран видно, меня слышно? Да, видно, слышно. Угу. Отлично. Так, с чего хотел начать? Ну, сейчас у нас 20 человек, возможно, повезёт. Возможно, нет.

3: Чат продублирую. Видимо, вы начали уже добавлять практику и начали добавлять практику в то же самое пространство, где у меня была доска, да, потому что я всем ссылку, видимо, рассылал. Просьба. Так.

4: Не делать, потому что там мой бесплатный аккаунт и конкретно наша доска уже заблокировалась. То, что всего там несколько досок доступны для редактирования. Сейчас я всех перевёл в статус гость.

5: И чьи вот 3 доски, которые добавлены без названия медиа трекинг и анти, и untitled, напишите мне, я вам их перенесу, постараюсь, к сожалению, сразу не посмотрел, чьи, а теперь уже не видно, потому что теперь везде

6: Я владелец. Так, ну я, да, в чат продублирую. Если кто-то здесь, то напишите мне в личку, пока в отдельном пространстве сегодняшнюю лекцию проведём, потом я туда перенесу.

7: Так, сегодня мы поговорим про распределённые транзакции, про оркестратор распределённых транзакций. Так почему-то не работает. Вот он же оркестратор бизнес процессов.

8: Все обсудим и совсем чуть чуть поговорим про бипин нотацию.

9: Так, давайте я план сегодняшней лекции скопирую.

10: Угу. И давайте, наверное, 1 вопрос сразу в зал. То есть, кто знает, кто, как понимает, что такое распределённая транзакция?

11: Можно своими словами? Да и мы потом поговорим.

12: Кто-то хочет рассказать, высказаться.

13: Транзакция, которая задевает несколько сервисов.

14: Угу. Так, окей. Транзакция распределённых бд. Так, а давайте, да, с самого начала, на всякий случай, чтобы все правильно понимали вообще, что такое транзак.

15: Кто начнёт?

16: Атомарная какая-то часть какого-то действия, либо все, либо не выполнилось вообще. Угу. А, наверное, проще всего на примере будет, да, потому что атомарная. Не очень понятно.

17: Ну, то есть тут скорее набор атомарных действий, которые нельзя выполнить вместе, да? Ну, в смысле, наоборот, можно выполнить, нужно выполнить только вместе. Нельзя выполнить только часть.

18: Так, давайте я порисую тогда и постепенно объясню. Ну, самый простой пример, да, это перевод денег, перевод денег должен быть в транзакции. Мы должны списать деньги у 1, ну, условно, пользователя, да.

19: Кто передаёт и записать на счёт другому, если мы у 1 списали деньги, a2 не записали, ну это будет плохо, потому что деньги потерялись. Поэтому вот перевод денег такой пример, самый простой пример транзакции.

20: Если мы не смогли записать на счёт 2 деньги, да, кому переводили, то мы должны вернуть их на счёт 1, так как операция не удалась. Давайте вернёмся к нашему любимому примеру.

21: Создание заказа в интернет магазине.

22: Да, тут правильно написали, то есть транзакции. Ну, транзакции мы рассмотрели в рамках 1 базы данных, да, то есть, если мы в рамках базы данных делаем какой-то селект, потом update 1 таблицы, инсерт во 2 таблицу.

23: И ещё что-то в 3 таблице. Если мы это все оборачиваем в транзакцию, то силами базы данных транзакционность будет. То есть если мы не смогли какую-то часть операций выполнить, допустим, там insert во 2 таблицу, то вся

24: Вся операция откатится, то есть будет транзакция выполняется либо полностью, либо либо не выполняется вообще. То есть в рамках 1 базы данных. Все просто. Это обеспечивается инструментами субд.

25: Наш вопрос как раз, да, распределённая транзакция, когда участвует несколько баз данных либо несколько сервисов. Сейчас мы на примере и посмотрим. То есть в случае создания заказа, что нам нужно сделать? Ну,

26: Записать что-то в базу данных, допустим, склада, да, о том, что нужно зарезервировать некий товар.

27: Так я же экран шарил, да, кроме этого, нужно, если мы говорим, да, про распределённую систему, про микросервисы крут самих заказов этот заказ создать, либо пометить, что он создан, что он

28: Допустим, требует оплаты, либо уже оплачен да, крут аббревиатура напомню на всякий случай кри 3 update делет, то есть это просто микросервис, который не обладает бизнес логикой, а предоставляет только доступ к данным.

29: Так, и, к примеру, нам нужно куда-то на шину это выгрузить. Ну не обязательно. То есть мы при этом кидаем на шину данных, возможно, на какую-то даже внешнюю, что заказ создан.

30: И давайте пофантазируем ещё.

31: Ну какой-то, допустим так.

32: Куда-то отправляем, допустим.

33: Сборка заказа, то есть сигнал о том, что нужно начинать сборку заказа. Скорее всего, это будет на складе, там же, где круд склада, но не важно. То есть суть в том, что при вот этом действии создания заказа нам нужно, ну,

34: Минимум сходить в 1, сделать 4 сетевых вызова и на каждом этом, ну, условно, взаимодействии, естественно, может что-то пойти не так. Допустим, мы зарезервировали на складе товар, но потом

35: Упали при создании заказа то, что база данных не работает, сервис не работает либо ещё что-то, либо мы все это проделали, но не смогли куда-то в шину данных выгрузить, либо сборку заказа не смогли сделать. И в таком случае как раз

36: Происходит, ну, возникает распределённая транзакция. Если мы говорим, что все вот эти 4 действия должны либо произойти все, да, либо если мы что-то не смогли сделать, то нужно откатить все предыдущие. То есть вот

37: Про вот эту проблематику мы и будем говорить. Ну, иначе данные разъедутся, да, у нас заказ где-то будет создан, задание на сборку заказа не возникнет и не возникнет никогда, если мы не предусмотрели как раз, ну,

38: Каких-то повторов, да, и так далее. Так

39: Про проблематику, я надеюсь понятно. Если нет, то лучше вопросы прям сейчас задавать. У нас сегодня не такая большая лекция, поэтому можно походу включать микрофон и спрашивать.

40: Так, если вопросов нет, то идём дальше. Есть 2, наверное. Ну, 2 паттерна мы сегодня рассмотрим.

41: Так это паттерн ОСАГО?

42: Для того, чтобы, ну то есть проблема понятна. Вопрос в том, как это реализовать. То есть ещё раз, если у нас какой-то шаг отпал, то нам нужно, скорее всего, 2 предыдущих отменить.

43: То есть делать компенсирующие какие-то действия, которые отменяют предыдущие шаги, ну, либо ещё что-то придумать вообще по паттернам распределённых систем. Мне больше всего нравится вот этот ресурс микросервиса кио, да?

44: То есть тут достаточно много всего в виде статей, не в виде там большого какого-то инфор материала, как в книгах обычно бывает. И вот здесь мне больше всего нравится что-то читать. То есть тут минимум воды и, на мой взгляд, понятные примеры.

45: И понятные диаграммы. Итак, рассмотрим 1 паттерн, который позволяет работать с распределёнными транзакциями. Это паттерн саго. Ну, собственно, да, проблема. Как выполнить транзакцию

46: На несколько сервисов.

47: Есть 2 под паттерна, или, как, как сказать, реализации паттерна Сальта. Это на основе хореографии и на основе оркестрации. Давайте, наверное, сначала посмотрим про оркестрацию.

48: Вернёмся, немножко порисуем, а потом чуть позже вернёмся и посмотрим хореографию.

49: Так, в чем? Что говорит наш паттерн ОСАГО в случае оркестрации? То есть у нас есть несколько сервисов, то есть тут тоже рассматривается заказ, создание заказа и какие

50: Действия суть в том, что у нас есть некий центральный мессенджер брокер. Неважно, есть некий оркестратор, который управляет всеми транзакция транзакциями, вообще управляет всеми бизнес процессами.

51: И как раз вот он и отслеживает, что у нас либо все выполнилось вообще, на каком мы этапе находимся и как сказать, если что делает повторы, да, либо делает вообще транзакции. То есть

52: Накатывает, как оно называется, компенсирующие транзакции. Да, я вот сам сказал, что будут понятные схемки, но вот конкретно в паттерне Саги Сага. Мне не очень нравятся схемки, поэтому я их сейчас, наверное, сам попробую перерисовать.

53: Чтоб было понятно, что такое оркестрация, так нам нужно вот сюда.

54: Сейчас, секунду. Да, доска будет. Там все ссылки есть, наверное, доску. Я, ну, разберусь с правами редактирования, с тарифом и верну доску, как было.

55: Давайте чуть по другому порисуем ту же самую схемку, нарисуем большую распределённую транзакцию.

56: Для простоты будем рассматривать последовательно распределённые транзакции, то есть когда мы не в параллель что-то делаем, а просто последовательно.

57: То есть, условно тут порисуем уже не архитектуру больше, а блок схемы, чтоб было понятнее, то есть к нам.

58: Происходит некое событие, и мы, ну, условно вот в такой контур распределённой транзакции вступаем. То есть, 1, допустим, нам нужно выполнить какой-то эскуэль на 1 базе. Ну, на самом деле, неважно на какой базе просто некий эскуэль запрос, да.

59: Потом дальше мы его выполнили, допустим, зарезервировали товары. Дальше мы должны выполнить ещё 1, сколь запрос там неважно, в той же базе, в другой базе, в другом сервисе и так далее. И, допустим, ну, для

60: Набрали. Мы должны ещё отправить сообщение в очередь э. Мессендж.

61: Sent message queue. Вот так, наверное, правильно, да, saint to message. Queue. Вот. И после чего у нас распределённая транзакция успешно завершается, и мы выходим

62: То есть вот такая у нас последовательность. Теперь смотрите, важный момент. Так, сейчас попробую кружок скопировать, что у нас одновременно вот по процессу заказа могут уже идти несколько, то есть

63: Разные пользователи плюс минус одновременно создают заказы, даже если это, а если это длительные операции, то даже не одновременно у нас могут быть несколько инстансов процесса гулять по этой схемке.

64: Условно 1 пользователь создаёт заказ, и он только ещё на входе. Для этого заказа у нас ничего ещё не выполнилось для какого-то другого заказа. Ну, допустим, с водичкой 45 у нас выполнился 1 запрос.

65: Но ещё не выполнил 2. То есть это просто некое состояние, да, и так далее. Айдишка 87 находится в этом состоянии. Вот теперь давайте посмотрим самое интересное. То есть, что если мы

66: У нас условно 1 операция внутри распределённой транзакции выполнилась, a2 упала, 2 упала с некой ошибкой, и нам тогда нужно как-то на это среагировать. Стандартный

67: Ну, стандартный подход, да, сделать компенсирующую транзакцию. То есть, нужно откатить те изменения, которые мы сделали в предыдущем блоке. То есть, ну, на самом деле, не в предыдущем, а во всех блоках до, просто в данном случае у нас только 1 блок.

68: До этого, до падения. Соответственно, мы должны его откатить. Давайте это нарисую другим цветом. То есть что это в случае ошибки к 1

69: Это 1 вариант действий при ошибке. Давайте сразу. Какой ещё может быть вариант? Да, помимо того, что мы сразу падаем, ну, не то, что падаем, а откатываемся.

70: Что ещё приходит на ум? Что можно сделать, когда у нас вот это упал в чате, пишет трат, да, абсолютно верно. То есть мы можем перед тем, как совсем уйти в компенсирующую транзакцию, мы можем попробовать

71: Повторить, да?

72: То есть, ну, здесь я уже непоследовательно рисую, но, в общем, ретрай сколь 2, то есть у нас с 1 раза не получилось, мы попробовали заретраится, и на самом деле мы можем ретрай так несколько раз, то есть есть разные

73: Tetra, мы про это позже на лекциях будем говорить. То есть можно, допустим, просто 3 раза повторять, можно повторять 3 раза с нарастающим таймаутом, допустим, через секунду, через 2 секунды, через 5 секунд, ну, через секунду, через 5.

74: И, допустим, через там, через минуту и так далее. Но самое главное, чтобы все всегда было, во первых, ограниченное их количество, чтоб мы вообще в вечный цикл не попали. И во вторых, нужно смотреть на тип ошибки.

75: Да, то есть, к примеру, если у нас вот это вот действие эскуэль 2 не выполнилось по причине того, что сети нет, то да, ретрай может помочь, ну, сеть восстановится, там какой-то сбой уйдёт, и при ретрай мы

76: Сможем повторить. Ну, есть шанс, что мы успешно выполним эту операцию, но если, допустим, сколь 2 не выполнился, потому что, ну, допустим, база данных возвращает, что такой идентификатор уже есть в базе, да, то сколько бы мы не пытались

77: Править, допустим, запись, скорее всего, всегда мы будем натыкаться на ту же самую ошибку. То есть вот здесь вот при выборе стратегии обработки ошибки нужно всегда смотреть на тип ошибки. То есть это тоже

78: Особенно, ну, бизнес логика либо инфраструктурная логика. Вот просто так ретраить все подряд я не советую.

79: Так, в чате повторить, понять, почему не получилось исправить. Ну вот смотрите, да, понять, почему не получилось и исправить это уже некое ручное действие. То есть в целом, да, можно вот здесь вот повиснуть, мы про это тоже будем говорить и

80: Условно ждать.

81: Вмешательство техподдержки, да, это тоже вариант, но, естественно, нам нужно понимать, все зависит от нашего бизнес процесса. То есть, если мы не можем себе позволить, что у нас

82: 1 операция выполнена, 2 не выполняется уже 10 секунд, да, то мы должны учитывать этот тайм аут в ретрае, да, то есть, условно, если максимум 10 секунд должна быть синхронизация, мы не можем ретраить в тече

83: Ни минуты. И точно также мы не можем ждать вмешательства, техподдержки, да, потому что у нас данные разъехавшиеся, то есть нужно сразу ревертить. Может нужно, когда делают реверт и потом подвешивают вот этот токен.

84: Да, и ждут вмешательства, техподдержки, то есть есть разные процессы.

85: Так, так, так. Угу. Ну, то есть, если мы понимаем, что ничего страшного, что мы выполнили эскуэль 1, да, за ретраить, не получилось, но мы по каким-то причинам не хотим ревертить, подвешиваем, и мы знаем, что в течение 8 часов техподдержка

86: Придёт, разберётся, то можно на этом ограничиться. Давайте вот эту ветку разберём. То есть мы сделали реверт, у нас система пришла опять в нормальное состояние, но при этом мы операцию не выполнили.

87: Которые должны были, естественно, мы должны

88: Отпра выполнить логику обработки ошибок. То есть, во первых, сказать пользователю, что заказ не создался. Во вторых, для опять же, той же техподдержки, для нас самих какой-то сделать Алерт, да, запись в лог и так далее, чтоб пото

89: Можно было разобраться, что произошло и что теперь с этим делать.

90: Так. Угу. Что ещё тут хочется сказать? Ну, то есть, да, вот этот токен 45, он куда-нибудь. Ну, давайте другой какой-нибудь.

91: 56 токен, он, да, пошёл уже по ветке с ошибкой и его тоже перекрашу. То есть главное понять то, что вот в такой распределённой транзакции у нас одновременно может быть несколько инстансов процесса в данном

92: Заказ, да, то есть для разных заказов разные заказы путешествуют по вот этой блок схеме условно и находятся в разных статусах. Что ещё может произойти? Давайте вот здесь посмотрим ошибку. То есть если

93: Здесь мы упали то, что мы должны сделать. Во первых, мы должны ревертить

94: Сколь 2, причём мы это делаем в обратном порядке.

95: Откатываем оо уже наката накаченные и потом откатываем реверт столь 1.

96: Ну и дальше точно также отправляем ошибку. Логика обработки ошибки. Теперь смотрите, интересная такая штука, что будет, если мы вот здесь упадём? То есть мы вот здесь упали, раз попыта.

97: Пытались откатить предыдущее и упали на откате. Что при этом делать? Есть идеи?

98: Алертит вручную смотреть. Ну то есть, да, всегда у нас есть шанс просто подвесить токен, оставить его здесь. Так, давайте коряво, не буду рисовать. То есть всегда есть вариант.

99: Запомнить состояние, что 61 заказ, он вот здесь, то есть для него упало вот это действие i, упало вот это действие и уйти в ожидание техподдержки.

100: Так, ещё есть варианты?

101: Сигнализировать какой-нибудь сервис, ретраить, откат, ретраить, откат, да, правильно? То есть мы вообще ретрай можем на все действия на самом деле повесить и на уровне инфраструктуры даже сделать. То есть что у нас автоматом будет какое-то количество ретра.

102: При определённом типе ошибки, да и только потом падение и уход вот по веткам вниз.

103: Ретраить, ка, то есть правильно, сигнализация какой сервис? Так, на самом деле, да.

104: То есть вот мы упали здесь, потом упали, здесь несколько раз попробовали, ничего не получилось. Какие у нас есть варианты?

105: На самом деле, да. Ну, наверное, самый распространённый метод это

106: Какая-то даже не сент. Вот так.

107: От logic, то есть какая-то бизнес логика, предусмотренная на случай вот рассинхронизации данных и что мы не смогли их вернуть в консистентное состояние. Вот здесь уже

108: Ну, скорее всего, не обойтись. То есть нужно будет ждать вмешательства, техподдержки, но

109: Давайте так, ещё веселей. А что, если у нас вот эта штука тоже упала?

110: Так, варианты из чата ошибки кидать сразу. Ну тут вопрос, куда кидать ошибку? Вот мы попытались, да, кинуть ошибку, у нас все упало.

111: И скинуть ошибку, просто ответить, там 400, да, вот, ну, условно, в ответ тому, кто запустил распределённую транзакцию, то тоже вариант, но из плохого я вижу то, что мы должны статус

112: Сказать, то есть, что именно сломалось. То есть вот этот статус, состояние системы, где у нас какой токен лежал и где он упал. Так что ещё из чата у нас есть

113: Откатить к самой базовой ревизии логи, может ли ветра отката сработать частично так откатить к базовой ревизии, да, то есть мы можем вот здесь условно что-то запоминать, но опять же, если мы говорим про 1 базу,

114: То там все просто. Если мы говорим про состояние системы, да, то по сути вот здесь вот в реверта мы и пытались откатить, и у нас это не сработало.

115: Ну я к тому, что вот здесь вот если что-то запоминать и пробовать откатить через fatal, то это тоже тоже может упасть по сути это тот же сценарий с падением каких-то конкретных реверто.

116: Так, может ли ретрай отката сработать частично часть транзакций откатить, a2 часть сломаться? Тогда ретрай ретрай сразу. Вот, по сути, мы так и смот этот вариант и смотрим, да, то есть мы можем рассматривать, что у нас этот блок упал.

117: Потом у нас мы стали последовательно откатывать, это у нас может сработать, а все упасть вот здесь, ну то есть опять же, у нас будет неконсистентное состояние, да, то есть мы что-то

118: Могли откатить что-то не смогли и куда-то упали.

119: Транзакция на уровне бд неделима. Смотрите ещё раз, давайте вернёмся к вот этой схемке. То есть если у нас все в рамках 1 базы данных, да, общие товары и заказы, то вообще вопросов нет. То есть вот эта распределённая транзакция, она

120: Катится средствами субд внутри базы. Нам не нужно об этом беспокоиться. Мы говорим именно про распределённую транзакцию, когда нам нужно что-то проапдейтить или записать в несколько баз, да, вот 1 действие, 2 действие.

121: И вообще даже не обязательно с базами данных. Ну, какие-то действия совершить, выложить на шину данных эти данные, какое-то сообщение об ивенте и послать сигнал ещё в какой-то сервис.

122: То есть суть как раз в том, что у нас нету единого места, да, где мы можем вот, ну, автоматически, условно откатить транзакцию. Вот мы про этот вариант говорим.

123: Так, ну смотрите, то есть вообще, по идее вся суть, мы тоже про это будем говорить про отказоустойчивость, что повышая вот уровень вот таких вот вложений, предусматривания, то, допустим, мы

124: Предусмотрели, если здесь у нас что-то упало. Потом предусмотрели, если у нас частично реверт эскеля реверт транзакции упал. То есть этот упал, мы, грубо говоря, на каждом шаге мы снижаем, вероятно,

125: Этого сценария, то есть условно, если мы предусмотрели 1 уровень компенсирующих транзакций, то, допустим, если у нас

126: Падение происходит в 1 проценте случаев, да, мы предусмотрели вот эти вот, ну, условно, грозди компенсирующих транзакций. Тогда, получается, мы проблему проблемные заказы снизили с 1%. Ну, условно, до

127: Че, в 100 раз 0 0 1%.

128: Если мы предусматриваем, что и компенсирующая транзакция может упасть, да, то вероятность такого события ещё примерно в 10 тире 100 раз ниже. То есть мы предусмотрели вот этот сервис и тем самым снизили вероятность сбоя.

129: То, что даже он упадёт ещё, допустим, на 1 порядок.

130: И так далее и уже в зависимости от требований к надёжности к вашей системе мы уже проектируем, либо мы говорим, что 1% вообще не страшно и мы просто делаем только happy path, только прямые.

131: Вот эти вот вызовы и вообще не паримся про компенсирующие транзакции. Если мы говорим, что 1% это слишком много, нам нужна система понадёжней, чтобы хотя бы у нас было, ну сколько тут получается? 99, запятая 99, то мы предусматриваем вот

132: Компенсирующих транзакций. Если ещё надёжнее, мы предусматриваем вот условно ветку для падения компенсирующих транзакций и на самом деле мы можем идти и так далее, да, то есть снижение постепенно

133: Ещё и ещё вероятность неконсистентных данных, но вот что хочется сказать до нуля, да, никогда у нас не получится сделать. То есть все равно будет какой-то, какой, какие-то доли процента, когда все упадёт.

134: И никакие вот эти вот грозди компенсирующих транзакций и обработок проблем при компенсирующих транзакция, нас не спасут. То есть вся суть только вовремя выбрать вот эту цифру и вовремя остановиться. Так здесь

135: Надеюсь, понятно. То есть 1% у нас падает. Хэппи пасе. У нас 99% пролетает хорошо, напрямую.

136: Так. Угу. У меня уведомления сыпятся, так, что-то я не выключил. Ну, вроде в чате больше нет.

137: Угу. Вот 1 у меня вопрос в реверт эскьюэль может быть просто вот замена, допустим из wallet на false условно, а не полное там как-то удаление всех полей?

138: Ну, зависит опять же, от сценария. То есть мы, да, можем какую-то сущность пометить, просто, что она невалидная, если мы её добавили, если я правильно понял идею, если мы её добавили новую, да, то есть мы её можем просто пометить там.

139: True или там звали фолс. А если мы вот в сколь 1 проапдейтили какие-то данные, то есть у нас было условно на счёту пользователя, там 100 ₽ мы проапдейтили, сделали 50 ₽, то есть

140: Просто так, если мы сделали апдейт, ну, вместо 100 записали 50, то просто так мы там не сможем пометить фолс. То есть, если мы как допустим,

141: Если мы храним ивенты, то есть не списываем сразу 100 ₽, а храним списание 50 ₽, то вот это списание мы можем пометить, как это называется сорсинг. Вот.

142: Когда мы храним ивенты, а не конечное значение. То есть в целом тут зависит от от сценария, от задачи и от подхода, хранения данных. Ну какие данные мы делаем? Ну и с другой стороны, тут может быть не просто, не только эскуэль, а просто какой-то

143: Rest вызов, да, то есть мы делаем рест, вызов какой-то вообще внешней системе, не знаю, когда у доставщика создаём заказ на отправление. То есть потом мы, мы как

144: Как сказать, в таком случае нам нечего помечать из valley. Пос. Да, нам нужно какой-то другой endpoint у доставщика дёрнуть, что заказ вот с такой-то айдишкой нужно отменить ну отправление с такой-то айдишкой нужно отменить. То есть в общем случае у каж.

145: У каждого вот этого действия нужно вручную предусматривать реверт.

146: Надеюсь, ответил. То есть, ну, я так понимаю, в инсорсинг довольно хорошо вкладывается. Вот если мы делаем именно распределённые транзакции, ну, если мы говорим про данные Иван сорсинг, ну да, он хорошо на это ложится, но

147: Опять же, как, как сказать, выбирать или нет, я бы все-таки от доменной области, от потребности проекта решал, а не исходя из

148: Ну, допустим, необходимости распределённых транзакций тому, что если микросервисная архитектура, распределённые транзакции практически всегда есть, ну вот сейчас мы как раз сегодня поговорим, как, как с этим быть.

149: Ага, у меня ещё 1 вопросик есть. А вот получается все вот эти вызовы, то есть эскьюэль 1 скил 2 и st mq, они по факту выполняются как раз оркестратором, каким-то 1 сервисом, который вот все это вызывает. Да, да, да. То есть сейчас мы до этого дойдём.

150: То есть мы пока просто логически рисуем, чтобы мы хотели от оркестратора сейчас зафиксируем и про это поговорим. Угу. Спасибо. Так, тут ещё вопрос в чате хэппи пап, ну то есть это

151: То есть путь без ошибок. То есть, когда у нас просто токен зашёл, нигде ничего не упало, мы пролетели и 99% токенов. Ну, токеном я называю конкретные операции создания заказа, они будут пролетать вот по

152: Прямого пути условно, да, и без ошибок. Так получается, давайте пойдём дальше. То есть, если мы реализуем некую коробку, которая, во первых, сможет исполнять некую блок схему,

153: И, во вторых, хранить состояние токена. То есть нам важно не только исполнять схему, но и запоминать, где у нас токен находится, что 45 токен. Здесь для него выполнилось какие-то операции, 87 здесь.

154: 6 сообще состояние ошибки вот здесь на этой какой-то блок схеме. То есть если у нас будет какая-то коробка, которая умеет, ну во первых вот в это ветвление, да, то есть если что-то упало, умеет совершат

155: Компенсирующие транзакции, которые мы, естественно, сами вручную зададим. И 2. То есть тут я скопировал требования к нашему оркестратору. Оркестратор должен отслеживать состояние экземпляров процесса. Ну то есть то, что я проговорил, где, в каком состоя

156: У нас лежит конкретный токен, то в целом, вот если эти 2 критерия устраивают, то мы можем его взять и использовать, ну, основные проблемы распределённой транзакции микросервисной архитектуры будут решатьс,

157: Так, когда в общем случае выбирать саго вместо to писи можно позволить долгоживущую транзакцию консистен, важно так давайте, наверное, после лекции все расскажу и потом к этому вопросу.

158: Вернусь, как хранится положение токена. Да, сейчас про это поговорим.

159: Так мы рассмотрели проблему и рассмотрели критерии для оркестратора оркестратора как раз в рамках паттерна ОСАГО.

160: На самом деле вот таких систем достаточно много. То есть таких вот движков, коробочных решений, которые умеют это делать из примеров есть

161: Допустим, есть темпорал, да, как сказать, такая библиотека, ну, либо сервер, который, который, по сути, и делает исполнение блок схемки и хранение токенов.

162: Как это обычно устроено. Ага, красный.

163: Есть оркестратор, почему-то я печатать не могу.

164: Допустим, какое-то коробочное решение, и у него есть своя база данных база данных, она ничего не знает про нашу специфику, про специфику процесса, она, ну, в зависимости от

165: Может, всегда хранит токены, иногда ещё хранит.

166: Воркфлоу.

167: Ну то есть наши вот эти вот блок схемы, как мы идём по бизнес процессу, какие у нас есть компенсирующие транзакции, просто ветвления и так далее.

168: Условно есть коробочные, коробочный такой продукт, и мы уже можем его использовать.

169: Если рассматривать наш пример с созданием заказа, давайте попробуем, то это будет

170: Ну, по сути так же выглядеть.

171: Только у нас в центре будет вот этот оркестратор.

172: Оркестратор.

173: Со своей базой я её внутри нарисую, потому что часть этой коробки

174: Которые, в котором мы загружаем нашу блок схему, ну, условно, что надо сначала сюда сходить, потом сюда, потом сюда. Ну то есть последовательность из 4 вызовов. Ну, естественно, должен быть ещё какой-то инициатор процесса.

175: Сервис создания заказов.

176: Он процесс инициализирует, инициирует, да, и потом оркестратор уже конкретный блок, схему берет и выполняет. Да, я сказал про темпорал, это такой движок без нотации.

177: И есть ещее BPM нотация, которую, у которой есть много реализаций, которая как раз хорошо ложится на исполнение заказов на исполнение распределённых транзакций.

178: Давайте посмотрим вообще бимэн это business process module нотей то есть это вот формат нотация ну условно вот таких блок схемок можно отдельно это погуглить посмотреть вот в чем плюс то есть мы наглядно

179: Видим, как будет исполняться наш код. Ну, условно вот, да, заказ получен, создаётся заказ, потом есть какое-то деление, да, то есть мы здесь сходили в какой-то наш микросервис, спросили, есть ли товар.

180: В наличии, если есть, пошли по 1 ветке, если нет, пошли по другой ветке, ну и так далее. То есть тут можно таким же ветвлением делать различные компенсирующие транзакции.

181: Да, ну то есть, если ошибка, то делаем что-то, в чем основной, основной плюс, во первых. То есть сама нотация показывает визуально блок схему процесса. Ну неправильно говорить блок схемы, схему исполнения процесса.

182: LIBOR фо, да, с 1 стороны, и, с другой стороны, из коробки вот все BPM движки, да, то есть реализация мутаций, они поддерживают хранение токенов. Условно, что у нас 1 заказ здесь находится, другой заказ, здесь 3

183: Заказ здесь 4 заказ здесь и так далее. То есть, во первых, мы знаем, где какой токен, и мы знаем какую-то метаинформацию, ну то есть, что вот этот заказ с айдишкой 1, да, и у него, ну, условно, такой-то список товаров.

184: Примеры реализации такой такого итэн движка, например, комунда, наверное, самый распространённый.

185: Давайте вот здесь запишу 1.

186: Энтерра.

187: Там пароли нету никакой нотации, там мы просто вот этот блок схему алгоритма, мы её реализуем кодом, то есть там и нет визуализации.

188: Из так напишу бипин.

189: Ну, визуализировать то можно, но это достаточно бедно будет визуализация. И 2, это гимн.

190: Мишки, например, комунда.

191: Я думаю, оркестраторов достаточно много различных и на основе vpn, и на основе других нотаций, но вот, на мой взгляд, самый популярный это темпорал и комунда.

192: Были разные движки, но, по моему, в 8 комунде вот комунда в себя их интегрировала. Так вот с этим понятно. То есть тут давайте ещё чуть чуть остановлюсь. То есть вот здесь вот на самом деле

193: Идёт исполнение по блок схеме, то есть самого кода не может не быть в каждом из этих, ну то есть внутри команды точно не должно быть, внутри темпорала тоже. То есть тут идёт просто вызов наших сервисов.

194: Условно наш оркестратор вот как на этой картинке окружён кучей сервисов, которые мы из конкретных блоков дёргаем.

195: Так я не смогу нарисовать.

196: Ну, то есть создать заказ покупателя, это значит, мы пошли, сходили в этот сервис, дёрнули вот здесь, да, сходили, проверили наличие, отсюда ушли. Че там, 3 сервис и так далее. То есть это просто

197: Некий управляющий, управляющая схема, которая дёргает наши микросервисы, которые стоят вокруг неё.

198: Так.

199: Про хранение токена ответил то есть это внутренняя база самого оркестратора.

200: Угу. Давайте вопросы почитаю. Очень часто говорят, что Саги это распределённые транзакции. Н. К тому, что такое транзакция, то 1 из определяющих изоляция.

201: Нет ли тут противоречий про изоляцию? То есть, если вы про разные уровни, изоляции, транзакций, то есть, допустим, грязное чтение, чистое чтение и так далее, это уже на уровне, как, как сказать,

202: Ну, то есть, к распределённым транзакциям, как будто они не очень применимы. Ну и я, по крайней мере, не слышал, да, то есть, возможно, и есть для распределённых транзакций разные уровни изоляции, но вот здесь, мне кажется, ну, я пока не очень вижу в них смысла.

203: Все равно любая распределённая система, даже если в ней учтены распреде, распределённые транзакции, она всегда, как это по-русски, ну, то есть она придёт в верное состояние с течением времени, да, и

204: Consistency то, что по-русски. То есть это время, может быть, что мы выполнили 1 действие через миллисекунду, выполнили 2 действие и все синхронизировалось, да, но вот этот разброс, миллисекунду он всегда будет

205: Вот здесь, ну, уже не сделать идеальное, чистое чтение. Если мы пошли в разные базы, сохранили, то есть, условно 1 операцию сделали в товарах и в течение миллисекунды сделали 2 операцию заказа вот в течение этой миллисекунды.

206: Данные будут рассинхронизованы. То есть, я бы сказал так, что в случае там распределённой системы у нас все транзакции, они вот уровня изоляции, грязное чтение.

207: Вот, возможно, да. Возможно, тут есть какое-то другое теоретическое мнение, но я с этим не сталкивался, честно скажу.

208: Что если оркестратор упадёт, тут все очень просто, все как с центральными инфраструктурными вещами, то есть если оркестратор упадёт, то, соответственно, все и застопорится.

209: Естественно, его делают резервируемым, его делают, чтобы он высокие нагрузки выполнял. И ещё смотрите. То есть оркестратор это всегда асинхронная, ну, то есть он не быстро выполняет любая

210: А вот эта вот распределённая транзакция, она будет не мгновенно, поэтому правильно его использовать в асинхронном режиме. То есть, если создание заказа

211: По хорошему я бы сделал здесь вот так в оркестраторе есть свои очереди. Ну давайте, чтоб было прям наглядно.

212: То это произойдёт не мгновенно, то есть в асинхронном режиме. Вот в таком варианте. Если у нас оркестратор падает, то когда он поднимется, он вернётся к обработке сообщений из очереди на вход и продолжит

213: Продолжить его обработку. Плюс он восстановит своё состояние из систе, хранилища из базы данных, да, и он поймёт, что. Ага, вот это вот сообщение я уже разбирал, и оно у меня остановилось на 2 шаге. То есть условно нужно

214: Начать со 2 шага. Вот здесь интересный момент. Чуть чуть отвлекусь с темпоралом. То есть темпорал, он хранит вообще все результаты операции внутри распределённой транзакции и если он падает

215: Потом понимает, что для этого заказа я дошёл до шага 2, то он последовательно выполняет все шаги до этого, но выполняет их фейково. То есть он на самом деле не сходит в круг склада и не

216: Ещё раз, не там добавит товар, либо не отнимет товар, да, он запомнит, что для этого токена, когда я делал 1 шаг, у меня ответ крут склада был, ну, условно, там 200 с таким-то джейсоном, и он из истории это подтянет.

217: И повторно не выполнит. То есть таким образом сохраняется иммутабельность всех операций. То есть не будет такого, что при падении он повторил предыдущие шаги ещё раз. Вот. Но это немножко, да, я про конкретную реализацию темпа.

218: Рассказал. Так, давайте дальше пойдём. Угу. Уже почти час, оказывается, сидим. Правильно ли я поняла, что оркестратор вызывает микросервисы по определённой схеме, да, то есть, вот смотрите, пример простой схемы.

219: Заказ, потом проверить товар в наличии или нет, зарезервировать товар, сделать запрос в отдел закупки. То есть на самом деле создать заказ. Это вызов сервиса, проверка товара, вызов другого сервиса и так далее. Так предлагаю.

220: Идти дальше. Я к плану вернусь немножко непоследовательно получилось. Мы рассмотрели оркестрацию, то есть оркестрация это когда есть некий условно 1 дирижёр, который

221: Управляет всем оркестром. Давайте вернусь к

222: Ссылки. И есть ещё вариант хореографии. Ну вот честно скажу, мне вариант с хореографией меньше нравится. Ну, не то, что меньше нравится. Я меньше встречал его на практике. То есть, на мой взгляд, он чуть

223: Сложнее в реализации, но вот здесь, по моему, в чате уже про to писи говорили. То есть это как раз вот свойственно банковскому, банковской сфере. То есть в чем суть хореографии, хореография.

224: О том, что мы вот эту вот логику по исполнению распределённой транзакции размазываем между разными участниками вот этого, этой же транзакции, то есть нету какого-то центрального оркестратора. Вот здесь, на схеме, это message брокер, который управляет всем

225: А у нас каждый сервис умеет, то есть, допустим, в случае создания заказа. Так, тут что происходит сейчас, да, то есть каждый сервис он создаёт условно.

226: Автооперации. Ну, допустим, в случае списывания денег мы говорим, что вот эти деньги захолдируются. Списывай. Если захолдировать получилось, то условно мы идём обратно, да, и то есть

227: Резервируем какие-то товары, возможно точно также создаём драфт, резервы и потом по цепочке мы, мы подтверждаем то есть чтобы мы у нас деньги из Холда на самом деле списались и из драфта там резерва заказа на самом дел.

228: Зарезервировались и начал заказ создаваться. То есть идея хореографии в том, что мы сначала пытаемся все подготовить, ну, условно, создать черновики операций, драфт или hold, либо ещё что-то.

229: А потом уже все сервисы между собой договариваются, что все ок. У нас получилось создать драфты. Теперь давайте драфта переводить в реальное состояние. Ну то есть вот здесь тоже пример с кредитом лимит ксидит.

230: Кредит, резерт и так далее. В таком варианте, да, получается, каждый из сервисов должен вот уметь, ну, ещё раз повторюсь, наверное, создавать черновик операции, ждать подтверждения и потом

231: Как переводить уже выполненную операцию? В таком случае обычно между всеми сервисами взаимодействие происходит через очереди. То есть в очередь мы кладём, что сначала там зарезервируй, либо захолдируются ства, а потом говорим, что все ок. Теперь из Холда переводи в

232: Уже статус исполнен.

233: Так, про хореографию, да, если интересно, я советую ещё подробнее посмотреть. Тут есть более там расширенные ссылки, да, либо на этом сайте, либо ещё погуглить. Сейчас предлагаю дальше двигаться, чем

234: Про несколько вещей поговорить.

235: Так. Угу.

236: Давайте сразу тогда поговорим ещё про 1 паттерн транзакшн. Абокс, на мой взгляд, он более такой тактический. То есть если Сага и оркестратор это больше стратегические паттерны, которые говорят, как весь процесс организовать, то транзак

237: Бокс, он такой более тактический, но там не рассказать про него я не могу. Давайте точно также.

238: Посмотрим по ссылке и сразу перейдём. К примеру, основная идея. Здесь рассматривается пример, когда мы в рамках распределённой транзакции должны записать что-то в базу и при этом что-то выложить на шину месседж брокер.

239: То есть распределённая транзакция состоит из 2 действий запись в базу, выкладывание сообщения и что предлагается, то есть в паттерне абокс предлагается для этого использовать средства базы данных.

240: Давайте, наверное, расскажу реализацию, потом прокомментирую, то есть мы совершаем некоторое действие, это может быть любое действие да, insert update делет, и при этом мы у нас есть для каждой таблицы, для каждого

241: Действие, да, специально абокс таблица, то есть то действие, которое мы совершили, но это не совсем так, как в сорсинге. То есть тут абокс именно для распределённой транзакции, а для не для накатывания данных после и

242: Что потом происходит? Мы в рамках уже 1 базы данных делаем вот эти 2 операции. То есть здесь проблем возникнуть не может, потому что средствами субд поддерживается атомарность транзакции и потом у нас есть небольшой сервис.

243: Месседжей обычно называется, который следит за autox таблицей, то есть он из неё вычитывает, да, что там появилось, те записи, которые появились и перекладывает машину. Ну условно, что произошёл инсерт заказа, ну создался заказ.

244: Либо заказ удалился, либо заказ обновился. Вот.

245: И таким образом, то есть message релей кладёт машину и потом помечает в утбо таблице, что эта запись обработана там эту запись я выложил машину либо наоборот, да, то есть он берет из out бокс таблицы, помечает выпол.

246: И перекладывают на шину. Тут вопрос, да, на внимательность. То есть какая проблема может возникнуть в таком случае, тут полностью. Угу. Будет, либо, может быть, что упадёт, тогда будет либо 0, либо

247: Много, в зависимости от того, какая там выберем, там war one or many t's Ван или как там. Да, да, да, да, все правильно. То есть смотрите, про что речь, сюда эту картинку сложу.

248: То есть, условно мы забрали распределённую транзакцию отсюда, но она переехала сюда, по сути, в месседжере у нас все тоже самое, та же распределённая транзакция. То есть 1

249: Что ему нужно сделать? Это выложить машину, 1 действие и 2 действие ему нужно пометить в бокс таблице, что, ну, то есть эта запись обработана, ну, условно он выложил эту запись, наши

250: И совершенно правильно. То есть тут несколько стратегий, то есть что будет? Если он выложил машину, а в бокс таблице не смог пометить, то в следующий раз там через time аут, или когда он запустится, он снова вытащит это.

251: Запись, которая не помечена обработанной и продублирует её на шину. То есть в таком варианте мы, да, не можем гарантировать, что у нас каждое событие Ровно 1 раз попадёт на шину, какие-то события могут попасть дважды на шину и другой.

252: Вариант, если мы сначала помечаем запись обработанной, да, когда мессенджеры её вычитываем, вычитывают и потом кладём машину. В этом случае другая проблема. То есть мы уже пометили запись, но по каким-то причинам

253: Не смогли выложить машину, и тогда получится, что мы пропустили некую запись. То есть 1 из 2. Либо мы не можем гарантировать единственность событий, либо мы не можем гарантировать, что все события всегда будут выложены чаще.

254: Всего идут по 1 варианту. То есть это положить что-то дважды на шину обычно лучше, чем пропустить, вообще не положить ни 1 раза. Вот это нужно учитывать, нужно иметь

255: Но, тем не менее, этот фактор достаточно распространён. Он позволяет в order сервисе не беспокоиться про распределённую транзакцию, а потом, позже там когда-нибудь это будет выложено в машину и причём с гарантией доставки, то есть не обязательно

256: Раз, может быть, 2 раза, может быть 3 раза, но точно попадёт машина. Извините, вопрос задать сама машина не может забирать, допустим, из базы данных. Нет ли таких возможностей?

257: Может, то есть, но есть варианты с триггерами, то есть мы можем навесить триггер.

258: И trigger автоматом, сам будет класть на шину, но тут тот же самый, та же самая проблема. То есть что будет триггер? Ну, если шина будет недоступна, триггер упадёт, и можно

259: Конечно, в рамках базы данных, ну, условный трайкеч сделать, да, как-то предусмотреть эту логику, но тогда получается, что у нас уже логика, вот эта логика, она внутри базы зашита. На мой взгляд, это нехорошо. Ну,

260: Это сложнее тестировать, это не явно, то есть мы на схемке не видим, что есть message, и раз уж мы делаем микросервисную систему, то обычно делают отдельный месседжер ей, а брокер может

261: Брокер сам забирать.

262: У брокера немножко другая парадигма, да, то есть он

263: Он сам доставляет, доставляет сообщения такого, чтобы он сам забирал, ну, стандартных там поставках брокеров нет, ну то есть это немножко выбивается из его философии, это транспорт доставки, а нет.

264: Паспорт опроса и забора.

265: Ну, то есть чаще всего делают, да, отдельный месседж релей. То есть этот message релей может следить не за 1 autboy, а там за несколькими, за десятками, если это большая база. Ну, условно, если у нас монолитная база, монолитный сер.

266: Все равно, может быть, мессенджеров, который заберёт эту распределённую транзакцию на себя. Ну, то есть, да, возвращаясь к вопросу через триггеры, сделать можно, но это будет не явно. И примерно те же самые вопросы.

267: Проблему придётся решать только на уровне базы внутри триггера. Это, ну, как я сказал, не явно, поэтому хуже.

268: Так, можно вопрос ещё, да, правильно понимаю в целом, что мессенджер это, по сути дела, сервис, который следит за таблицей выполнения различных операций. Оо, как просто журнал, грубо говоря, статус выполнения

269: Да, да. Ну то есть в самом простом варианте он там каждые 30 секунд читает эту таблицу, смотрит, появились ли там новые записи, не помеченные, обработанные.

270: Если появились, то помечают, выкладывают машину.

271: По сути, все вот такой вопрос. А какими средствами можно проверять то, что, например, статус? Ну, то, что, во первых, такая операция действительно была, потому что если вдруг внезапно в эту таблицу попадёт какая-то левая запись, по идее,

272: Отправится дальше сообщение в, ну, его опубликует брокер и так далее. То есть, может какие-то идентификаторы уникальные или как это можно поддерживать.

273: Угу. Так, не очень понял в целом, что бокс таблице записи все будут верные, потому что вот здесь на уровне базы данных транзакция обеспечивается, да, то есть мы не можем что-то записать в order тейбл и не записать.

274: Бокс и наоборот то есть это на уровне базы данных субд транзакции. Если вопрос про дубликацию, да, то есть чтобы дальше мы дважды не обработали какое-то 1 событие, то ну да, то есть мы можем

275: Уникальный, уникальную айдишку класть и последующие системы, которые подписаны на эти брокеры, они уже поймут, что. Ага, там с этой айдишкой такая операция уже была сделана. Но вообще базовое правило при работе с очередьми, что операции должны быть

276: Патентные, да, то есть, что если мы дважды выпол, обрабатываем одно и то же сообщение, это не должно привести к развалу системы. То есть все подписчики, они должны быть готовыми к тому, что операция задублируется. Ну то есть

277: Это не конкретно к боксу, это вообще в целом при использовании очередей больших данных, больших нагрузках.

278: Так, предлагаю дальше пойти.

279: На чем мы остановились да поговорили про оркестратор, поговорили про бокс и сейчас немножко поговорим про бизнес процессы, немножко отвлечёмся от оркестратора.

280: И попробуем реализовать оркестратор на шине данных.

281: Так, ну, условно, да, наверное, попробуем. Вот вариант с

282: Хореография реализовать, но немножко в таком своеобразном варианте, что я имею ввиду.

283: Так, сейчас.

284: Тот же самый сценарий создание заказа.

285: То есть попробуем вот, и архитектуру, ну, условно, её там, базовые заветы вывести в максимум, что ли, и вот все, вообще все ивенты закидывать на цену и через это реализовать в том числе.

286: Компенсирующий транзакции. Итак, у нас сервис создания заказа закидывает машину. Собственно, что заказ создан.

287: На эту очередь подписана подписан сервис, который зарезервирует заказы на складе, резерв товаров на складе.

288: Он читает, что-то делает. Ну да, он отвечает, что товары зарезервированы кому-то там, ну сейчас это пока пропустим дальше по последовательности создания заказа у нас, допустим, должна быть оплата.

289: Да, и мы распараллелив, то есть одновременно и резервируем, и одновременно обрабатываем оплату.

290: Я тут упрощаю, давайте там.

291: Да, наверное, чтобы не запутаться, придётся мне не совсем простой вариант нарисовать новый заказ здесь.

292: Вот здесь.

293: Товары заказа зарезервированы условно. Следующий статус заказ перевёлся. Его можно отправлять на оплату.

294: Дальше пошла оплата.

295: Ой, если оплата прошла, мы шлем в следующую очередь.

296: И, допустим, тут сборка заказа на складе.

297: Так, ну это вот допустим такой happy path, да, идеальный сценарий, когда все хорошо, давайте попробуем вот здесь какие-то предусмотреть проблемы.

298: То есть, допустим, если оплата не прошла,

299: То нам нужно что сделать.

300: Снять резерв, да, другим цветом это нарисую.

301: Оплата не прошла, нам нужно снять резерв на вкладе, потом обновить статус товара и так далее.

302: Что ещё может пойти не так на этапе сборки заказа может оказаться так, что по каким-то причинам

303: Lara не найдены.

304: При этом нужно отменить заказ. Нужно вернуть деньги.

305: И нужно каким-то образом там пометить эти товары, которые помечены, резервированы, что на самом деле они не то что зарезервированы, их вообще в целом нет.

306: И так далее. То есть мы вот сейчас рассмотрели небольшой сценарий, и у нас уже получалось, получилась вот такая достаточно объёмная схемка. Я ещё здесь хорошо нарисовал, да, то есть тут более менее все понятно, но в реальном

307: Проекте вот таких вот очередей с различными событиями, с откатами событий и так далее. Становится очень много. На 1 из проектов я столкнулся с тем, что очередей 300 и вот никаких схемок, где стрелочки

308: Нарисованы, их нет. Просто есть около там нескольких Десятков микросервисов и 300 очередей. И чтобы понять, как вообще процесс работает, какие сервисы, на какие очереди подписаны, какая последовательность вообще.

309: Вызовов этих сервисов вообще, ну, нереально сделать. То есть как это выглядит. То есть есть просто

310: Rabbit ну там был rabbit и 300 очередей.

311: И к нему подключены около не помню сколько около 50 микросервисов.

312: И каждый из них в несколько очередей что-то пишет, на несколько очередей подписан и что-то делает. Ну то есть вот в таком варианте разобраться в этом всем, ну, на мой взгляд, вообще не представляется возможным. То есть, чтобы даже просто бизнес

313: Аналитик зашёл и посмотрел, как сейчас устроен процесс. Если нигде это не отрисовано, да, ему придётся чуть ли не весь код смотреть и выстраивать, кто на что подписан. А даже если вот такая вот схемка где-то отрисована, то не факт, что она актуальна.

314: Пока ты в каждый микросервис не зайдёшь, не посмотришь, в какую очередь, что когда шлётся, на какую очередь мы подписаны, что при этом делаем? Ну то есть мы не поймём. И вот, на мой взгляд, 1 из плюсов оркестратора в том, что он из

315: Анализирует тот процесс, который есть на самом деле. Давайте ещё раз сюда скопирую. То есть, условно это даже не документация, это не какой-то там рисунок в конфлюенсе, это прям реально вот та блок схемка, по которой ходят

316: Наши процессы, наши токены. И в таком варианте бизнес аналитик может зайти и поменять ПИН схему, и она автоматом сразу же применится, да, то есть нету варианта, что мы в схемке поменяли, а в коде у нас крутится по другому, ну,

317: Потому что условно вот по этой схемке, то есть, как мы в нотации отрисовали, так все токены крутятся. То есть, на мой взгляд, вот такой основной плюс оркестраторов, ну особенно оркестраторов с визуализацией, например, бип движков в том, что мы у нас

318: Всегда есть актуальная документация, которая в целом понятна, без там, без знаний программирования даже, да, то есть системный аналитик, зная нотацию, может посмотреть и что-то даже поменять.

319: Так, но вот такой вот вариант через кучу очередей его тоже делают.

320: А, извините, можно вопрос задать? Угу. Да, да. А вот можете немного приблизить схему вашу, которую нарисовали?

321: Тему какой vpn, которую нарисовали через очереди, да, вот почему здесь товар не найдены, вот он идёт в очередь в резерв, почему он не идёт? Допустим, оплата не прошла.

322: То есть вот это очереди, да, то есть это событие, да, и на это событие подписаны сервисы, которые по этому событию что-то делают. То есть сервис оплаты по этому событию должен, ну, каким-то образом вернуть деньги.

323: Все, я понял. Резерв товаров на складе. Да, давайте я его переименую, там изменение статуса.

324: Товаров на складе.

325: Ну то есть, да, тут имелось ввиду, что товары не найдены и надо пометить, что они не зарезервированы, а их вообще нету по каким-то причинам.

326: Так, ага. А можно ещё вопросик по, вот. Угу. По схемам, нет ли такого для хореографии? То есть, чтобы была тоже схема понятная, где можно что-то там перетащить, передвинуть.

327: Хореография, ну то есть хореография суть хореографии в том, что каждый из сервисов знает, что и как среагировать, и что, и как откатить. Ну то есть каких-то инструментов.

328: Чтоб все это визуализировать, фреймворков нет, наверное, я не встречал.

329: А компании, может, большие, сами свои разрабатывают. Ну вот есть протоколы, да, вот в чате упоминался ту писи, сегодня мы его не успеем рассмотреть. То есть есть различные протоколы, ну, то есть.

330: Условно нотации, каким должен, как сказать, какие интерфейсы должен потребовать сервис, да, чтобы его подключить по данному протоколу.

331: То есть там есть какие-то, во первых, строгие требования и есть рекомендации. То есть если вот ты выполняешь 1, 2, 3, то тебя можно по вот этому протоколу использовать.

332: Вот, но сразу скажу, да, по этому протоколу я не специалист реализации этого протокола, я там подробно, наверное, не расскажу, проще его погуглить.

333: Вопрос тоже хотел задать, как визуализирующие оркестраторы, которые способны строить нотации, определяют вот как раз-таки название очередей микросервисов. Просто название, грубо говоря, там класса какого-то, который мы определили. Вот

334: Как понять, какая внутри бизнес логика, какая именно, что это именно создание заказа? Например, сейчас можно ещё раз че то не понял. Ну допустим, вы говорите, что у нас есть оркестраторы, которые способны строить визуализацию в виде определённой аннотации.

335: Угу. И вот как понять, какая именно бизнес логика внутри какого там, условно, квадратика находится? То есть вот здесь сделать запрос? Вот, да, да. Угу. Тут есть несколько вариантов. Ну, то есть

336: Условно, когда мы вот этот квадратик рисуем, мы, ну,

337: Условно подписываем на этот квадратик, то есть

338: Пишем, какие данные, куда нужно отправить. Ну, допустим, если рассматривать команду, то там свой немножко протокол очередей. И мы просто говорим, что вот этот квадратик, это такая-то очередь, ну, условно, очередь сервиса 1, а сервис 1.

339: Уже подписывается на эту очередь и исполняет. Ну, все, что в неё пришло.

340: То есть можно, да, допустим, если мы говорим про комунду, и мы встраиваем комунду в джаву приложение, мы можем прям внутри этого квадратика написать java код, но это сейчас сама комунда признала, что этот вариант хуже.

341: То есть нужно просто на каждый, ну вот квадратик, да, подписывать некий внешний вызов, как-то они называются экстернал таски, они там называются, то есть просто мы говорим, что вот этот квадратик, это такая-то external таска, и мы знаем,

342: Сервис 1 умеет исполнять экстернал Таску 1, external Таску 45. И там 92. Ну то есть 1 сервис может только 1 Таску исполнять, может несколько и по сути все, ну то есть связывается по некому иденти.

343: А там уже на уровне сети, по моему, пуллингом сообщения там доставляются.

344: Надеюсь, ответил. То есть получается, что это как автособираемое документация, которая все-таки требует участия человека, чтобы вормер именно создать подпись. Смотри.

345: То есть не то, что автособираемое, документация это наоборот. То есть сначала мы в самом коммуна модельер, есть такая утилита, то есть мы в нём вот эти вот схемки собираем и, собственно, они уже исполняются.

346: Так, сейчас попробую загуглить команда иксэмель.

347: То есть мы в BPM нотации.

348: Так, ладно, наверное, сейчас сходу не нарисую. То есть, условно мы прям в визуальном редакторе рисуем вот этот бипин.

349: Потом как это работает, и это BPM.

350: При он хранится в виде xml.

351: То есть, чтобы, ну то есть промежуточный вариант xml, который описывает вот эту вот всю блок схему и вот конкретно уже по этому xml генерируется код, который исполняет, ну код внутри команды, то есть это

352: Не автодокументация, когда мы из кода генерируем схему, а наоборот мы нарисовали схему, из неё генерируется код, но это внутри команды происходит. То есть нам это

353: Нас это вообще никак не задевает. То есть мы рисуем в модельере вот такую вот штуку, либо её редактируем и сразу же можем её там залить на сервер, на продакшн и она будет исполняться.

354: Понял. Спасибо. Так, ну давайте дальше. Про что ещё хотел рассказать? Проектирование бизнес процессов, да, вариант. И мы рассмотрели проблематика визуализации актуальности бизнес процессов. Вот, как ра,

355: Про то, что я сказал, что вот в варианте с шинами сложно очень понять, во первых, у тебя схемка актуальная или нет. Если её в принципе нету, то как это нарисовать? Тут вопрос был в чат имеет ли?

356: Смысл вообще делать с шинами на самом деле, да, имеет, когда у вас бизнес процесс не такой сложный, и там затаскивание оркестратора будет, скорее, там, оверинжинирингом, ну, то есть дополнительная точка отказа и там сложности ресурсов, он бывает

357: Нормально живёт и не настолько, как сказать, не настолько высокие нагрузки выдерживает. Если просто вариант. То есть тут надо смотреть, во первых, по нагрузке, во вторых, по сложности бизнес процесса. То есть, возможно, для каких-то простых бизнес про

358: Даже в 1 проекте у вас будет вариант вот с ивентами через шину, ну то есть такой неявным бизнес процессом, а для другого варианта со сложным бизнес процессом, но зато менее нагруженным у вас будет вариант там с коммуной либо с темпоралом. Я бы так

359: Сказал, так и про шины. То есть я тоже буду говорить про архитек с код. То есть в целом у меня есть там библиотека опенсорс, который теоретически проверяет, что схемка, она иденти.

360: Но на самом деле тому, как устроено все. То есть мы будем говорить, по моему, предпоследней лекции, вот про такой инструмент, который вот это либо визуализирует, да, по вашему коду, по вашей инфраструктуре, либо скажет, что вот

361: Ваша архитектура кода написана, она актуальна, либо скажет, что неактуальна, там у вас стрелочки нету или, наоборот, лишние.

362: То есть в целом, да, ещё раз такую схемку можно и нужно брать для простых процессов, либо нагруженных для сложных, ненагруженных, лучше комунду. Ну да, ну и надо смотреть, чтобы там комунда, либо темпорал, это не было.

363: Инженер для вашего проекта. Так что ещё хотел рассказать супер краткий обзор BPM, мне кажется, рассказал вариант с оркестратором.

364: Сейчас что ещё хотел рассказать?

365: А, ну на самом деле, да, то есть вариант с оркестратором, по сути, вот он у нас есть оркестратор, и вокруг него рои микросервис. Ну, здесь тоже мы нарисовали. Единственное, ещё хотел 1 схемку, а вот, да, ещё 2 скриншот.

366: Что-то хотел показать, то есть как, допустим, в случае с комундо это все выглядит.

367: Вот кусочек реальной схемки. И мы тут видим условно на какой операции, в каком блоке у нас сейчас какие токены. Вот здесь 1, 2, это, по моему, не айдишник, это количество, да, то есть скол

368: Токенов цветом различаются. Это токены в нормальном состоянии, которые идут по процессу другой цвет. Это токены, которые зависли, которые как раз упали в ошибку и ждут ручного исполнения. То есть

369: Как раз в комунде можно настроить автоматическое решение проблем, а можно сделать вот где мы, где мы это рисовали, когда мы ждём техподдержку.

370: То есть вот здесь вот 2 токена, они проблемные, они просто, ну они ждут, когда кто-то из техподдержки зайдёт, посмотрит, что с ними, и каким-то образом их решит по 1 токену здесь. И здесь нормальные, которые просто идут по процессу. Так.

371: И вариант тоже man, схемка с автоматическим решением проблем. Ну то есть, с вот как раз компенсирующим транзакция. Тут такой учебный пример про мосты в Питере, да?

372: То есть перекрыть мост, потом развести мост, если по каким-то причинам не получилось, да, то есть мы идём по ветке проблемной, снять перекрытия моста, начать поиск неисправности, если

373: Все хорошо. Развести мост удалось, то идём дальше, проводим корабль через мост. Опять же, если почему-то корабль не стал проходить, да, то мы сводим мост, снимаем перекрытия, ну и, возможно, ещё что-то делаем.

374: То есть в таком случае у нас токен не будет вот здесь висеть проблемный, он сразу пойдёт по проблемной, ну, по проблемной цепочке, это все в самой нотации предусмотрено и условно вот эти вот

375: Это молния или что это ну как try catch примерно на языках программирования?

376: Так, мне кажется, все рассказал, что хотел. Давайте по вопросам.

377: Сейчас в чат прочитаю, надо найти, где я остановился.

378: Так, так, так.

379: Угу.

380: Так вот, на это, по моему, ответил, как вам работа с командой или темпоро вроде все сильно жалуются, в какой момент действительно стоит затаскивать их проект. Ну, частично ответил, что мне больше всего нравится это визуализация и точное понимание, как все

381: Работает, что, ну, условно, визуализация не разъезжается с реализацией. Вот про проблемы комонды, да, то есть, если не понимать, как она работает, то будет очень много проблем и на высоконагруженный

382: Участки процессов точно не стоит её вешать, потому что она достаточно медленно медленная темпорал. Ну все, плюс минус тоже самое единственное. Он более легковесный за счёт того, что у него нету визуализации.

383: То есть он и работает побыстрее и

384: То есть, темпорал используем, наверное, когда не такие большие сложные процессы, как в комунде. То есть вот условно, вот эти вот процессы, которые здесь нарисованы. Если это все, то я бы их делал на темпорале, да, комунда, это если

385: У нас, ну, условно, примерно, раз, раз, 5, больше схемка бизнес процесса тогда уже там, потому что без визуализации, без имена уже будет сложно. Темполи, там эта блок схема, она прям кодом описывается. То есть, просто последовательность вызовов какие-то.

386: И так далее.

387: Так, ну вообще, как я и сказал, то есть и темпорал, и комунда, они забирают на себя исполнение, да, именно бизнес процесса, и это очень хорошо. То есть под исполнением, я понимаю, вот именно отслеживание.

388: Текущих состояниях экземпляров, что у нас по бизнес процессу, или это темпорал воркфлоу называется несколько экземпляров, и даже если что-то падает, что-то там временно лежит, то оркестратор никогда не забудет, где, ну, в каком

389: Состоянии находится конкретный токен, что для него исполнялось, что не исполнялось. Вот это основной плюс.

390: Так, право, только insert кажется, это неправда, я уже сейчас не скажу про что этот комментарий.

391: Кейсы, в которых куча очередей оправдан, да, про это рассказал. Простые, либо высоконагруженные, да, разного цвета, что 1 в нормальном состоянии, он исполняется, а там другой цвет, это уже токены попадали, и они дальше не

392: Пока вручную мы не зайдём. А нет, я не про это, я про цвета, которые вот красные и вот чёрные, на где мастер. Вот. А вот здесь, тут, по моему, просто разные типы операций.

393: Различным цветом помечены. То есть вот здесь вот конвертик, да, немного ниже.

394: Так, ниже вот здесь. Да, да, да, тут, да, тоже надо смотреть нотацию я наизусть уже не помню, к сожалению, это разные типы ошибок. Ну то есть здесь прям любая ошибка, да, а здесь какая-то контролируемая

395: Ошибка, ну или выбор из, ну.

396: Ну точно не подскажу, может, это и ошибка на схеме скриншот. Ну откуда я брал?

397: То есть нотация, она достаточно большая, то есть там очень много всего нотации, всю нотацию, там все блоки, я честно скажу, даже не знаю.

398: Так, хореография не тормозит из за увеличения количества операций. Есть ли случаи, когда это правда? На самом деле все естественно, тормозит при увеличении сложности, при увеличении количества операций, проверок и так далее. То есть бесплатно ничего не бывает, нет.

399: Какой-то серебряной пули, которая вам и распределённую транзакцию выполнит как надо, и ещё и будет супер быстрый и без каких-то проблем.

400: То есть, да, у всего есть свои там и плюсы, и минусы.

401: Так, ну, по сути, про хореографию, то есть некий вариант хореографии мы вот здесь и рассмотрели. То есть тут, ну, тут

402: Различные сообщения доставляются через очереди, а каждый из сервисов уже умеет реагировать на каждое сообщение. То есть в примере по ссылке там были именно сообщения о том, что нужно создать драфт процесса, там что-то

403: Кодировать, забронировать, а тут получается оплата, она умеет списывать деньги и умеет ревертить списание, то есть возвращать деньги.

404: Так, по моему, из чата на все ответил, если нет, то продублируйте, либо там задайте голосом, либо напишите в telegram. Руслан, можно вот уточнить, я в начале спрашивал, видимо, это прилетело. Вот мне уже

405: Которую лекцию интересует вот микросервис крут, именно его реализация. То есть это как какой-то тупой микросервис, грубо говоря, который балансирует запросы к базе, или же там реализована какая-то логика конкретно вот под эту базу. Угу. Вот.

406: Да, смотрите, да, давайте про крут. Мне кажется, я забыл немножко про это рассказать. То есть крут, в чем его задача? Его задача быть единственным единственной точкой доступа к данным.

407: В чем суть? То есть он вывешивает какое-то конкретное апи, да, то есть, что вот у нас есть такие-то эндпоинты, можно заказ создать, можно там, не знаю, ему поменять статус и можно, ну, к примеру, не знаю, количество товаров увеличить, да?

408: То есть он предоставляет конкретные операции уже в доменной логике товаров. Конкретные оо, ну то есть в нём нет никакой бизнес логики, это будут просто там апдейты в базе, но суть в том, что если мы разным сервисам предоставляем

409: Доступ к базе, да, они могут творить все, что угодно. Ну, то есть они могут выполнить любой эскуэль, проапдейтить любые поля у товаров, там, сделать какой-то инсерт в 1 таблицу, не сделать в другую и так далее. Получается, что

410: Все сервисы должны будут знать, как правильно работать с этой базой. Это во первых. То есть, когда мы подключаемся всеми сервисами к базе, да, то есть мы на данными можем сделать все, что угодно крут, он очень сильно ограничивает те операции, которые

411: Можно сделать с базой данными, условно поменять статус, да, то есть удалить запись нельзя. Можно её пометить удалённо, да, то есть, если бы мы напрямую в базу это ходили, то все сервисы должны были бы это знать. А так мы

412: Point удаление, а на самом деле он только помечает удалённым и так далее. То есть его задача ограничить, защитить данные с 1 стороны, с другой стороны.

413: Запросы, они всегда должны быть, ну, особенно высоконагруженные, они должны быть, как сказать, ну, допустим, те же индексы внутри базы данных, они должны быть заточены под запрос, ну, либо, наоборот, запросы заточены под индексы.

414: Да, и как раз крут, он знает внутреннее устройство базы. Он знает, какие там индексы, и определённым образом может сформировать запрос, чтобы они попадали в индекс, а не там, ну, соответственно, не делали. Фуллскан, серч, ну,

415: Тоже самое, да, то есть, если бы мы всеми сервисами входили напрямую в базу, то пришлось бы либо индексы затачивать под все сервисы, да, либо всем сервисам объяснять, как правильно сделать выборку, сделать поиск. То есть все эти знания

416: Которые не нужны внешним сервисам, они инкапсулируются внутри круда, и он ограничивает доступ к данным только по тем методам, по которым правильно работать с данными. Вот надеюсь, ответил

417: Ну, вообще это просто, да, то есть это эндпоинты, да, и которые преобразуются в какие-то запросы. А можно вот уточнить, допустим, если там нужно какой-нибудь специфичный отчёт сделать, то есть вот, вот этот

418: Тут он реализует просто получение данных и уже journey джойним и где-то вот за его пределами. Угу. Ну тут обычно некий баланс. То есть если мы

419: Все-таки джоины обычно внутри круда. То есть, если мы понимаем, что нам нужны не просто товары, а товары, там с джоина, соединённые со складами, да, условно, что вот этот товар есть на таких-то складах, то мы этот джоин внутри круда сделаем, ну и будет.

420: Какой-то point там товары плюс склады.

421: Если это какая-то сложная выборка, сложная, ну то есть, ну да, чаще всего джоин внутри склада. То есть если это какой-то отчёт, то внутри него может быть джоин из разных Кладов крудов. Условно мы отсюда забрали

422: Товары и склады отсюда забрали заказы. Ну, естественно, джоинить мы будем в отчётах, потому что это данные из разных мастер систем.

423: Да, собственная мастер система. Ну, логичнее в круде. Джой, будь.

424: То есть это не бизнес логика, это просто представление данных в удобном для потребителя виде. Так, окей, правильно понимаю? То есть, что если, допустим, нам требуется какая-то сложная логика, вот, допустим, ну, какой-то эффективный запрос, то, условно, м,

425: Ну, допустим, если отвечают за команду отчёта, вот, которая только работает со складами, когда я говорю команде круда, что вот нам такое нужно, сделайте такой запрос.

426: Ну, то есть, если нету эндпоинта, который покрывает потребность потребителя, то да, нужно в круде добавить ещё 1 эндпоинт, который, не знаю, там товары со складами ещё с чем-нибудь выдаёт.

427: Ну, главное, чтобы логики не было. То есть, это может быть логика выборки, но не бизнес логика. Условно, что нужно загрузить склады. Если там, не знаю, сегодня суббота, то подгрузить только там те склады, которые

428: Работает по субботам. Ну, сейчас сходу фантазируем. Угу. Вот этот флаг, допустим, там выходной, не выходной, он должен извне выходить, а уже по этому флагу крут, может отфильтровать, а не то, что крут. Смотрит в календарь. Какой сегодня день подтяги.

429: Календарь праздников и в зависимости от этого выбирает свои данные. Ага, спасибо. Ещё вот нормально будет решение, допустим, сделать крут склада, допустим, как graphql, сервис, который смотрит на ба.

430: Данных и выдаёт эту модель. Ну, в целом, да, графкюэл меня немножко смущает, что, ну, я вот точно не помню, там в первых версиях там точно не было ограничения. То есть можно было вообще любые данные в любом виде.

431: Доставать. И часто мы если революционную базу используем, то такие запросы они в индекс не попадали. Ну, условно, потому что фронтент, либо потребитель формирует какие-то критерии, по которым мы ищем, а естественно,

432: Мы не можем индексы подстроить под все варианты поиска, но в целом какой-то сервис, да, можно рассматривать как крут. Если для вашей задачи не критично, то почему нет?

433: Спасибо. Так, у нас время на сегодня закончилось. Вроде на вопросы поотвечал. Из чата тоже. Если да, вопросы остаются, то пишите в чат. Напомню, что завтра у нас будет

434: 1 практика, все тогда так и по поводу досок, которые в общем пространстве были заведены, я в чат напишу, их надо будет перенести.

435: По поводу завтрашнего дня можно спросить, да, завтра можно показывать уже какие-то наработки по проектам, и как это примерно будет по организации, по, может быть.

436: Очерёдность, что-то такое. Угу. Ну, обычно самоорганизуемся. То есть, как это происходит? Расшариваем экран, да, то есть тот, кто показывает, расшаривает экран, комментирует и дальше уже задаёт вопросы. Либо я

437: Задаю вопросы, как-то комментирую и так далее. Просто обсуждаем схемку.

438: Ну, если прям очень много народу на практике такое бывает ближе к защите, то, да, там вначале каким-то образом выстраиваемся в очередь и договариваемся, что на каждую группу, допустим, не больше 15 минут. Ну, я думаю, на первых практиках точно такого не будет. Угу.

439: Все понятно. Спасибо. Угу. Все тогда. Да. Всем до завтра. До свидания. Спасибо. До свидания. До свидания. Спасибо. До свидания. С. До свидания.