Пікірлер

• 
  @XdXD-ff2vcКүн бұрын

  Автор красава, ахуенный материал

• 
  @do_bro4 күн бұрын

  Спасибо. За полчаса всё по полочкам разложил

• 
  @romantitov62075 күн бұрын

  Спасибо за видео. Очень интересное но как по мне уж слишком поверхностное. Автор подчеркивает важность демонстрации практического опыта на собеседовании но именно этого самого практического опыта использования этих паттернов автором в этом видео и не хватает. Надеюсь в будующих видео будет что-то основанное на реальных проектах. Хотя возможно для начинающих видео будет полезно чтобы не искать по гуглам все эти паттерны.

• 
  @user-bs8bz5lk1b7 күн бұрын

  Всё доходчиво) Возник вопрос по поводу JWT. Допустим есть API Gateway сервис и Security сервис, который после первоначальной проверки имя:пароль генерирует JWT, используя RSA шифрование и отдает его клиенту. Каким образом лучше всего осуществить проверку этого токена, не отправляя каждый запрос от клиента в Security, у которого (только!) есть доступ к RSA ключам? Сейчас на Gateway применяется фильтр, который отправляет запросы к другим микросервисам сначала в Security на верификацию JWT. Как-то криво по-моему(

• 
  @digital_train6 күн бұрын

  Есть несколько подходов, если я правильно понял ваш случай - это случай когда для каждого микросервиса мы осуществляет запрос и проверку токена, такой подход отлично работает с точки зрения безопасности, но у него есть минусы и один из основных это проблема масштабирования (при большом количестве микросервисов и запросов рост нагрузки будет экспоненциальным). В таком случае чаще всего переходят на аутентификацию на edge (по перимитру), что сильно упрощает масштабирование, но снижает "строгость" проверок для каждого вызова внутри безопасной зоны Подробно данных подход хорошо изложен в блоге Netflix (они как раз столкнулись с проблемой управления и масштабирования) - netflixtechblog.com/edge-authentication-and-token-agnostic-identity-propagation-514e47e0b602

• 
  @AllMovieAndGameTrailers7 күн бұрын

  ммм алгоритм бинарного поиска на несколько минут дольше писал и хоткеи не использует. боже дай сил окружающим интервьюера)))

• 
  @alexandr60559 күн бұрын

  контент супер! Спасибо вам

• 
  @egor.cleric10 күн бұрын

  Мне кажется автор натягивает сову на глобус говоря, что RabbitMQ это про Push. Сам брокер не знает адреса потребителей, они к нему подключаются и запрашивают новые сообщения. Это только запутывает

• 
  @digital_train9 күн бұрын

  Действительно это может немного смущать что rabbitmq ориентирован на push based. В нем есть два типа API push & pull но в большинстве случаев используется push подход (www.rabbitmq.com/docs/consumers#subscribing )

• 
  @MrCipec10 күн бұрын

  Пили про аутентификацию, всегда актуально)

• 
  @sergeystarostin17912 күн бұрын

  Спасибо. Еще бы добавить nats/nats streaming.

• 
  @ivanstrelka344813 күн бұрын

  Оч круто! Если можно покажите тесты на gRPC пожалуйста

• 
  @tihon497913 күн бұрын

  Доступно. Понятно. Без воды. Лайк. Подписка.

• 
  @user-zs3tk1gn2x14 күн бұрын

  спасибо!!!

• 
  @ivanstrelka344814 күн бұрын

  Топ контент! Спасибо

• 
  @paemox15 күн бұрын

  Очереди сообщений не нужны практически никогда! Для этого есть обратный прокси и балансировщик nginx/Apache.

• 
  @digital_train14 күн бұрын

  Действительно в самых простых случая очередь можно заменить на реверс + LB Но это только часть функциональности, очереди так же: - Автоматически масштабируются при добавлении и удалении нод из кластера - Могут гарантировать транзакционность и использовать различные стратегии доставки - Часть из очередей могут использоваться в виде хранилища events в event-driven архитектуре - Так же поверх них удобно строить real-time стримы данных и событий и не переживать за то что какой-то из consumer упадет Важно посмотреть на кейс и уже после решать нужна ли очередь или нет

