0: Ребят, как меня слышно? Подтвердите, пожалуйста.
1: Отлично, отлично. Что ж, тогда не будем затягивать и начнём, как обычно, по классике. Я вам пошарю экран, и мы начнём с вами разбирать тему. Давайте я буквально только убежусь.
2: В том, что у нас все работает и мы можем начинать
3: Собственно.
4: Итак, я думаю, что ребят.
5: Можно постепенно переходить. Собственно, о чем мы сегодня с вами будем разговаривать. Все вы собрались послушать про микросервисы. Понятное дело, микросервисы дело нелёгкое и в современном мире в 26 году
6: Ходит очень много за и против. Одни говорят, микросервисы избыточные, они слишком сложные. Другие говорят, микросервисы это круто. Они позволяют нам масштабироваться, эффективно использовать память. Есть люди, которые говорят, http,
7: Умер, нужно переходить на кафку и в принципе эйчтитипи это очень плохо, и tcp это вообще просто днище полнейшее, но все эти люди одновременно правы и неправы, как это можно?
8: Идентифицировать, как можно понять, почему одни говорят правильные вещи, а другие нет. Самый верный путь это разобраться в том, как микросервисы составляются, какие проблемы они решают и, главное, перед вами какие
9: Стоят проблемы, которые вам приходится я бы так изучать или решать во время обучения вашего индивидуального, либо при выполнении ваших непосредственных должностных.
10: Обязанностей. Сегодня в качестве примера, чтобы показать вот эти должностные, те самые должностные обязанности, мы с вами возьмём не супер сложную тему и поговорим о том, я бы сказал бы, даже очень популярную. Поговорим о том, как создать заказ и
11: И затем отправить этот заказ в обработку платёжной системе. Представим себе. Поэтому мы немножко порисуем перед тем, как мы перейдём к коду и более техническим решениям. Ведь любые микросервисы, монолиты модулит, всегда начинаются с системного дизайна.
12: Но главное здесь вы должны понимать, как происходит, как устроена система и как выполняется дейта флоу. Начнём с простого. У нас с вами есть человек, который делает заказ.
13: А это клиент условный. Давайте не хочет писать чик чик чуть чуть её уплотним.
14: Так, есть. Ага. Шрифт маленький. Так, так, так, так, так.
15: Маленький шрифт это отлично. Почему, почему такой маленький шрифт? 1 секундочку, ребята, у меня почему-то не хочет. А понятно почему маленький, потому что я зазумить у нас
16: У нас есть с вами клиент, он, разумеется, совершает заказ какой-то, и его флоу выглядит следующим образом в сторону какого-нибудь order сервиса ордер.
17: Сервис у него тоже есть своё время. Соответственно, у него, вероятно, есть какая-то база данных, потому что нужно хранить так или иначе ордера где-нибудь и есть ещё.
18: Какой-либо платёжный сервис, который располагается удалённо или где-то рядом, это нас не интересует. Назовём его пеймент.
19: Сервис у каждого из них есть, понятно, свой flow, асинхронный либо синхронный по отношению к 1, либо другому нас это сейчас не сильно интересует начнём мы с клиента соответственно, клиент выполняет запрос по созданию.
20: Заказ, то есть создать заказ, это ордер или креит, это неважно. Можно для простоты назвать его кре. Соответственно, ордер, сервис должен его каким-то образом обработать. У него начинается процесс какой
21: В конечном итоге он приводит к тому, что сохранить базу данных сейф дейта или safe ордер ну, разумеется, далее мы получаем или отправляем ответ на клиента.
22: Здесь респонс, да, окнок нас не интересует, успешно это или провально. Нам важно, что этот процесс был. И, разумеется, вот это пространство, которое сейчас выделено красным цветом.
23: Это как раз и есть тот самый синхронный процесс. Почему мы говорим здесь именно о синхронном процессе? Это крайне важно. Когда вы работаете как клиент, то с большой долей вероятности вы что-то кликаете на графическом интерфейсе вашего браузера.
24: Веб аппликухи какой-то, иначе говоря либо телефон. Соответственно вам нужно постучаться в какой-то gateway как правило это ипиай гейтвэй, неважно для чего. И это 1 точка коммуникации, которая проходит между клиентом и бэкендом, то есть она как правило,
25: Сорри, синхронно, именно по этой причине здесь я сделаю вам отметку эйчтитипи. Те, кто не любят. Вернее, те, кто считает, что http не подходит для микросервисов, можете уже начинать в меня кидаться камнями.
26: При этом придумайте для комментария, я бы сказал бы хорошее обоснование, почему http или rest api в целом плохо для микросервиса, но у нас система такова далее, разумеется, мы с вами говорим о том,
27: Вот, пришёл запрос по созданию заказа, необходимо сделать какой-то процесс, здесь мы его сохраним, этот. И ещё мы добавим небольшую стрелочку, к сожалению. Ага, нет, стоп, вот так вот небольшую стрелочку.
28: Которая будет указывать, куда ты пропала. Ага. Которая будет указывать на то, что происходит какой-то процесс. К сожалению, она у меня выгибается. Странно, страшно. Ну то есть это мы назовём процессинг, да, то есть
29: And процесс бэк энд процесс.
30: Процессинг или ладно, или процесс. Вот так, да, то есть мы не обращаемся ни в какие сторонние сервисы. Для нас это абсолютно нормальная ситуация и нам необходимо просто обработать что-то, вероятно, данные
31: Отменить дтошки, заменить и потом сохранить в базу данных. Но в рамках нашего с вами конкретного примера нам необходимо, безусловно, эту историю добавить тем, что мы с вами сохранили заказ. Все отли.
32: Но теперь необходимо его отправить в обработку в пеймент сервис. И это может быть асинхронным. Это может быть абсолютно асинхронный процесс. То есть мы не будем ждать ответа.
33: Для чёткости я покажу, что здесь от базы данных мы ждём ответ, потому что соединение с базой данных, оно, разумеется, синхронно. И здесь мы не коммит коммит или роллбэк, да, или роллбэк. Ну,
34: В зависимости от ситуации, как нам повезло, не повезло. Мы это сейчас не обсуждаем. И в конечном итоге, после того, как у нас произошёл коммит ролл бэк, все, синхронщина заканчивается, мы отправляем запрос прямиком в
35: Сервис и здесь на publish паблиш ивент ивент у нас простой
36: Order криейт.
37: Зачем это нужно? Все просто логично. Мы с вами собираемся, мы с вами собираемся уведомить пеймент сервис для начала обработки платежа. Представим себе, что в системе у нас уже есть все данные клиента, его карты.
38: Сивишкин это верификационные коды, которые необходимы, то есть все окей, он в системе правильно заведён, никаких проблем с данных у нас нету в отношении данных клиента. Это, условно говоря, у вас есть на гитхабе подписка диджитал оушен, подписка google.
39: Клауды какие-нибудь подписка. И вас раз в месяц, разумеется, чарджит какая-то компания, снимает с вашего счета деньги за услуги. Ну, допустим, спотифай все, что угодно. Это для всех. Сегодня вполне себе понятная схема. И вот в ордерах
40: Когда вы через, допустим, какой-то онлайн сервис заказываете, новый продукт, сапоги, телефон. Это работает приблизительно таким же образом. Понятно, у нас очень упрощённая система, но мы сходимся в том, что в данном конкретном примере
41: У нас в данном конкретном примере мы подразумеваем, что с данными пользователя все в порядке. Мы не занимаемся работой, связанной с обработкой платежа. Нам главное уведомить, чтобы она началась. А теперь посмотрим внимательно. Вот у нас во
42: Как бы готовая система и вроде все окей, но мы же здесь с вами собрались разбирать микросервисную архитектуру. Мы видим, у нас здесь есть 2 выраженных ярко микросервиса. 1 это у нас, разумеется, ордер сервис и 2 это пеймент сервис, это
43: 2 микросервиса. У каждого есть своя ответственность. Здесь у вас сомнений быть не должно. Они деплоятся отдельно, вероятно, независимо друг от друга и разрабатываются независимыми командами, но микросервисы приносят
44: Пользу, масштабирование, независимая разработка, возможность, вероятно, выбирать различные технологии, подходы. И в принципе, это влияет на скорость. Доставку призвано влиять на скорость, доставку, но в то же время это несёт комплексность комплексити.
45: Сложность выражается в том, что чем больше у вас микросервисов, тем сложнее ваша система. То есть, с 1 стороны, мы хотим улучшить нашу систему, но улучшение чего-то будет стоить в монолите. Все просто здесь мы не будем сильно останавливаться. Скажу, чт
46: Все в 1 легко дебажить, легко деплоить всего лишь 1 артефакт. Сложно масштабировать в зависимости от конкретной нужды разрабатывает 1 команда и очень длительный цикл доставки и, главное, большие расходы на тестирование.
47: И в целом на поддержку. Поэтому как бы мы пришли к микросервисам, чтобы многие из этих проблем или челленджей преодолеть, но вместе с этим возникают проблемы. И давайте поговорим об этих проблемах, которые у нас возникают. Для этого нарисуем не супер сложную
48: Крестик супер красного цвета, который будем массивно эксплуатировать для того, чтобы показать, где у нас возникают проблемы. 1, 1 проблема.
49: Сеть, сеть это всегда друзья. Опасно не потому, что там ходят всякие бродяги, злоумышленники, иначе говоря, а потому, что сеть может оборваться, она нестабильна. Представим себе ситуацию. Клиент посылает запрос по какой-то причине.
50: Запрос обрывается, но он все-таки достиг сервис, но при этом клиент об этом не знает. То есть, раз у нас возникает проблема, это может произойти по разным причинам. Допустим, 1.
51: Причина это таймаут по какой-то причине провисла сеть. И именно в этот момент, когда вы отправили запрос от клиента в order сервис, это заняло очень большое количество времени для обработки, поэтому клиент оборвал соединение по причине
52: Ну, давайте здесь я добавлю оо посередине, если, конечно, влезет, не влезет. Судя по всему. Ну, я напишу, мы не сдаёмся. Тайм аут, да, случается, бывает, есть. Безусловно, может.
53: Просто сеть, ворваться грубо. Или же вы потом ещё делаете повторные попытки, потому что зачастую после тайм аута хочется повторить попытку. Здесь сразу хочется отметить 1 простую вещь. Если мы говорим с вами про создание объектов новых, то есть
54: Что-то пытаетесь инициировать в базе данных, изменить состояние, создать новое состояние ретрай паттерн, связанный с микросервисной архитектурой. И не только это очень плохо. То есть вот мы с вами повстречались с 1
55: Шаблоном проектирования ретрай паттерн. Если вы что-либо создаёте ретрай, это всегда плохо. В этом случае лучше этого не делать. Почему? Потому что ретрай паттерн эффективно работает при получении данных. То есть, иначе говоря, когд
56: Вы не можете системе причинить какие-то побочные эффекты. С другой стороны, так или иначе, ретрай, скорее всего, с точки зрения клиента все равно будет. Ну то есть вы пытаетесь сохранить ордер, добавить его, у вас грузится
57: Грузится окно, но ничего не происходит. И потом, бах, попробуйте ещё раз при этом всем. То есть, когда вы в следующий раз будете создавать заказ, вероятнее всего. То есть это уже будет система расцениваться как не повтор, а абсолютно новая, но это все за
58: Зависит от того, как устроена система и как те самые архитекторы ордер сервиса определяли эйпиай. Это очень много значит, но, тем не менее, тайм аут может произойти. И, разумеется, это может причинить ситуацию, где, повторюсь ещё раз, клиент
59: Не знает, был ли запрос, доставлен его статус, и поэтому, что он делает правильно, он делает, соответственно, ретрай да, то есть здесь мы можем в случае таймаута я это опущу, оно вот так будет, и здесь будет red рай.
60: В случае ретрая вы отправляете все такой же заказ, и, разумеется, какие есть проблемы? Есть проблема следующая, что если ваш сервис недостаточно идемпотентен иначе,
61: Говоря, он не умеет отличать 1 состояние от другого. Предположим, у вас пришло, пришёл запрос на создание какого-то заказа. Вы его благополучно сохранили в базу данных. Он действительно новый, но затем к вам пришёл точно такой же заказ. И вы
62: Взяли, опять же, его сохранили в базу данных. То есть у вас в базе данных 2 одинаковых заказа. И как раз retry вот эту историю может причинить. Не могу сказать, что сам по себе ретрай плох, в нём никакой проблемы нету. Проблемы начинаются когда
63: Мы, разумеется, неправильно это используем, и retry как результат таймаута может причинить повторное создание, иначе говоря, дубликат может создать в базе данных здесь.
64: Сразу возникает намёк, каким образом это все решать и, соответственно, товарищем, который за нас это все будет решать. Мы его будем рисовать зелёным цветом. Это будет идемпотентный.
65: И демпо, и демпо тёнки это ещё 1 шаблон проектирования, который призван решать проблемы, и они как раз
66: Очень тесно связаны с тем, что таймауты причиняют желание повторить запрос. Иногда есть другие причины, по которым повторяются запрос, но, как правило, это нестабильная сеть. Разумеется, если ваша ипиай спроектирована.
67: Правильно, то api должен быть устойчивым и, главное, идемпотентным при создании запро, при создании каких-либо ресурсов. В нашем случае ресурс это ордер, это тот самый шаблон проектирования, который
68: Вам необходимо закладывать практически всегда. Если вы говорите о том, что у вас есть api, рестовой или http, и не только на самом деле, оно может быть асинхронное. Допустим, между, где вы коммуницируете через-ка.
69: Q иначе скажу когда у вас есть операция, которая создаёт или изменяет состояние, вам всегда нужно побеспокоиться о идемпотенции этой операции, иначе говоря, ввести вот этот идемпотентный ключ, поскольку
70: Благодаря нему вы сможете удостовериться в том, что в случае ретрая, повторной операции по какой-либо причине у вас не будет создаваться дубликат, вы его либо обновите. Предположим, если в этом есть необходимо
71: Либо вы сразу же ответите клиенту, что это уже обработано. Вот твой результат. Держи, пожалуйста, как бы это даже улучшит нам производительность. И вот как бы 1 момент. И ещё 1, повторюсь, шаблон, шаблон проектирования часто приме,
72: Меняющийся в проектировании микросервисов. 1 был тайм аут. То есть, с 1 стороны, тайм аут это у нас шаблон проектирования. Вернее, это проблема, которая возникает коннекшн таймаут. С другой стороны, вот есть у нас такой товарищ, который называется ретрай паттерн, я его так здесь отмечу.
73: И он тоже является частью микросервисной архитектуры, хотя и применялся задолго до неё. На самом деле много че притащили из монолита. Че работало здесь в скобочках? Давайте поставлю, что отмечу, что это тоже паттерн, чтобы вы пони,
74: С другой стороны, тайм аут кстати, тоже может быть паттерном, то есть connection time аут здесь, уточню, он тайм аут или это может быть респонс тайм аут тоже. То есть с 1 стороны вы не могли подключиться по какой т.
75: Причине или с другой стороны вы отправили запрос, но так и не дождались ответа, но сам по себе таймаут тоже, между прочим, является паттерном. Его принято считать, и он говорит о том, что каждый раз, когда вы устанавливаете соединение как клиент с сервером,
76: Вам нужно побеспокоиться о том, чтобы настроить таймауты на соединение и на ответы. Это очень важно, это не столько про микросервисную архитектуру, но в том числе паттерн, который в неё закладывается. Почему? Потому что многие системы по умолчанию
77: Имеют бесконечный тайм аут, допустим, когда я давно работал с php, если мне не изменяет память, там реально бесконечный тайм аут стоял, и если вы его не настроите, то, соответственно, все запросы будут висеть бесконечно сервис завис ресур.
78: Отжираются, приходят новые и новые запросы. Разумеется, система перенагружается и в итоге падает. Вот. Но здесь мы таймаут обсуждать как кейс. Я имею ввиду тайм аут паттерн как кейсы.
79: Мы не будем вот, но будем двигаться дальше с шаблонами проектирования. Вроде, казалось, мы решили с вами идемпотентность. То есть мы предусмотрели это, мы реализовали паттерн инпатент кии.
80: Мы точно знаем, если у нас придёт 2 одинаковых запроса, то мы и это можем идентифицировать. И, разумеется, 2 * 1 и тоже обрабатывать не будем. К этому шаблону применяются абсолютно разные подходы. Что такое идемпотентность? Здесь нет чёткого
81: Определение сам паттерн гласит просто 1 2 одинаковых запроса это 1 и та же сущность. Соответственно, должен быть способ это идентифицировать позже в коде мы посмотрим, как это реализовано у меня, но разные системы ещё раз
82: Повторюсь, они определяют это по разному и по разному это отражают в своём api вот теперь следующее представим себе, что вроде окей, импотентность есть, но мы же с вами говорим о том, что нам необходимо уведо.
83: Сервис пеймент сервис о том, что у нас с вами все отлично пожалуйста оплатите сервис, как это сделать ну типичный разработчик разумеется.
84: Сохранился в базу данных отлично. Вообще мега и потом как-то асинхронно параллельно или в конце паблишит, соответственно, ивент в кафку в rabbitmq в моём примере будем использовать кафку, но это не ограничивается.
85: И, опять же, здесь могут произойти следующие проблемы. 1 из этих проблем. Соответственно, это, опять же, сеть. Ну, сеть, в принципе, это всегда проблема для любого разработчика и любого инж, опа.
86: И любого инженера вот так вот наш крестик подхватим, поэтому сходу здесь можем поставить Крест на этом всем. Опять же у нас сеть упала. То есть мы здесь
87: Допустим, нетворк оо напишу так нетворк эро.
88: Это 1 проблема, которая может произойти. Если вы думаете, что Кавка вас от этого защитит, я вас огорчу. Кавка никогда вас от этого не защитит. С чем это связано? С тем, что Кавка тоже работает в сети. Многие думают и ошибочно думают, что
89: Якобы асинхронная коммуникация разрешает проблемы, которые присущи в http, потому что в http сеть нестабильна, и якобы мы можем по http оборвать сеть. Разумеется, это принесёт проблемы, а с кафкой этого не будет. Это
90: Ложь, потому что Кавка все также работает в сети и kafka все также может потерять соединение с сетью, соответственно вы запаблишить ивент, предположим, какой-то красивый, и при этом всем вы никогда не доставите это сооб.
91: Сервис это 1 ситуация, 2 ситуация заключается в том, что вы, предположим, отправили успешно этот ивент. Все отлично, здорово, никаких проблем с этим нету.
92: Но по какой-то причине произошёл роллбэк и вот прямо здесь я его отмечу красным не как операцию с точки зрения базы данных, а именно как точнее. Ну давайте транзакшн, фейлор, трансфер, вот так, ну и соответственно, произо.
93: Откуда в принципе, знает пеймент сервис? Что произошло в order сервисе? Ничего он о нём не знает. Соответственно, вы сначала успешно проверили идемпотентность. Окей, такой транзакции нет. Попробовали?
94: Сохранить в базу данных. Параллельно посылаете событие, соответственно, асинхронное в пеймент сервис. И в этот самый момент у вас происходит сбой в транзакции, который, соответственно, приводит к чему. Правильно я
95: Я уже сказал кбк, это тоже проблема. Проблема выражается в чем правильно. Суть заключается в том, что пеймент, сервис, как я уже сказал, никогда не узнает о том, что у вас произошло в order сервисе.
96: Иначе говоря, ордер или заказ не существует, но оплатить его нужно или или, или противоположная сторона, с которой я начал ордер, существует, но оплата не происходит, потому что произошёл.
97: Сбой и, разумеется, даже в code no поинте ресепшен вылетает, и, разумеется, пеймент сервис никогда не узнает об этой оплате. То, что о ней нужно побеспокоиться, поскольку все операция завершена, клиент уведомлен.
98: Спасибо. Вы успешно купили новый велосипед, но при этом всем оплата не производится, и никто не знает, че с этим делать. Реально проблема для бизнеса. Вот такие вот ситуации негативные могут встречаться. Как эту проблему решить?
99: Простейший способ это друзья аут бокс, паттерн, аут, бокс, паттерн. Благодаря нему есть возможность предусмотреть все эти проблемы, которые я только что описал, на случай того, что
100: Оборвётся транзакция и пеймент сервис по какой-то причине не получит своё сообщение или, напротив, пеймент сервис уже знает о том, что есть заказ, но при этом всем заказ по какой-то причине не создался и произошёл
101: Back. Как раз именно вот эту проблему нам может помочь решить аутборд му, что он довольно-таки прост. В комбинации с идемпотентностью можно с лёгкостью преодолеть все эти проблемы.
102: Бежать дубликатов и в том числе говорить о таких гарантиях доставки оо стратегии гарантия доставки такой как at least once at least, once, я думаю, многие уже слышали.
103: Она называется atlas, пишется таким образом и, переводя по простому хотя бы 1 раз. Что это значит, это значит, в сущности своей, что такое сообщение будет отправлено как минимум 1 раз, не идёт.
104: Речи о доставке. Здесь речь идёт об отправлении. Это значит, что данные данная стратегия гарантии доставки подразумевает дубликаты, дубликаты, как могут, могут быть, да, могут, могут быть
105: И это реально проблема. Особенно это проблема для платёжных систем, для, ну, все, что связано с деньгами. И в таком бизнесе, это может причинить дубликаты. И дальше уже, я бы сказал бы, несогласованность, несогласованность данных разу.
106: По причине дубликатов и в целом, чуть подвину и в целом неправильная работа системы, да, неправильная работа системы, это в том числе, может повлечь, разумеется, когда мы говорим
107: Говорим о такой гарантии доставки, нам нужно это все предусматривать в целом в комбинации идемпотентный ключ нам позволяет это решить, поскольку в нашем случае ордер сервис является идемпотентным сервисом, мы говорим, что у него есть api оно
108: Он рестовый, коммуникация по http, я уже сказал, могут быть повторы и, разумеется, нам необходимо здесь. И, разумеется, мы говорим о том, что будет этот лист. Уанс из за этих повторов и нужно предусмотреть идемпотентность. Мы это решили с другой.
109: Нам крайне важно с вами в случае ошибок, связанных с публикацией ивентов, тоже предусмотреть эт лист ванс. Почему это важно, поскольку в данном случае из за каких-то ошибок в коде
110: Ещё чего-либо. Сообщение, к сожалению, может быть отправлено и через кафку. Несколько раз. Такое тоже случается. И не будем здесь привязываться исключительно к кафке. Любая система по какой-либо причине может одно и то же сообщение, даже в асинхронном стиле.
111: Отправить несколько раз. Опять же, как я уже вам сказал, вы успешно запули овали в кафку что-то, но потом кафка отвалилась. Она отправила сообщение к своему подписчику, не знает, было ли оно доставлено.
112: Эколодж не получила, потому что связь оборвалась и начинает повторять его ещё раз. Соответственно, это вот может возникнуть дубликат разумеется, это тоже нужно предусматривать, и гарантия at least once нам помогает на этом сфокусироваться, то есть при проектировании систем.
113: Темы. Нам просто необходимо держать это все в голове. Сам по себе, аутборд. Он позволяет нам разрешить вопросы дубликата и организовать гарантию доставки. Он не решает.
114: Он говорит о том, что даже если произойдёт какой-либо сбой, мы не приведём систему в неконсистентное или в несогласованное состояние, а несогласованное состояние это когда ордер сервис знает, что есть заказ, а пеймент сервис не знает.
115: Или наоборот пеймент сервис знает, что есть заказ, а order сервис его уже отменил разумеется вот это есть несогласованность данных, особенно в распределённой системе и out бокс паттерн это будет решать, поскольку здесь механизм работы
116: Это некогда, иначе сперва сохраняются данные атомарно. Давайте нарисуем это в отдельном блоке есть наш, наша с вами база данных и есть наш.
117: Опа пеймент сервис и нарисуем это с позиции не будем трогать клиента, он нас сейчас не интересует и нарисуем это с позиции соответственно вот так вот.
118: Да, потерял. Угу.
119: Есть.
120: Начинается обработка. Вот она, родная, пошла. Соответственно, 1, что мы пытаемся сделать, выполнить сохранение в базу данных.
121: Safe, ордер готово, затем нам необходимо дождаться ответа. Ну, ведь мы знаем, он будет, скорее всего, да, здесь, разумеется, коммит рок, в зависимости от ситуации. Ну, будем.
122: Что все окей. Далее мы с вами делаем ещё 1 операцию. Соответственно, я бы сказал бы здесь не комитал бэк confirm. Вот так бы я бы сказал, конформ в этом конкретном случае или эколодж.
123: Далее мы делаем с вами сейф аут бокс ивент или просто out box для сокращения тоже ждём с вами эколодж и соответственно это то, чем
124: Гарантируем с вами достойный ответ на эти трудности. Главное здесь отметить. Очень важно отметить то, что вот, вот эта операция, отмечу, зелёным бэкграундом она
125: Является атомарной, да, то есть это
126: Atomic оп это атомарная операция. И, как вы понимаете, она должна увенчаться коммитом, коммитом либо роллбэком в зависимости от того, что произошло.
127: Здесь понятно, конкретно сейчас отправим на кварт бэк, да, вот так здесь понятно, у нас вместе с тэкнолоджи может быть, ещё nuk это вполне нормально, ну.
128: Ввиду операция не удалась, я это имею ввиду. И если хоть 1 из этих операций не удалась, то, разумеется, мы делаем рубэк и все. И на этом, друзья, все мы больше, как бы таким образом мы чётко с вами гарантируем, что order сохранён.
129: Если сохранён, то мы затем помещаем специально в дополнительную таблицу. Абокс, как правило, называется, может быть по разному событие, которое затем должно быть синхронно отправлено в пеймент сервис и далее пока
130: Все ещё клиент ждёт здесь, мы чуть чуть продлим его страдания. Клиент все ещё ждёт, ждёт, ждёт. Ой, ой, ой, покосилось все, сейчас я это исправлю. Так, чуть чуть эти палки, ёлки выровняем, готово. И после этого мы можем
131: Уже отвечать клиенту. Здесь был реквест, да?
132: Рек, а здесь, соответственно, респонс
133: Response параллельно после того, как мы это завершим, мы с вами можем выполнить ещё 1 операцию внутреннюю, почему внутреннюю, поскольку нам для этого не нужен никакой сторонний сервис, это опера.
134: Будет связана с обработкой. То есть нам необходимо с вами подготовиться к обработке. У нас с вами будет background. Процесс он не связанный с запросом ни в коем, ни в коем случае. Я бы его назвал бы
135: Скедулер скедулер или schedule task, при помощи которой будет считываться данные из базы данных.
136: И здесь мы будем брать хетч, аут бокс. И далее это абсолютно не связано с клиентом. Как я уже сказал, это отдельная операция на бэкграунде, поэтому она называется скед, таск, и я бы
137: В общем, назвал бы, ой, слово такое фоновая, да, фоновая операция, фоновая, фоновая операция. Соответственно, вот так мы сначала получаем доступ к базе данных. Понятно? Она синхронная.
138: Все ещё она ещё все ееще синхронная, но она клиента не затрагивает. То есть мы получили доступ к базе данных. Отлично. Затем она продолжается какое-то время вот здесь вот так и после этого, когда мы сформировали
139: Окончательно запрос, то есть мы знаем что все точно у нас есть в autox необработанные записи, мы спокойно это друзья, отправляем в наш пеймент сервис и в ответ разумеется полу.
140: Получаем эколодж, да, то есть, окей, принято, ну, если никаких ошибок нету, да, то есть я all publish.
141: Publish и здесь эколодж.
142: Готово. Так можно делать в цикле механизм. Каким образом обрабатывать огромное количество запросов фоново мы здесь обсуждать не будем. Здесь речь идёт только о шаблонах проектирования. Конкретно здесь ещё раз, друзья, напомню, мы здесь говорили про
143: Out бокс паттерн.
144: И это его, собственно, реализация. Как это можно сделать, чтобы уточнить это, я бы сказал бы, усвоить здесь хочется проговорить ещё раз, 1 и ту же вещь, которую я уже сказал, недавн.
145: Out бокс паттерн в 1 очередь решает несогласованность данных, то есть система не должна приходить в несогласованное состояние и в том числе, если у вас будут несогласованно будет несогласованное состояние, это может привести к неправильной работе системы или к её
146: Падению целиком разумеется в этом и есть задача autox паттерна, чтобы не получилось так что 1 операция выполнилась, а другая с ней связанная, провалилась и вовсе не знает о том, что 1 выполнилась или наоборот 2 выполняется.
147: Какой-то причине, a1 уже откатилась или почему-то она не выполнилась. И, разумеется, поскольку мы говорим о распределённых сервисах, ведь это дистрибуция, это микросервис, 1, микросервис 2. Они друг о друге ничего не знают. Понятно, здесь кто-то может сказать, чт.
148: Ладно, можно устроить обмен сообщениями на уровне кафки или чего-нибудь другого, что пошлёт ордер. Сервис получит ответ от пеймент сервис. Да, так можно сделать. Но таким образом, мы, в принципе, лишаем систему возмо.
149: Быть асинхронным асинхронный в каком-то в какой-то степени, а с другой стороны вы создаёте таким образом, вы создадите просто больше проблем, поскольку клиенту важно дождаться ответа, что все окей, все готово.
150: Сохранён. Ему не важно, что платёж происходит здесь и сейчас. Платёж может произойти через 5 секунд, через час, через полтора часа, если мы говорим про e commerce платежи, поэтому его это интересует, не интересует. И, разумеется, нам не нужно так.
151: Связывать между собой ордер, сервис и пеймент сервис и out бокс паттерн позволяет нам сделать вот этот декаплинг ещё более безопасным. Вот как друзья это выглядит ещё раз перечислю мы с вами только что обсудили несколько шаблонов.
152: Проектирование 1 это time аут, он здесь не отражён, он на клиентской части, мы её здесь не обсуждаем. Напоминаю, что таймаут паттерн это шаблон, который призван обеспечивать достаточное время для ожидания, но не делать его бесконечным, как правило.
153: Это полминутки и все. Далее мы обсудили косвенно ретрай паттерн, то есть это паттерн, который позволяет повторить запрос в случае необходимости, но этот паттерн приносит негативную сторону. Позитивные, негативные. Негативная сторона это
154: Что он может привести к созданию дубликата именно по этой причине, как я уже отметил, ретрай лучше делать именно чистый ретрай 1 и того же запроса лучше делать, когда вы получаете ресурсы, а не создаёте их.
155: В случае вам нужно будет пересматривать каждый раз в рамках 1 и того же заказа, который не получилось доставить. Вам нужно будет пересматривать его состояние. Это накладывает неудобства и определённую логику заказами. Проще его отправить.
156: Удостовериться, что сервер его принял, если не принял, то лучше считать такой заказ провальным, отметить его в каком-то логе на фронтенде и все и попробовать его ещё раз создать с новым id тогда мы точно будем уверены, что не будет.
157: Никаких дубликатов. Ну и при этом всем, даже если сеть по сети клиент отправляет несколько раз одно и то же, такое тоже может произойти, нам необходимо делать сервисы и в частности, ипиай устойчивыми. В нашем случае мы говорим про дру.
158: Шаблон проектирования импатентки или импатентный ключ, задачей которого является обеспечение стабильного устойчивого эйпиай, при котором один и тот же объект не будет создан. Несколько раз напоминаю, что если мы используем с вами рест,
159: Http, а именно пост метод для создания объектов, то он, разумеется, не идемпотентный. Это его природа. Сколько раз его выполните, вот столько раз и будет создан объект там есть, я бы сказал бы, лайфхаки как можно его превратит.
160: В псевдо идемпотентный, но это уже не про шаблон проектирования и demand ключ и последний шаблон проектирования, 4 это autox паттерн, который мы здесь расписали более детально, его задача как
161: Как я уже сказал, избежать ситуации, когда система приводится в несогласованное состояние, и это в конечном итоге приводит к её неправильной работе или в целом потере её ценности, вплоть до отказа вот как это.
162: А сейчас, думаю, пора перейти к вопросам. Уделим этому немного времени, после этого поговорим о коде и о способах реализации, и это будет завершать.
163: Завершающая часть нашего с вами сегодняшнего вебинара. Так, кидайте запросы, запросы, вопросы. Я с радостью на них всех отвечу. Так, так, так, так, так, есть.
164: Вот хороший вопрос, чисто из практики если у меня моя табличка out бокс оказалась пустой, все ордеры, все ордеры обработались и новые не поступали, то получается мой шедулер.
165: Будет просто так слать запросы в базу, как быть в такой ситуации. Но это class хороший вопрос. Мы его не будем затрагивать технически именно в этом вебинаре, потому что он требует более внима. Я бы сказал бы, он требует
166: Большего времени и другого контекста. Здесь мы можем говорить про бэч процессинг, но отвечу на него, потому что в моём коде вот как раз такая же ситуация с отметкой туду. Вот как именно ты описал, как это лучше делать необходимо, как я уже сказал,
167: Организовывать бэч процессинг, когда, во первых, мы сможем получать данные безопасно, не перегружая базу данных. То есть мы будем выдёргивать какой-то определённый объём, если там что-то есть и его складывать к
168: Будущему будущей обработке. Это 1, это, это про стабильность разумеется мы предполагаем то, что в базе данных может не быть абсолютно событий никаких. Это тоже нормально для
169: В принципе, можно внедрить ориентир событийно ориентированный механизм, то есть событие, создать, допустим, out, box crate и положить его в какое-то хранилище, хранилище, не базу данных.
170: Потому что опять же мы ходим в базу данных, полить мы её не хотим, допустим, в какую-то очередь rabbitmq, эскью эс от амазона и складывать туда соответствующие ивенты о том, что поступил вот такой вот.
171: Таким образом, у вас появится хранилище, которое будет наполняться информацией о том, что реально есть в базе. Но опять же, это огромный кусок кода, это огромный кусок функционала, затем начнётся асинхронная обработка, что ваш опять же какой-то
172: Он будет слушать соответствующую очередь, это, как по мне, поэффективней, чем каждый раз обращаться в базу, он будет слушать, соответственно, очередь получать оттуда айдишки и затем уже на основании грамотно настроен.
173: Индексации в бд и правильного построенного запроса эскьюэль или другого нового эскьюэль можно будет получить именно те данные, которые вас интересуют. Это вот 1 из подходов. Безусловно, подход полить базу данных по скед. 1 из вариантов. Вот, вот я
174: Именно так и реализовал, но это связано с тем, что нас сейчас эта тема не интересует, но я бы попробовал бы на твоём месте вот такой вариант.
175: Хорошо. Так, друзья, будут ли ещё какие-то вопросы по существу технических или все понятно? Все отлично. Если все так, то это нормально. Тема довольно-таки обширная. Полагаю, у кого-то это может даже вызвать взрыв.
176: Мозга, но в целом это окей, как я уже сказал. Ладно, будем тогда двигаться дальше, начнём с простого, начнём с самого простого. У нас есть с вами код, да, у меня сейчас есть
177: Только order сервис, и нам, его вполне себе достаточно 1, с чего нужно начать в проектировании любого эйпиай, каким образом мы будем строить этот api, потому что он должен быть устойчивым, версионируемым.
178: И главное вы строите эйпиай не для себя, вы строите эйпиай для клиентов несмотря на то, что вы якобы стейкхолдер этого api, вы за него отвечаете, вы его строите для клиентов и очень важно поддерживаться.
179: Контракту, придерживаться контракту, обратной совместимости. Она, как правило, в себя включает бэкворд и форвард компатибилити, и в том числе необходимо в это закладывать ситуацию, связанную с версионированием, чтобы, если что, то
180: Случилось, то, соответственно, была возможность это провалидировать, и клиент мог тоже, опять же, получить доступ к актуальной схеме. Как это можно сделать. Для этого существуют друзья, специальные риджестри, они так называются. Схема риджестри.
181: Перед вами эйпиай курио, и это очень простая Тула. Она в буквальном смысле слова хранит схемы в разных форматах. Форматы тут абсолютно разнообразные Авро граф кюэль.
182: Джейсон кафка, опен эйпиай протобаф и понеслось то есть все, что в принципе сегодня есть и чем мы довольствуемся, мы будем с вами использовать json просто потому, что он простой, понятный, в отличие от протобаф да, у джейсона есть.
183: Достатки а у протобаф есть как бы а у протобафа они тоже есть это связано с тем, что protobuf нечитабельный для человека, а json отлично подходит для презентаций там, где нужно глазами что-то смотреть, поэтому мы
184: Берём его. Это единственная причина, почему так произойдёт. В противном случае для асинхронной коммуникации. Я бы, вероятно, взял бы авра, но это уже отдельный топик. Какие структуры выбирать? Поговорим про ипиай, который мы
185: Используем для rest за основу я взял стандарт open api specification это стандарт, который определяет, как будет, который декларирует, как будет выглядеть ваш рест api для этого я создал собственно яму.
186: Он выглядит вот следующим образом. И здесь он представлен в явном формате. Как я уже сказал, здесь описываются операции, ответы, примеры запросов. И не только здесь, что немаловажно, есть версия.
187: Этого api это то, что можно впоследствии контролировать и делать сопоставление. У вас версия, которую вы сейчас используете, она является совместимой с той, которую использует бэкэнд, или нет. Поэтому
188: Именно используют риджестри. Почему все просто, друзья, вы когда собираете свой проект, когда ваш сиайсиди происходит, вы вот это все скачиваете из риджестри, так же самое, как и ваши клиенты. И затем на основании этого вы генерируете код, также его Гене.
189: Клиент и, разумеется, это точка контроля и единая точка хранения, во вторых, это разбивает тесную связь между api и бэкендом и между клиентом и api.
190: Скачивайте его. То, что есть, вы видите версию. Вот здесь даже есть версионирование. Мы видим лейтест пока что она у меня 1, разумеется. Но это 1 из причин, почему, а вернее, некоторые из причин, почему необходимо делать. Так это называется.
191: Устойчивое, предсказуемое эйпиай, то есть проектирование, казалось бы, все начинает сразу с кода. Но нет, по хорошему так не надо. Затем, разумеется, мы, если воспользуемся вспомогательными тулами для разработки или
192: Для тестирования, то у нас появится вот такая вот красивая юайка, она уже работает, она уже все запущено. Ну, был здесь, разумеется, мы используем спрингбут под капотом, и он нам это обеспечивает, но опять
193: Все основано на open api спецификации и на Туле, которая называется сваггер как мы видим, здесь вот есть полное описание нашей спеки, как выглядят запросы, какие разнообразные ответы, собственно, могут быть вот примеры этих самых ответов и так.
194: Далее и так далее еже с ним это очень полезно, потому что вы можете таким образом без какого-то кодинга увидеть как ожидать, что ожидать от вашего api, а версионирование соответственно, которое используется для этого api, позволяет вам.
195: Как клиенту понять, что от этого ожидать во вторых, здесь есть объекты дтохи так так званые, и вам не нужно будет их создавать руками вы все можете при помощи open api спецификации.
196: Весь фронтенд, понятно, я не говорю про под фронтендом. Я имею ввиду контроллеры, делегаты и дто. Кстати, клиентскую часть вы тоже можете сгенерировать. То есть меньше кода больше вы полагаетесь уже на схему?
197: И вот этот риджестри, он этому помогает в коде, это выглядит очень просто. На самом то деле мы откроем наш не супер сложный. 1 секундочку. Да, так есть, да, вот он.
198: Мы откроем с вами не супер сложный проект ордер сервис здесь я использую мейвин для простоты и вот у меня есть 1 плагин, который выкачивает этот api ордер сервис опен эйпиай ямал, он его выкачивает, точнее, вот откуда его выкачивает.
199: И в корневом проекте, в корневом модуле здесь есть путь. Понятное дело, здесь все захардкожено, но нас это сейчас не беспокоит. Мы не говорим про, как правильно деплоить. Мы говорим о том, как проектировать систему. Это уже детали.
200: Реализация нас мало интересует. Соответственно, вот этот плагин мейвин антран, он позволяет выкачать нам спеку, что важно, это не самый лучший выбор конкретно для этой презентации он
201: Простой, короткий, но у api курио есть свой отдельный плагин, который можно использовать для скачивания зависимостей, для тестирования этих зависимостей и для загрузки новых зависимостей, если не зависимостей схем, если
202: Необходимо. Далее я использую следующий плагин, который называется open api тулс для генерации кода. То есть я ни в коем случае не хочу руками создавать контроллеры это только повод для ошибок, поэтому мы сначала скачиваем
203: Схему, потом на основе этой схемы, которая скачается, мы генерируем бэкенд. Если мы откроем папочку таргет, то мы найдём, да, вот generators, вот срц, вот моя джава. И вот, собственно, что
204: У нас есть, у нас есть все модели, обращаю ваше внимание допустим, крейт ордер реквест, вот, пожалуйста, они все сгенерированы мне руками. Делать ничего не надо, и если я открою соответственно open api, swagger, ui. Точнее вот он.
205: Пожалуйста, тот самый крейт крейт, ордер реквест. Вот он, красивый каренси и items, соответственно, это все. Вот они, опять же, каренси айтемс. Все делается из 1 файла, который скачивается из регистра.
206: Также он позволяет нам сгенерить контроллер самостоятельно и собственно делегат. Затем нам остаётся всего лишь то реализовать вот этот делегат, что не супер сложно. На самом деле сегодня можно его сгенерить ручками. Я имею ручками сгенерить при помощи чата.
207: Это не супер сложная история. Вот так вот это 1, с чего нужно начинать, это не столько про шаблоны проектирования, это про проектирование систем, в том числе микросервисных. Почему это так важно? Почему я затронул эту историю? Мы говорим про микросервис микросерв.
208: Сервисы очень часто переиспользуют одни и те же модели, иначе говоря, схемы. Разумеется, 1 способ, которым решает классический разработчик. Как по мне эту проблему он создаёт какую-то библиотечку и в неё туда
209: Все, потом он в эту библиотеку поддерживает от зависимости, фиксит эти зависимости, релизит её, постоянно беспокоится о том, чтобы все об этом знали. Это приносит очень большой бордель. Вот так у меня на самом деле на проекте современ.
210: Происходит потому, что так вот оно начиналось, есть возможность это решить и возможность это решить, это как раз тот самый avi, курио или другой схема риджестри, где вы можете располагать свои ивенты, и потом в безопасной форме и, главное, с контролем.
211: Версионирование, распространять их, насколько микросервисов, насколько вам заблагоразумится. То есть это очень важная часть в проектировании любой микросервисной архитектуры, либо api, который предназначен для клиентов, допустим, даже для монолитов, это тоже
212: Вот это 1 часть, не супер сложная. Как видите, поехали, посмотрим, как выглядит у нас идемпотентность. Идемпотентность довольно-таки проста. В нашем случае у нас с вами есть несколько
213: Прошу прощения, не то у нас есть с вами база данных и у нас есть с вами специальная табличка, там уже есть, я тестировал какие-то данные, сегодня с ней таблица называется pi.
214: Records. Называйте её как хотите, но суть заключается в чем? Давайте откроем для примера эйпиай рекард, и мы её вот так откроем, чтобы можно было отдельно смотреть, что мы здесь.
215: У нас есть идемпотентный ключ. У нас есть с вами фингер принт. У нас есть с вами статус order id, респонс боди респонс код и её как раз тот самый идемпотентный ключ это то, что мы создаём с вами изначально в
216: Api потому что если вы посмотрите в схему поста ордер, здесь лежит в основе обязательный хедер реквайред, его имя и импотенции кии, и, собственно, вот как он красиво выглядит, мы используем для этого стандарт юай айди.
217: Тем, разумеется, вот этот ключ инициирует клиент, и этот ключ ляжет в основу нашего соответственного совет. Прошу прощения, нашего соответствующего заказа. И вот он, собственно, последний заказ.
218: Когда я тестировал, что здесь ещё важно, крейт тет, я думаю, никого не интересует. Это базовая история. Ордер айди. Это то, что генерируется на стороне бэкенда. Соответственно, потому что только мы знаем ордер айди, куда интереснее. Другая история.
219: Во первых, фингер принт, что это такое и зачем здесь респонс боди? Давайте для этого посмотрим в order сервис и быстренько протестируем эту историю. 1 секундочку посмотрю, че там так.
220: Сам по себе фингер принт нам нужен для того, чтобы друзья идентифицировать. А тот ли это запрос. По сути, мы здесь говорим про хэш. Реализация довольно простая. Мы
221: С вами, с ха. И берём, и буквально хэшируем весь запрос. Ситуация следующая. В чем негативная ситуация? Почему это важно? Вы можете послать один и тот же идемпотентный ключ. Вам никто не запрещает 2 раза послать один и тот же ключ.
222: Но при этом вы можете послать другое тело запроса. Соответственно, если у вас ключ есть, он есть в базе, но тело запроса отличается, то это новый запрос. Разумеется, это необходимо отклонить. Это явно приведёт систему в нерабочее состояние.
223: Или ещё чем похуже, но это явно плохо именно по этой причине мы сначала генерим так называемый фингер принт или hash, затем мы по импотентному ключу сравниваем, существует ли запись, ну просто её ищем.
224: И в конечном итоге мы делаем сравнение. Если ключи хэши не соответствуют, то мы просто выбрасываем исключение и потом конкретно в этом примере его захендлить и выглядит вот это.
225: Как, то есть импотенции, конфликт эксепшн, и он вернёт эйчтитипи 409, соответственно, конфликт. Спросите ли вы меня, почему 409? Потому что этот код идентифицирует конфликтные ситуации, но, с другой стороны, это
226: Не столь важно, важно то, как вы задокументируете этот api у меня это все задокументировано везде, ну то есть, если мы откроем с вами ордер, посмотрим, какие есть исходы 201, опять же 201.
227: 202. Есть так же самое, 400, 409 и 500. Каждый имеет, разумеется, на бэкграунде свою, какую? Своё какое-то описание. Это просто пример, это и вот эти коды, набор операций, очень тёс.
228: Связанные с проектированием api и как его архитекторы или разработчики видят, поэтому это может отличаться, но главное из этого всего то, что конкретно здесь мы говорим о том, что если у вас есть импатентный ключ, всегда связывайте его с
229: Finger принтом или с хэшом, как вам легче называть, для того, чтобы сравнить пейло или тело запроса, потому что оно реально может отличаться. 2 момент, на который я изначально обратил внимание. Друзья мои, это безусловно,
230: Body. Зачем нам респонс боди? В нашем случае конкретно здесь мы видим респонс боди выглядит следующим образом. Айдиа это идентификатор запроса, ордер айди, иначе говоря, и понеслась там атомы и так далее, и так далее. Короче,
231: Иначе говоря, здесь сохранён джейсон, если мы с вами откроем ответ примера, который я создавал относительно недавно, то вот он выглядит вот таким образом. То есть вот айдишка создалась, и все. И вы спросите меня, закономер.
232: Макс, зачем тебе в импотентном ключе, когда ты это реализуешь? Вообще, эта фича? Какая, какая в ней ценность, ценность, друзья мои, что ни на есть самое важное, и идея заключается в том, что
233: Как правило, когда мы говорим с вами про идемпотентный ипиай не ключ, а api, который на один и тот же запрос должен отвечать 1 и тем же ответом, то это необходимо обеспечить, ситуация простая вы отправили запрос.
234: Он вроде бы сохранился. Все окей, проблем нет. Затем вы отправляете точно такой же запрос с точно таким же телом, но вам возвращается другой ответ, потому что между этим заказ обработался и, вероятно, поменял из поменял.
235: Из статуса нью в статус in progress. И здесь нарушается принцип димпатие, которая чётко заявляет о том, что на один и тот же запрос должен быть один и тот же ответ. Но опять же, это очень тесно связано с
236: Если во время проектирования такого api архитекторы аналитики говорят, что окей, для клиента это не важно, нормально так будет, что вы отправите один и тот же запрос, он не сохранится дважды, но ответ может поменяться.
237: И клиент умеет это хендлить, тогда, окей. Но если мы говорим про платёжные системы, ну, допустим, ордер, сервис, это связано с платежом, потому что вы что-то покупаете, то, как правило, там требуется точность. И вот, допустим, такая система, как страйп платежи.
238: Она чётко идентифицирует у себя, что на один и тот же запрос вы всегда получите один и тот же ответ, вне зависимости от статуса текущего именно по этой причине в бд при депоте ключах, как правило, принято сохранять респонс, потому что если что-то поменять.
239: Впоследствии в ордерах заказах, то на этот запрос вы будете иметь точно такой же ответ. Иногда применяется титиль, называется time to live, и это точно должно быть идентифицировано в айпиай, это другой подход.
240: Патентных ключей, что если вы хотите, допустим, возвращать один и тот же response body, но все-таки с какого-то периода вам нужно показывать актуальный результат при выполнении этой же операции. Пост я имею ввиду
241: То в таком случае устанавливается идиль, он точно идентифицируется в api, это клиент на это только реагирует, он это условно не устанавливает как параметр это предположим.
242: Кейс следующий, что в течение суток, если вы будете отправлять один и тот же запрос на создание заказа, вы всегда будете получать один и тот же ответ. Если он был, конечно же, обработан успешно. Если, разумеется, сутки прошли, то уже
243: Со следующего дня вы можете получать другой ответ, допустим, статус поменять. Ну вот, собственно, это очень важно. Также принято сохранять респонс код. Это все тоже об этом же здесь просто выделено в отдельную колоночку. И у нас с вами есть. Понятно?
244: Статус complete. То есть, чтобы понять, чего от этого ждать, статуса этого может не быть. Но все остальные вещи, которые я вам перечислил, это именно то, на что нужно обращать внимание при создании идемпотентного эйпиай и применения.
245: Паттерна и импатентный ключ вот так вот друзья как видите не супер сложно но в то же время насыщенно и многие вещи нужно учитывать казалось бы типа rest api непонятно зачем вообще это нужно кто это сегодня использует?
246: Никто. Никому это не интересно. На самом деле используют многие друзья, особенно в платёжных системах. Точка вхождения в платежи, она всегда является синхронной, так или иначе, потому что нужно дождаться ответа, как правило, на стороне.
247: Клиента, а вот обработка уже происходит в фоновом режиме асинхронно, поэтому здесь тоже очень важно все эти моменты предусматривать. И как видите, вы пришли с вопросом, какие микросервисы реально сегодня использую
248: В мире, в продакшене. И теперь вы знаете, как их реализовывать и, соответственно, каким образом, какие моменты необходимо предусматривать в вашей архитектуре. Если вас интересует практика, разумеется,
249: Где этому всему можно научиться то, как обычно, друзья, врываемся в торговый торговый центр, в учебную платформу i. Проди, там есть 2 офигеннейших курса 1 про микросервисы, где разбираются детально шаблоны проектирования, в том числе.
250: Кстати, идемпотентный ключ и 2 это командная разработка, где вы разрабатываете и and, and доставляете, имеется ввиду с развёртыванием небольшую микро, вернее, небольшую систему, связанную с микросервисами, небольшую, потому что не потому что
251: Она очень маленькая, потому что там нетту 1000 микросервисов, но их там достаточно, включая разные базы данных, разные шаблоны проектирования и кубернетис. Поэтому, друзья, врывайтесь, ссылочка в описании, заполняйте форму, поверьте, там супер интересно и
252: Пройдя эти курсы, вы уж точно научитесь делать не хуже, чем я, а, вероятно, даже лучше. А теперь давайте перейдём к вопросу связанными с идемпотентными ключами. Вижу, тут немножко накопилось. Так проект в гите можно будет?
253: Посмотреть. Думаю, что да, скоро можно будет конкретно. Сейчас я его не хочу публиковать, потому что он грязный, и я предпочитаю его довести чуть чуть дома, но думаю, что в ближайшее время я его опубликую.
254: Кому интересно, просто напишите мне в личку или напишите менеджеру лучше i, проди, который вам поможет с этой историей, но он будет опубликован, просто можете подписаться, допустим, на мой github, как вариант.
255: Ну или написать мне в личку. Так ту ту ту вижу 2 вопрос технический нормально, что id генерирует не хайбернейт в конструкторе, а мы его из контроллера генерируем, из контроллера хайбернейт.
256: В конструкторе. Ну давайте мы ещё не, мы не добирались до хайбернейт, но на самом деле это не тема наша, наша. Ну давайте посмотрим, я открою ордер сервис и увидим, поговорим более предметно. То есть мы здесь
257: Создаём с вами запись и дом патентный ключ. Это у нас ok order id, мы здесь создаём это тоже окей. И далее мы начинаем с вами подготовку к созданию самого ордера и здесь, в коде мы с вами
258: Сразу видим, почему так важно иметь генерацию не в хайбернейт, а непосредственно в коде. Ситуация такова, что order id должен быть разделён между вот этой иденпотентно тью.
259: Запись в бд, а в том числе и с самим ордером. Разумеется, здесь ситуация следующая, что создать быстрее ордер или запись идемпотентности, разумеется, запись идемпотентности имеет
260: Более высокий риск на провал. Я имею ввиду, что её надо быстро создать, если её не будет, то есть возникает риск создания дубликата, поэтому мы сразу сходу её создаём. Это крайне важно, друзья, и разумеется,
261: Мы для этого генерируем ордер айди и потом, соответственно, мы этот же ордер айди передаём в хайбернейт. Здесь на самом деле закладывается небольшой, я б сказал бы, гэп, который может быть
262: Связан со следующей ситуацией теоретически, чисто теоретически, если у вас есть 2 или 3 или более экземпляров ордер сервиса, и они одновременно вот именно в ту же наносекунду создали ордер.
263: То они будут одинаковы, но там, там на самом деле такая энтропия, как говорит мой коллега, что, скорее всего, этого не произойдёт. Но шанс такой может быть, чтобы избежать проблемы с дубликатами ордера айди.
264: Идентификаторов. Тогда нужно реализовывать сервис, который будет генерировать дистрибутивные, стабильные, устойчивые, уникальные айдишки. Но это, я бы сказал бы, про системный дизайн. Это не тема этого урока или этого вебинара.
265: Точнее, поэтому мы это отбросим. А моё пояснение следующее, что нам необходим один и тот же ордер айди между 2 разными записями. Поэтому, а поскольку идемпотентную запись нужно создать как можно быстрее, поэтому мы создаём это не в хайбернейт.
266: Непосредственно здесь, допустим, с проектом, которым я работаю, я имею ввиду на своей привычной работе проектирование и разработка платёжного шлюза, мы там не генерируем айдишки через
267: Или через, ну, какими-либо другими способами, поскольку генерация айдишки происходит ещё раньше, чем мы сохраним что-либо в базу данных. Это тоже нормальный подход здесь негативного, ну, здесь отторжения никакого быть не должно.
268: Так, следующий вопрос. Как гарантируется идемпотентность ключей? Но вопрос как будто бы с подвохом? Как гарантируется идемпотентность идемпотентных ключей в 1 очередь?
269: Должен быть просто устойчивый алгоритм, как генерировать эту айдишку? Зачастую ключ генерируется. В нашем случае пример очень, я бы сказал бы, примитивный. Вот он, да, то есть мы видим, что нам идемпотентный ключ переходит
270: От клиента сам клиент генерирует изначально ключ по алгоритму мы его не обязываем мы ему говорим пожалуйста используй стандарт ю ай айди uuid и пере.
271: Мы его будем использовать как идентификатор идемпотентного ключа, он же идемпотентный ключ, но опять же здесь можно попасть в ситуацию, когда множество параллельных клиентов создадут один и тот же ключ, потому что энтропия не сработала, здесь опять же можно навязать
272: Клиенту требования к использованию какого-нибудь сервиса, который обязательно сгенерирует уникальный ключ стабильно. И вот это нам решит проблему. В нашем случае он очень просто
273: То случай мы просим клиента сгенерить этот ключ, и он в нашем конкретном примере будет беспокоиться о его, разумеется, идемпотентности. Вот о чем идёт речь. Ну далее мы его сохраняем в бд соответ.
274: Теперь идём дальше. Мы с вами поговорили про, соответственно, импотентность. Мы поговорили с вами о том, как обеспечить это все, как это выглядит в коде, в примере.
275: Теперь пришла пора поговорить про out бокс паттерн, аут бокс паттерн не супер сложная история на самом деле не сложнее, чем импатентный ключ, и для этого у нас существует специальное событие autox ивен.
276: И база данных здесь. Давайте на примере схемы я покажу, как это выглядит. То есть опять же у нас с вами есть id. Ну понятное дело, если посмотреть, как он создаётся, мы опять же используем
277: Uuid для генерации здесь вот кстати, можно было бы использовать хайбернейт как конкретно для этого случая, но опять же это пример ясное дело, его можно всегда улучшать агрегейшн нас будет ордер это.
278: Важно, поскольку аут бокс события тоже необходимо каким-то образом анализировать, агрегировать, и чем больше метаданных вы заложите, тем легче вам будет этим всем управлять. Агрегейшн нас, собственно, будет id ордер.
279: Здесь никакой информации об идемпотентности не надо, потому что уже идемпотентность позади. Далее мы устанавливаем ивент тайп. В нашем случае он здесь захардкожен. Не самый лучший пример, но это и не принципиально. Мы видим здесь. Напи.
280: Order криейтед в odin откуда вот эта история, ордер криейтед в 1 идёт. Это друзья идёт из апих, который мы создавали. Поскольку вот наш ордер, криейтед ивент версии 1 для него
281: Мы используем так называемую джейсон схему, которая описывает его структуру, она не супер сложная, мы видим какие параметры реквайред и так далее, какие эдишенл есть и additional properties или нет, учитываем их и пошло перечи.
282: Соответственно, этих всех параметров. Затем эту схему мы впоследствии можем использовать на стороне подписчика, который будет принимать запрос на организацию платежа.
283: И в том числе на нашей стороне, когда мы это будем отправлять. И опять же, друзья, это про декаплинг между клиентом сервером и между подписчиком и публикующим, то есть продюсер и вот так это
284: Это уже не open api, это просто джейсон схема можно, безусловно, представить это в ямле. Вот так это будет выглядеть, но формате джейсон схема. Затем можно, разумеется, из этого генерировать тоже дто опять же, это требует кода, но это
285: Лучше, лучше генерировать схему на основании. Вернее лучше генерировать код на основании схемы, чем писать код руками, а потом его везде править. Таким образом можно обеспечить версионировано и автоматизацию, и стабильность. Далее, разумеется, когда мы
286: Идём по out box, здесь у нас не супер, все сложно. Мы с вами видим следующее мы создаём ивент, заполняем его event type это, по сути, имя ивента и его версия ещё немаловажно. Можно
287: Версию включить непосредственно в метаинформацию схемы, но всего лишь 1 из Приёмов, как это реализовывать, есть множество разных способов, но так или иначе вы должны уяснить 1 любая друзья, схема должна обладать
288: Версии, потому что благодаря версии вы сможете идентифицировать совместимость или несовместимость 2 коммуницирующих объектов между собой. Далее мы туда упаковываем пэйлот, который, собственно, должен быть затем отправлен в сторону.
289: Подписчика и соответственно статус, что это new это как раз вопрос, который был задан с самого начала, а нам нужно полить ивенты и мы на самом деле в моей реализации мы это и делаем, это не самый
290: Крутой вариант, но какой есть он самый простой у нас есть простой event репозиторий, абокс, репозиторий. Мы достаём топ 50 с статусом нью и затем тупо, но рабочая схема в цикле.
291: Начинаем их в кафку посылать в качестве схемы для кафки мы используем пейлод тот самый, который сохранён вот здесь, да, мы видим ивент айди и прочая история. То есть вот он такой сокращённый. Далее
292: Разумеется, мы используем ивент тайп, потому что event type это для нас, в том числе топик, который мы с вами создали, потому что все, вы знаете, в кафке есть топики и агрегейшн оо это без.
293: Оно ключ, потому что нам необходимо с вами по ключу это все дело потом выбирать. Напоминаю, что в нашем случае агрегейшн, оо, друзья, ордер айди, они эквивалентны. Вот, ну не супер, все сложно. Затем просто обновляется статус.
294: Самого ивента и обратно. Он сохраняется в бокс ивент репозиторий. И в моём случае они уже все saint. Ну потому что это был просто банально. Пример, который я тестировал, если посмотреть соответственно в кафку.
295: Вот она моя красивая. Откроем, посмотрим топики. Вот у меня есть топика целых 3 штуки. И мы видим, что у нас есть вот 3 сообщения и 1 из них последнее как раз давайте посмотрим этот
296: Самый месседж, вот его структура. Обращаю внимание, что здесь мы затрагиваем с вами событийно ориентированное проектирование. И вы наверняка удивитесь, Макс, а почему здесь нету информации о элемент?
297: Заказа потому что на самом то деле, если посмотреть, когда я отправлял запрос здесь был айтом да, product id его ску продакт нейм квонтити и unit price ну и все, но задайтесь вопросом друзья, а зачем пеймент сервису зна.
298: Какие элементы есть внутри? Пеймен сервиса интересует только 1 сколько нужно заплатить и куда заплатить, соответственно, и за что заплатить, чтобы сделать эту проводку? Больше ничего. Поэтому, когда вы используете событийно ориентированное проектировании,
299: 1 делом вам необходимо побеспокоиться о метаинформации. То есть событие имеет схему. Разумеется, должно иметь версию 2 момент. Вам необходимо побеспокоиться о том, чтобы событие было как можно меньше, потому что передавать
300: Лишние байты это тоже дорого стоит, это увеличивает в конечном итоге летенси, ну то есть задержку, так называемые расходы на это все. Поэтому отправляйте только те ивенты в том объёме, я имею ввиду в той форме, в которой это действительно необходимо.
301: Не нужно туда доставлять информацию, которую никто использовать не будет. Поэтому чем проще ваши ивенты, тем на самом деле лучше. Разумеется. Теперь мы видим, что в топике собрались события. Вот они здесь упакованы.
302: Также здесь есть так называемый длт делетер топик. Это, это на случай того, если не удалось по какой-либо причине обработать, отправить сообщение. Ну то не сообщение, а событие. Так вот.
303: Тоже случается это не предмет сегодняшнего разговора, но это всегда нужно предусматривать, таким образом, мы видим как работает наш не супер сложный autox паттерн, его реализовать намного проще чем кажется, но есть множество.
304: Нюансов, которые связаны с обеспечением стабильности в коде. 1 из них вы уже подсветили грамотно, и мне это нравится. А что, если у меня нет
305: Записей в базе данных. А что, если записей очень много, а как часто мне ходить в базу данных? А что вот, допустим, в коде, как у меня здесь написано, что произойдёт, если вдруг в процессе отправки 1 сообщения вылетит исключ.
306: То есть, получается, все 50 сообщений зафейлятся, вернее, все 49 из 1 зафейлятся. Ну, тоже странно. То есть это все необходимо обрабатывать. Умело нужно выстраивать так называемую ретрай. Логику нужно обрабатывать.
307: Нужно выбирать из базы данных эффективно, необязательно это должна быть sql, это может быть носкл, затем вам необходимо устойчивое хранилище, временное и дешёвое, главное для того, чтобы складывать задачи туда ну.
308: Я сразу сказал, когда это был вопрос, можно использовать очередь дистрибутивную таким образом, что сначала вы готовите, вы отправляете событие о том, что в очередь, окей, пора бы обработать что-то потом она, разумеется,
309: Собирается достаточное количество ивентов. Предположим, как вариант, и уже по их айдишкам выполняется запрос в базу данных, и вы сразу получаете все эти ивенты, которые вас вам необходимы. Либо все 50, либо 28. Если время истекло, это
310: Так называемое окно и затем посылаете их дальше уже в кафку есть и другие механизмы, как это делать. Мы можем это обсуждать бесконечно долго, но это не тема сегодняшней нашей встречи. Это я вам оставлю.
311: На подумать, в любом случае, где-нибудь, на каком-то вебинаре мы это друзья, с вами затронем. Вот так вот. Безусловно, что ещё хотел ответить? Отметить. Необходимо, друзья, на каждом чихе предусматривать
312: Транзакционность, потому что мы с вами в самом начале говорили про ролбеки и коммиты, атомарные операции и крайне важно сейф ордер сейф бокс сделать как 1 атомарную операцию и только после этого выполнять
313: Уже, соответственно, все остальные операции, связанные с отправкой сообщений в сторону платёжного сервиса или какого-либо другого сервиса. В этом суть autox паттерна. Именно по этой причине у нас с вами стоит аннотация транзакшн. И здесь у нас есть, допустим, для
314: Получение данных у нас с вами есть транзакшн в режиме read only поэтому это все учитывайте если вы используете спринг, нужно использовать транзакшн менеджер для этого ну или хайбернейт, точнее хотел сказать хайбернейт, а не spring в комбинации со spring.
315: Нужно использовать менеджер для транзакции, этим умело управлять либо отлаживать какие-то кастомные, я бы сказал бы, ручные способы организации транзакционности и управления ею. Там есть разные подходы, но опять же, это не
316: Тема сегодняшнего вебинара, но это то, на что бы я бы хотел бы обратить ваше внимание. Вот так вот, друзья, что ж, мы подошли с вами к концу. Это то, что я вам хотел показать, рассказать, я уверен теперь
317: Многие из вас смотрят абсолютно иначе на тему, связанную с микросервисами, что, во первых, эйчтитипи рес это неплохо, просто нужно правильно с ним работать и предусматривать хороший устойчивый ипиай и все.
318: Кейсы, то есть нужно правильно проектировать до того, как его реализовывать. Во вторых, асинхронная коммуникация небезопасная, как её пытаются представить в современном обществе, во всяких ютубах ли.
319: И не только рассказывать, что асинхронная коммуникация решает все. Нет, друзья, она не решает все, она тоже имеет свои проблемы, которые необходимо, разумеется, предусматривать и правильно решать. С другой стороны, мы с вами поговорили о таких вещах, как гарантия.
320: Доставки в нашем случае это at least once, то есть как минимум 1 раз сообщение будет отправлено не доставлено, а как минимум 1 раз отправлено это важно потому что at least once это гарантия доставки, то есть вы в буквальном смысле говорите о том, что клиент может отправить сообщение.
321: Или или продюсер может запули овать сообщение несколько раз. Это нормально, и вы, разумеется, должны обеспечивать нормальную гарантию доставки, которая учитывает этот фактор. Это наиболее распространённая гара.
322: Доставки, она имеет плюсы и минусы, но опять же, она наиболее распространённая. Есть также другие, но сегодня про них говорить не будем. Вот так вот, друзья, что ж, давайте я отвечу на ваши вопросы.
323: И, пожалуй, мы сможем сегодня уже закрыть нашу сессию и разойтись. Между тем, пока вы пишите свои вопросы, друзья, в этом ничего сложного нет. Как вы видите, есть проблема, есть решение. Всегда нужно
324: Подходить к этому грамотно, прагматично. Сегодня есть всякие ии Тулы типа chat gpt клоды, которые позволяют вам, по крайней мере, предложить решение, как это можно использовать. Поэтому совок
325: Используя знания, реальную практику, современные Тулы, каждый человек способен это сделать, если вы хотите научиться делать так же, как я ещё раз повторяюсь, врывайтесь в учебный центр. I. Проди, там есть 2 супер курса 1.
326: Микросервисом по шаблонам проектирования, a2 курс это командная разработка, где вы научитесь не только разрабатывать, но проектировать микросервисную архитектуру и её потом деплоить в кубернейс. Так давайте пройдёмся.
327: Быстренько по вопросам закидывайте в чатик, друзья, на все постараюсь ответить. Так, по поводу проекта мы уже говорили, что я его опубликую в гитхабе. Наверное, самый простой вариант. Просто подпишитесь на меня в гитхаб в гитхабе и все.
328: То есть мой аккаунт, он публичный, я по любому это буду публиковать, просто приведу в порядок. Так, про айдишку мы поговорили, как гарантируется уникальность импотентных ключей про уникальность. Мы уже затрагивали тему, что
329: Уникальность гарантируется тем, что такие Тулы, вернее, такой стандарт, как y y y айди он довольно-таки имеет хорошую, ну, вернее, он имеет стабильную уникальность это не Гаран.
330: Уникальность, но в целом на него можно положиться. С другой стороны, если вы проектируете системы, то, безусловно, вы должны учитывать, что может при масштабировании или при супер больших нагрузках
331: Произойти так, что 2 разных экземпляра, даже не связанных между собой, могут сгенерировать 1 и ту же адику в таких случаях кстати, у меня есть забавно вот как раз есть книги по системному дизайну и вот в этот volume 1 scene.
332: Цвета, который отображается, это реклама, но не суть в этой книге есть классная. 1 из 1 вопрос по системному дизайну связан с проектированием генератора уникальных айдишек. Собственно, в таком случае вам нужно буде
333: Создать сервис по генерации уникальных айдишек, который позволит вам обеспечить максимальную стабильность и уникальность даже при распределённых системах. Но это отдельная тема, поэтому вариант 1 номер 1 положиться на
334: Uuid и молиться, что при большой нагрузке не будет 1 и того g1 и той же айдишки 2 момент открыть книгу по системному дизайну систем дизайн интервью алекс ксю вольюм номер 1 синего цвета.
335: И разобрать тему, которая называется генератор уникальных чисел, дистрибутивных систем. 3 вариант. Можете открыть мой гитхаб. Эта штука у меня реализована. На самом деле можете спокойно открывать.
336: На гитхаб публичный, я имею ввиду, и у меня вот этот генератор айдишек там есть там это довольно-таки простая система. Можете там смотреть, но там про код, а не про дизайн, но тем не менее вы поймёте, как генерировать уникальные айдишки. Так едем.
337: Дальше едем дальше, друзья. Так, так, так, гарантируется, гарантируется распределение вероятности по всему диапазону. Ю айди очень надёжный. Да, это правда, это то, что я говорю, он очень надёжный, действительно в него
338: Положено очень. Ну, короче, энтропия, как я уже говорил, там довольно-таки на высоком уровне, но может произойти ситуация всякая, что не будет он уникальным, потому что ui ю айди не учитывает масштаб.
339: Имя экземпляров, которые создаются, он не учитывает. Лобили зон в клаудах, он не учитывает регионы. И представьте себе, что у вас 20 экземпляров 1 и того же сервиса под сумасшедшей нагрузкой, которые расположены
340: В разных зонах. Поэтому шанс есть, понятно, энтропия высокая, но шанс все равно есть. Точнее, глубокая, не высокая, глубокая, как аналитику делать на простых ивентах. Ну как это вопрос отдельный, я б сказал бы
341: Как правило, для аналитики выделяются отдельные базы данных, зачастую но sql почему? Потому что sql плохо для этого подходит, аналитика имеет нестандартизированные структуру, очень часто данные присутствуют.
342: Отсутствует. Поэтому проще обратиться к структурам, которые не привязаны, вернее, к базам, которые хранилища, которые не привязаны к конкретной устойчивой структуре. Затем, как правило, туда сохраняются данные в той форме или в том объёме, в котором нужно, в котором
343: Нужны и уже, разумеется, другие сервисы. На основании этих аналитических данных проводят свои операции. Вернее, на основании этих данных делают аналитику. Есть ещё вопрос того, а как обновлять данные, которые
344: Связаны с аналитикой. Если они ещё в рантайме меняются, для этого нужно организовывать что-то вроде secure паттерна. Это очень как бы не супер, это очень популярно на собеседованиях. Очень много слышу об этом на ютубах, но пока что я нигде не видел, чтобы кто-то это реализовывал. Ну, должна быт.
345: Это должен быть очень серьёзный юскейс. Для этого, если кратко, то так, разумеется, аналитическую систему всегда необходимо рассматривать в контексте того, какая ставится задача, каких показателей метрик мы хотим достигнуть. То есть
346: И потом уже под это все проектировать, иначе это как пальцем в небо, если интересно, могу посоветовать книгу называется в народе кабанчик красного цвета с кабаном дейта интенсив аппликейшн клеппмана, если не ошибаюс.
347: Там как раз описывается о том как ну не то что проектировать, а что учитывать при проектировании систем связанных с аналитикой так так так так even driven на рм кью реальность или?
348: Вымысел, почему, как по мне, любая Тула, которая позволяет асинхронно делать обмен сообщениями.
349: Собственно, она связ вернее, она имеет место быть задача лишь в том, что именно реализует эта Тула, допустим, rabbitmq kafka, amazon, sq, c. Amazon.
350: Ms amazon кинезис кафка стримы и многое другое google папап, допустим, можно прочитать ну, можно продолжать бесконечно у каждой этой Тулы есть свои плюсы и.
351: Достатки. Это связано с тем, что они все реализованы по разному. Это не делает их плохими и хорошими. Просто каждый ставит другую определённую задачу, которую он собирается решать. Асинхронность это не задача. Асинхронность это
352: Способ обмена сообщениями это не задача, это, по сути, коммуникационный шлюз. Вот и все. И стратегия того, как обменивается клиент, и сервер, или подписчик и продюсер.
353: Между собой сообщениями, то есть, иначе говоря, ждёте вы ответ или не ждёте вы ответ. Вот и все. Я имею ввиду на свой же запрос, пока вы его не получите, это и есть синхронность и синхронность. Другое дело, что разнообразные Тулы, допустим,
354: Кафка и они реализованы по разному. Допустим, кафка, она в основе держит топики, которые позволяют потом делать отличные ретраи. Я имею ввиду, заново обойти топик. У неё балансируются эти топики, пардонте, не топики.
355: Я это хотел сказать, что на основе партишенов оно основано ребить, оно основано на очередях и на роутинге, что у вас есть разные очереди и есть, я бы сказал бы, очень гранулярный способ, как организовать
356: Роутинг сообщений по очередям в разных форматах фан аут, пир ту пир и так далее эскью эс или amazon на amazon sq эс иначе расшифровывается симпл хью сервис.
357: Это, по сути, очень упрощённый ребит инкью под капотом очередь, мы не будем говорить. Честная нечестная фифа Лифа это не суть. Важно, что под капотом очередь и там вы используете подход пир ту, пир, то есть вы не можете
358: Там делать никакие фанаты, его можно, конечно, там костылями сделать при помощи других плов, но цель другая, как видите. То есть, условно говоря, у вас есть очередь, вы туда помещаете сообщения и потом на обратной стороне в порядке очереди.
359: Той или иной клиенты или слушатели выбирают сообщения и их обрабатывают. Таких клиентов может быть много. В результате масштабирования они вообще могут быть разными сервисами. Ну конечно же, это неправильно. Странно, что в 1 оче
360: Очередь. Складываются сообщения 1 типа, а затем, разумеется, эти сообщения прослушиваются разными сервисами, абсолютно разными, потому что это просто работать так не будет. Цель другая. Поэтому возвращая
361: И отвечая на вопрос первичный имеет ли event driven на mq реализовывать, конечно же, имеет, но вопрос в том, какая задача ставится, что вы хотите реализовать, какие?
362: Какие слов, какие функциональные требования, исходя из этого, вы сможете выбрать соответствующий тул. Здесь могу сделать хинт, если вы думаете в контексте того, вернее, как вы можете себя отли.
363: Получить от senior инженера и сопоставить состав инженером с принципалом или с архитектором, если вы все ещё думаете, что нужно выбирать rabbitmq или кафку, при этом ваша система не спроектирована и не предусмотрела.
364: Гарантии доставки изначально идемпотентные ключи, тбокс, паттерны, дейта флоу. Как они будут перетекать от сервиса к сервису, но вы уже думаете о кафке, то поверьте мне, моему опыту.
365: Вы ещё senior почему? Потому что stuff он думает уже шире, принципал, ещё шире архитектор, ещё шире кафка, rabbitmq, другие Тулы это только Тулы, это уже детали реализации системы.
366: Даже если вы не пишите код для кафки, это детали реализации системы. Сначала вы её проектируете, потом вы все предусматриваете, и в зависимости от этого вы выбираете именно ту Тулу, которая вас устроит, исходя из вашей
367: Системы, а не сначала делайте Тулу, а потом все остальное. Иначе говоря, могу привести пример. Самолёт. Иногда самолёт строится вокруг двигателя. То есть сначала строят двигатель, а потом строят самолёт.
368: И из за этого очень часто получаются страшные самолёты, большие, неуклюжие, с дефектами тоже самое с оружием для Самолётов, иногда строится самолёт вокруг оружия, орудий, ракет и так далее. Неважно. С другой стороны, другой
369: Подход, когда самолёт строится под конкретную задачу и под эту конкретную задачу, разумеется, разрабатывается соответствующий двигатель, который интегрируется в этот самолёт, который отвечает требованиям, которым его, собственно, хотят видеть вот так вот, друзья. Поэтому да,
370: Это можно, можно использовать mq, в этом проблем никаких нету. Но вопрос в том, что мы реализуем вот так вот. Хорошо, друзья, вижу, вопросы закончились. Если будут пишите во мне ко мне.
371: В личку, не стесняйтесь, я в активном, публичном, так сказать, доступе. Если у вас будут вопросы, нужна будет какая-то краткая консультация, вы захотите что-то спросить, спокойно пишите, я с радостью отвечу. Если не отвечу быстро не переживайте, я никого не игнорирую лучше
372: Все просто написать. Макс, привет. Я был у тебя на вебинаре. Для меня это будет хорошим триггером, что окей, это не какой-то, так сказать, шарлатан бандит. И это, безусловно, смотивирует меня ответить быстрее. Во всем остальном, друзья, большое вам спасибо за уделённое.
373: Вами время. Мне очень было приятно вам рассказать о том, чем занимается современная разработка. Ввести вас в курс на реальных примерах, какие микросервисы используются, каким целям они служат, и объяснить, что
374: Не супер, то и сложно их реализовывать. Просто нужно чётко понимать, что у вас есть требования. Эти требования влияют на проектирование системы. И дальше, разумеется, вы можете спроектировать систему, а затем её правильно реализовать. А на сегодня, друзья, все хорошего вам.
375: Вечера, завершение недели. Пока, пока увидимся на других вебинарах.