Для таких донесений надо выделять час - такая информация на вес золота ) А то там на главный трэках какую-то херь разжовывают 60 минут которая нахрен никому не нужна
Последняя глава про Тыкву сама по себе требует 30мин времени. Мне кажется надо было дать этому человеку час эфира. Либо выкинуть очевидные вещи из презы типа Deadlines
Скелетон страницы видит, не даром же их придумали внедрять в приложения))) Но в задаче про рейтинги их можно было бы и кешировать, мне кажется, и показывать, пусть старый, но како-то рейтинг
@@himmih просто у akka своих проблем выше крыши: как минимум отсутствие типизации у акторов. Не зря в Scala мире от нее почти все отказались в пользу эффектов. Тем более, что akka сменила лицензию и де-факто теперь мы говорим о pekko
@@ChannelCheesecake 2.6 akka отличный и стабильный продукт с хорошей лицензий. Типизация есть. Используют куча крупных продуктов начиная играми с миллионами пользователей онлайн, заканчивая крупными платежными системами с огромным количеством транзакции. Не обязательно использовать Scala, очень хорошо работает и с java. Тут важнее именно архитектурные решения, которые в других подходах решаются сложнее.
По рейт лимиту не согласен. Как только мы начнем "давать в долг", то есть гибко подходить к лимитированию, сразу упадет надежность, и в части случаев сервис таки будет падать.
их бы куда-то в базу логов класть, общую на все сервисы, типа elasticsearch, чтобы можно было трейсить запрос сквозь всю цепочку приложений, ну и соответственно у каждого приложения могут быть свои retry и circuit breaker
Не очень понял профит от паттерна deadline. В чем принципиальная разница с обычными таймаутами. Если пользователь тупо закрыл свой клиент, нам никакая временная метка в хедере не поможет. Такое ощущение, что это альтернатива таймаутам на соединения. Чтобы не рассчитывать таймауты и количество ретраев для каждого микросервиса в сложной интеграции. Типа ретраимся до победного и надеемся, что сеть не с первой так со второй попытки нас пустит куда надо. Но если время до дедлайна вышло, то успокаиваемся и ничего не делаем дальше по флоу. Тогда получится более простая конфигурация кучи сервисов и при этом сэкономим, снизив паразитную нагрузку
Стандартная лексика в среде разработчиков. Много информации на английском языке и переводы слов часто разные, а многие и не переводят просто, и чтобы понимать о чем речь, часто используются англицизмы, уж так сложилось.
потрясающий доклад и докладчик. спасибо большое, прослушала с большим интересом! и действительно ужасно хотелось бы увидеть его в неурезанном виде(
Респект докладчику, хороший материал доклада и отличня подача !
Лучший доклад по патернам который слышал до сих пор
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
Отличный доклад, спасибо !
Круто 👍
ого, писал я немного в тот самый каталог) адовый сервис)) Александр супер крутой спец!
Спасибо большое! Отличная лекция)
Отличная лекция.
Отличный доклад. Благодарю. Особо за ссылки. Мне тоже показалось, что можно было бы и без кода. Так всё наглядно
Делать микросервисы ради микросервисов сомнительная идея, но сам доклад хороший. Презентация прям наглядная.
микросервисы ради горизонтального масштабирования. в остальном, конечно, это боль, но деваться некуда)
Подскажите. А что видит пользователь пока сервис ждет ответа от Retry?
ну обычно какой-то прелоадер в конкретном блоке страницы, например подгружаем отзывы, и только там как-то обыгрывается индикатор загрузки
Скелетон страницы видит, не даром же их придумали внедрять в приложения))) Но в задаче про рейтинги их можно было бы и кешировать, мне кажется, и показывать, пусть старый, но како-то рейтинг
Бомбезно!
Ключ идемпотентности или trace_id запроса?) По сути это одно и то же) И в логах будет порядок
Огонь
код был не нужен, без него можно было уложиться. жаль, хороший получился бы гайд
"5 минут?? "- очень жаль стало, что спикер не успеет все как планировал рассказать
Очень поучительная история. Только шрифты для людей тоже желательно было сделать.
Все эти задачи очень круто решаются в Akka из коробки!
А можно подробнее, как akka помогает
@@ChannelCheesecake подробнее не получается в комментарии, смотрите документацию, но akka по сути и создавалась, чтобы решать проблемы озвученные тут.
@@himmih просто у akka своих проблем выше крыши: как минимум отсутствие типизации у акторов. Не зря в Scala мире от нее почти все отказались в пользу эффектов. Тем более, что akka сменила лицензию и де-факто теперь мы говорим о pekko
@@ChannelCheesecake 2.6 akka отличный и стабильный продукт с хорошей лицензий. Типизация есть. Используют куча крупных продуктов начиная играми с миллионами пользователей онлайн, заканчивая крупными платежными системами с огромным количеством транзакции. Не обязательно использовать Scala, очень хорошо работает и с java. Тут важнее именно архитектурные решения, которые в других подходах решаются сложнее.
ну если не лучшее что слышал на докладах, то одно из.
про dummy штуку - как то никогда и не приходила в голову такая идея
13:30 ключи идемпотентности
Спасибо Матгередон
По рейт лимиту не согласен. Как только мы начнем "давать в долг", то есть гибко подходить к лимитированию, сразу упадет надежность, и в части случаев сервис таки будет падать.
КАЙФ!
Что значит Monolith?
а что на счет ключей идемпотпнтности. их индексируете в бд? А если ключ не корректный будет, просто отклоняем?
их бы куда-то в базу логов класть, общую на все сервисы, типа elasticsearch, чтобы можно было трейсить запрос сквозь всю цепочку приложений, ну и соответственно у каждого приложения могут быть свои retry и circuit breaker
Не очень понял профит от паттерна deadline. В чем принципиальная разница с обычными таймаутами.
Если пользователь тупо закрыл свой клиент, нам никакая временная метка в хедере не поможет.
Такое ощущение, что это альтернатива таймаутам на соединения. Чтобы не рассчитывать таймауты и количество ретраев для каждого микросервиса в сложной интеграции. Типа ретраимся до победного и надеемся, что сеть не с первой так со второй попытки нас пустит куда надо. Но если время до дедлайна вышло, то успокаиваемся и ничего не делаем дальше по флоу.
Тогда получится более простая конфигурация кучи сервисов и при этом сэкономим, снизив паразитную нагрузку
Я что-то не могу найти :
05 Rich client
06 Dummy
Вроде бы последний рубеж- это не тыква,а реплика виртуальных машин нет?)
Спикер крутой
Видно что ты разработчик по Яндекс Еде ))))
Отличный доклад. Можно было бы без кода обойтись, тогда больше времени было)
Хуєта для джунів
что тут забыл синьор
"Ретраить", " рефрешить", с русским языком проблемы? 😄
Стандартная лексика в среде разработчиков. Много информации на английском языке и переводы слов часто разные, а многие и не переводят просто, и чтобы понимать о чем речь, часто используются англицизмы, уж так сложилось.
подсказал бы лексику, если настолько знаток.