• 
  @paemox14 күн бұрын

  @@digital_train - Балансировщик тоже может добавлять и удалять ноды - Если пользователь не получает ответ в течении 30 секунд, то в большинстве случаев он перестает его ждать и уходит. Поэтому нет смысла накапливать сообщения в надежде когда-то там обработать все. - Событийная архитектура усложняет разработку, если система не помещается на сервер, то лучше использовать шардирование, а не разбиение на подсистемы, что связаны событиями. - После падения консюмеров забивается и падает очередь, что делает ее бессмысленной для спасения. Проще разруливать падение на клиенте путем повторных запросов.

• 
  @jewgenijmoldawski330612 күн бұрын

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

• 
  @unicoxr5tj41716 күн бұрын

  поддержка видосиков комменто-лайком

• 
  @ivanstrelka344819 күн бұрын

  Оч круто!! Спасибо

• 
  @alexandr605521 күн бұрын

  У меня вопрос по event sourcing. Вот Вы сказали, что мы каждый шаг пользователя фиксируем. Имеется ввиду прям i/o фиксация в бд. Или у нас просто собираются данные в некую коллекцию, а затем по завершении действий пользователем делаем запись в бд? При втором варианте конечно есть риск потери данных при сбое, но первый вариант кажется суперзатратным, все таки идёт постоянная запись в бд. Если юзер просто играется и добавляет товар через плюсик по одному до 20шт, затем удаляет, для меня это 20 транзакций?😢

• 
  @digital_train19 күн бұрын

  Отличный вопрос, спасибо что задали его! Действительно если рассмотреть реальную систему то такой подход будет слишком трудозатратен с тз "бека". Поэтому в примере с обычным e-commerce это будет слишком накладно + потеря корзины пользователя который ушел на несколько часов не так критична С другой стороны если мы продаем что-то на что есть жесткий лимит и пользователь будет сильно разочарован в случае отказа - например билет на самолет ил театр, то стоит фиксировать не саму корзину а событие старта процесса покупки тем самым мы снизим нагрузку на "бек", а с другой стороны сможем обеспечить гарантию только одной продажи для пользователя

• 
  @alexandr605519 күн бұрын

  @@digital_train спасибо, теперь понял.

• 
  @novmicha21 күн бұрын

  Про multi stage pipeline очень вскользь сказано, хотелось бы на конкретном примере. Например как организовать транзакцию когда идет целый ряд событий как результат одного. К примеру типовая ситуация: заказ от пользователя (оплата-пересчет остатков-информирование).

• 
  @digital_train19 күн бұрын

  Отличный вопрос, как раз разбирали его на теме про паттерны микросервисной архитектуры. Если коротко - транзакционность между микросервисами это дорого и сложно, но есть подходы к организации Тут пример kzread.info/dash/bejne/iJ13ppZ-gs2bZ5s.htmlsi=M7WRUakxvd6PIYtH 1. Event sourcing 2. Saga pattern

• 
  @outsourcingonline23 күн бұрын

  Невеликого уровня дигиталер. Владеет только птичьим разговорным...

• 
  @serb114624 күн бұрын

  Спасибо.

• 
  @vladimir_v_it24 күн бұрын

  Классное видео! Спасибо!

• 
  @immortal-spirit-1324 күн бұрын

  Спасибо )🙂довольно таки хорошая теория 👍

• 
  @unicoxr5tj41726 күн бұрын

  какнал об автотестах микросервисов на Джава?

• 
  @digital_train26 күн бұрын

  Канал о помощи начинающим ИТ инженерам, тестировщикам и аналитикам Вот тут для примера мы рассматриваем архитектуру и паттерны микросервисов, что полезно для инженеров kzread.info/dash/bejne/iJ13ppZ-gs2bZ5s.html

• 
  @unicoxr5tj41726 күн бұрын

  @@digital_train буду смотреть, спасибо. Пысы пре-миддл инженер-тестировщик с упором на Джава, что его три раза

• 
  @jonkarmok184027 күн бұрын

  Я правильно понимаю что у Rabbit должны быть ниже задержки, чем у Kafka?

