Для таких донесений надо выделять час - такая информация на вес золота ) А то там на главный трэках какую-то херь разжовывают 60 минут которая нахрен никому не нужна
Последняя глава про Тыкву сама по себе требует 30мин времени. Мне кажется надо было дать этому человеку час эфира. Либо выкинуть очевидные вещи из презы типа Deadlines
По рейт лимиту не согласен. Как только мы начнем "давать в долг", то есть гибко подходить к лимитированию, сразу упадет надежность, и в части случаев сервис таки будет падать.
@@himmih просто у akka своих проблем выше крыши: как минимум отсутствие типизации у акторов. Не зря в Scala мире от нее почти все отказались в пользу эффектов. Тем более, что akka сменила лицензию и де-факто теперь мы говорим о pekko
@@ChannelCheesecake 2.6 akka отличный и стабильный продукт с хорошей лицензий. Типизация есть. Используют куча крупных продуктов начиная играми с миллионами пользователей онлайн, заканчивая крупными платежными системами с огромным количеством транзакции. Не обязательно использовать Scala, очень хорошо работает и с java. Тут важнее именно архитектурные решения, которые в других подходах решаются сложнее.
Скелетон страницы видит, не даром же их придумали внедрять в приложения))) Но в задаче про рейтинги их можно было бы и кешировать, мне кажется, и показывать, пусть старый, но како-то рейтинг
Не очень понял профит от паттерна deadline. В чем принципиальная разница с обычными таймаутами. Если пользователь тупо закрыл свой клиент, нам никакая временная метка в хедере не поможет. Такое ощущение, что это альтернатива таймаутам на соединения. Чтобы не рассчитывать таймауты и количество ретраев для каждого микросервиса в сложной интеграции. Типа ретраимся до победного и надеемся, что сеть не с первой так со второй попытки нас пустит куда надо. Но если время до дедлайна вышло, то успокаиваемся и ничего не делаем дальше по флоу. Тогда получится более простая конфигурация кучи сервисов и при этом сэкономим, снизив паразитную нагрузку
их бы куда-то в базу логов класть, общую на все сервисы, типа elasticsearch, чтобы можно было трейсить запрос сквозь всю цепочку приложений, ну и соответственно у каждого приложения могут быть свои retry и circuit breaker
Стандартная лексика в среде разработчиков. Много информации на английском языке и переводы слов часто разные, а многие и не переводят просто, и чтобы понимать о чем речь, часто используются англицизмы, уж так сложилось.
Респект докладчику, хороший материал доклада и отличня подача !
Лучший доклад по патернам который слышал до сих пор
Retry 3:48
Deadlines и Deadline Propagation 17:22
Rate limiting (Burst limiting) 25:24
Circuit breaker 36:06
Rich client 36:34
Dummy (aka Pumpkin) 37:10
потрясающий доклад и докладчик. спасибо большое, прослушала с большим интересом! и действительно ужасно хотелось бы увидеть его в неурезанном виде(
Вот этот доклад я бы полностью хотел услышать. А ещё и паттерны из конца доклада я бы разобрал.
Для таких донесений надо выделять час - такая информация на вес золота ) А то там на главный трэках какую-то херь разжовывают 60 минут которая нахрен никому не нужна
Отличный доклад, без воды.
Про Яндекс.Воду без воды))
Много интересных паттернов. Побольше таких бы докладов
Жалко, что времени не хватило, но спасибо, очень интересно
отличный доклад, приятно слушать когда человек понимает про что рассказывает 👍
Спасибо! Отличный доклад! На одном дыхании смотрится.
Прямо очень хорошая памятка. Спасибо 👍
Отличный доклад, спасибо !
Круто 👍
Последняя глава про Тыкву сама по себе требует 30мин времени.
Мне кажется надо было дать этому человеку час эфира. Либо выкинуть очевидные вещи из презы типа Deadlines
Очень полезный и интересный доклад, жаль спикеру пришлось его сократить :(
Спасибо большое! Отличная лекция)
Отличная лекция.
ого, писал я немного в тот самый каталог) адовый сервис)) Александр супер крутой спец!
Бомбезно!
Отличный доклад. Благодарю. Особо за ссылки. Мне тоже показалось, что можно было бы и без кода. Так всё наглядно
Огонь
Ключ идемпотентности или trace_id запроса?) По сути это одно и то же) И в логах будет порядок
Делать микросервисы ради микросервисов сомнительная идея, но сам доклад хороший. Презентация прям наглядная.
микросервисы ради горизонтального масштабирования. в остальном, конечно, это боль, но деваться некуда)
13:30 ключи идемпотентности
Спасибо Матгередон
По рейт лимиту не согласен. Как только мы начнем "давать в долг", то есть гибко подходить к лимитированию, сразу упадет надежность, и в части случаев сервис таки будет падать.
Все эти задачи очень круто решаются в Akka из коробки!
А можно подробнее, как akka помогает
@@ChannelCheesecake подробнее не получается в комментарии, смотрите документацию, но akka по сути и создавалась, чтобы решать проблемы озвученные тут.
@@himmih просто у akka своих проблем выше крыши: как минимум отсутствие типизации у акторов. Не зря в Scala мире от нее почти все отказались в пользу эффектов. Тем более, что akka сменила лицензию и де-факто теперь мы говорим о pekko
@@ChannelCheesecake 2.6 akka отличный и стабильный продукт с хорошей лицензий. Типизация есть. Используют куча крупных продуктов начиная играми с миллионами пользователей онлайн, заканчивая крупными платежными системами с огромным количеством транзакции. Не обязательно использовать Scala, очень хорошо работает и с java. Тут важнее именно архитектурные решения, которые в других подходах решаются сложнее.
Подскажите. А что видит пользователь пока сервис ждет ответа от Retry?
ну обычно какой-то прелоадер в конкретном блоке страницы, например подгружаем отзывы, и только там как-то обыгрывается индикатор загрузки
Скелетон страницы видит, не даром же их придумали внедрять в приложения))) Но в задаче про рейтинги их можно было бы и кешировать, мне кажется, и показывать, пусть старый, но како-то рейтинг
код был не нужен, без него можно было уложиться. жаль, хороший получился бы гайд
Очень поучительная история. Только шрифты для людей тоже желательно было сделать.
Не очень понял профит от паттерна deadline. В чем принципиальная разница с обычными таймаутами.
Если пользователь тупо закрыл свой клиент, нам никакая временная метка в хедере не поможет.
Такое ощущение, что это альтернатива таймаутам на соединения. Чтобы не рассчитывать таймауты и количество ретраев для каждого микросервиса в сложной интеграции. Типа ретраимся до победного и надеемся, что сеть не с первой так со второй попытки нас пустит куда надо. Но если время до дедлайна вышло, то успокаиваемся и ничего не делаем дальше по флоу.
Тогда получится более простая конфигурация кучи сервисов и при этом сэкономим, снизив паразитную нагрузку
КАЙФ!
Что значит Monolith?
Я что-то не могу найти :
05 Rich client
06 Dummy
а что на счет ключей идемпотпнтности. их индексируете в бд? А если ключ не корректный будет, просто отклоняем?
их бы куда-то в базу логов класть, общую на все сервисы, типа elasticsearch, чтобы можно было трейсить запрос сквозь всю цепочку приложений, ну и соответственно у каждого приложения могут быть свои retry и circuit breaker
"5 минут?? "- очень жаль стало, что спикер не успеет все как планировал рассказать
Вроде бы последний рубеж- это не тыква,а реплика виртуальных машин нет?)
Спикер крутой
Видно что ты разработчик по Яндекс Еде ))))
Отличный доклад. Можно было бы без кода обойтись, тогда больше времени было)
Хуєта для джунів
что тут забыл синьор
"Ретраить", " рефрешить", с русским языком проблемы? 😄
Стандартная лексика в среде разработчиков. Много информации на английском языке и переводы слов часто разные, а многие и не переводят просто, и чтобы понимать о чем речь, часто используются англицизмы, уж так сложилось.
подсказал бы лексику, если настолько знаток.