• 
  @digital_train26 күн бұрын

  Если мы говорим на задержку на чтение и обработку сообщения то за счет структуры Kafka сообщение будет проходить быстрее, т.к. там по сути отсутствует умный роутинг и т.д. Но если наша задача выглядит как в зависимости от сложной логики раскидать сообщение по группам, с какими-нибудь полиси. То тут RabbitMQ будет быстрее так как в Kafka нет внутренних механизмов и все прийдется делать во внешнем сервисе, следовательно только передача сообщения между очередью и сервисом съест львиную долю времени Если суммировать, смотрите на ваш кейс_

• 
  @prostoprosa27 күн бұрын

  Большое спасибо за видео. Понятно и доступно)

• 
  @nikolaykozlov4888Ай бұрын

  Отличное представление информации. Просто огонь! Спасибо

• 
  @ilmusshaАй бұрын

  Спасибо за видео, вы лучший на мире

• 
  @user-zw8mz5jy8fАй бұрын

  Благодарю за видео, вкатывающимся будет очень полезно. Хотелось бы услышать каким образом работать с информацией, чтобы это все перерастало в навык, ибо информации на любые темы более чем достаточно, а вот как работать с ней - это большой вопрос)

• 
  @digital_trainАй бұрын

  Отличный вопрос! Постараюсь подготовить короткое видео на тему как лучшего всего подходить к поиску, фильтрации и работе с информацией и знанием

• 
  @digital_trainАй бұрын

  Больше полезных материалов и видео на моем канале, telegram: t.me/digital_train

• 
  @KartoplyanaHataАй бұрын

  Болел за экзаменуемого, как за любимую спортивную команду)

• 
  @digital_trainАй бұрын

  Показал хороший уровень 👍🏼

• 
  @ARaskolnikoffАй бұрын

  Думаю вы единственный человек, который смог передать многолетний опыт за час встречи настолько доступно и понятно 👍 Все строго по сути и делу - за час вы смогли сделать из полной каши в моей голове полное понимание «что, зачем и почему», которое возможно так бы и не сформировалось в дальнейшем за несколько лет работы автотестировщиком без вашей лекции, круто 🔥 Этот канал и весь ваш совокупный опыт в этой сфере очень ценны, продолжайте, супер полезно 🙂👍

• 
  @digital_trainАй бұрын

  Скоро выйдет продолжение про то как в ручную и автоматически тестировать контракты и сервисы если они соединены с Kafka / RabbitMq

• 
  @user-qu9tg8fd3yАй бұрын

  Очень хорошее видео, видно, что от души делаете! Подрекламировать контент стоит, а то просмотров немного,знаю про ютифай, сразу дела быстрее пойдут.

• 
  @digital_trainАй бұрын

  Больше полезных материалов и видео на моем канале, telegram: t.me/digital_train

• 
  @digital_trainАй бұрын

  Больше полезных материалов и видео на моем канале, telegram: t.me/digital_train

• 
  @digital_trainАй бұрын

  Больше полезных материалов и видео на моем канале, telegram: t.me/digital_train

• 
  @digital_trainАй бұрын

  Больше полезных материалов и видео на моем канале, telegram: t.me/digital_train

• 
  @user-vx4fl1is2wАй бұрын

  вот бы меня бинарный поиск спросили на собесе

• 
  @digital_trainАй бұрын

  Бинарный поиск скорее как задача разогрев

• 
  @digital_trainАй бұрын

  Больше полезных материалов и видео на моем канале, telegram: t.me/digital_train

• 
  @digital_trainАй бұрын

  Подписывайтесь на канал 🚀 Еще больше полезных виде и информации для инженеров, тестировщиков и аналитиков! t.me/digital_train

• 
  @digital_trainАй бұрын

  Больше полезных материалов и видео на моем канале Telegram: t.me/digital_train

• 
  @digital_trainАй бұрын

  Больше полезных материалов и видео на моем канале, telegram: t.me/digital_train

• 
  @-maxxxeffectАй бұрын

  спасибо! очень хорошая подача материала