Что спрашивают о микросервисах в крупных компаниях | Senior Developer | Jetbulb
2024 ж. 25 Мам.
35 749 Рет қаралды
Сегодня мы рассмотрим обзор реального технического собеседования на позицию Senior Developer в крупную страховую компанию, что предоставляет услуги по всему миру.
Поговорим о вопросах которые задавались на собеседовании и как на них можно ответить. Но важнее всего то, что данное собеседование покрывает чуть ли не самую популярную тему - "Микросервисная архитектура".
Погнали!
Программа
00:00 Введение
01:36 Кратко о компании и позиции
02:49 Архитектура и дизайн
17:51 Про High availability и Reliability
38:58 Выводы
Наш тренинг-центр:
iprody.com/
Запись на обучение и собеседование:
t.me/iPrody_Online
Мы в социальных сетях:
t.me/jetbulb
/ jetbulb
Невероятное количество полезной информации, благодарю!
Так легко и позитивно препадаешь информацию, что с легкостью можно включить утром и послушать пока умываешся. Спасибо друг!
Как всегда! Просто лучший формат видео!
вот это я понимаю контент, спасибо вам большое
отличная подача материала! Радуют примеры собеседований и вопросов для более продвинутого уровня. Было бы круто поработать вместе на реальных проектах :)
Спасибо Максим, как всегда очень круто! Когда я хотел попасть в престижную консалтинговую компанию меня минут 20 расспрашивали о microservices. Сначала в ролевой игре надо было убедить клиента использовать у себя microservices architecture. Он очень жёстко держался за свой монолит. :) А ещё спросили о microservices orchestration tools таких как Kafka или Zeeba
Спасибище!!! Сколько не учись - всю жизнь что-то новое узнаешь)) Крутой материал!
Очень полезно! Макс, спасибо👍👍👍
Подача огонь! Спасибо)
Очень полезно, спасибо!
Огромное спасибо автору за краткую систематизацию основных паттернов проектирования мисросервисов. Как раз реализовывали недавно timeout retry через webhook-и
Спасибо! Актуально и увлекательно❤
Спасибо автору за видео. Согласен с начальной заставкой. Ее поддержали бы также жители Белграда, Ливии, Ирака, городов Газы. Странно только при этом видеть картинку с солдатом известного военного блока на заднем фоне. Я немного застал советское время. О многом в истории просто не знал, многое трактовал субъективно. Чтобы не вестись на идеологическую пропаганду, важно пытаться сохранять критический взгляд и пользоваться разными источниками информации, а не только слушать то, что вещает рупор в стране твоего проживания. Иначе совершенно очевидные противоречия будут для тебя незаметны.
CQRS родился не совсем из EventSourcing-а, изначально был Command-query separation (CQS) который решает проблему сильной разницы в количестве запросов на чтение и запись. И в видео больше сказано именно про него, в то время как у CQRS имеет более строгие ограничения в реализации, главный из которых состоит в том что Comand никогда не возвращает данные, и работа идет в двумя разными бд который синхронизируются обычно через очередь. Этот подход крайне удобен для EventSourcing-а
Ну вопрос синхронизации это уже другой вопрос это могут быть просто master-slave реплики. Если это это база данных одного типа, какой то постгрес например. Если это sql+nosql то тогда нужно свой солюшин писать для синхронизации.
Классная подача) Интересно смотреть
Здорово, очень полезный материал. На сколько помню проводил опрос про реактивщину, если это было в твоём тг то очень сильно жду)
Да, в ТГ-канале уже было неоднократно про реактивы) И будет еще))) Спасибо за отзыв!
Полезно👍
Stability patterns очень хорошо упорядочены в подаче теперь понятно, по какой логике их применять, а то я в принципе знал как их подключить, но как они правильно должны подключаться не знал.
Огинище!!!! Сейчас готовлюсь к собесу в крупный банк на работу мечты!!))) И тут такой материал!!!)))) Благодарность огромная!!! Тысячу бы лайков поставил!!!) Но можно только один!)))
Один лайк уже как тысяча)) Респект!
С других аккаунтов ставь :)
Сбер на 250к?)
@@Dmitri915 450
Как работа?
И добавлю что в описании Circuit Breaker стоит описывать состояния не как открытый или закрытый а OPEN - разрыв цепи, CLOSED - соединение цепи, на русском как то это будет понятнее.
Очередной коммент для продвижения авансом. Спасибо)
спасибо за видео !!1!1
Макс, сколько новых слов 😅 Спасибо большое!
Короче, что я понял. Самое главное в микросервисах что? Не угадаете. Сторителлинг!
Благодарю!
Привет! Спасибо за видео) Было бы супер, если бы писал названи терминов, которые упоминаешь, чтобы лучше связывать через визуальное восприятие
Про CQRS ничего не понял из объяснения. Приемущества cqrs в том что для записи можно использовать один сторейдж например mysql а для чтения совсем другой, например dynamodb и апликухи, которые конектятся к этим сторейджам можно горизонтально скейлить независимо друг от друга. Например если запись в write model у тебя может быть 20 раз в день, а чтение с read model 20 млн в день. То возможно на чтение лучше поставить базу, которая работает быстрее на чтение и отдает например не нормализованные данные, сразу json as is.
Полезно, спасибо
При таком перекосе, думаю ее же можно использовать и для записи. Уж 20 раз в день она что-то записать, думаю, сможет. И на скорость чтения єто повлияет примерно никак.
@@yuriy.kostenko Так это образно. В реальных проектах совсем другие цифры.
Технологии интересные, но, редко встречаются на собесах. Event driving более менее часто только.
Наконец-то петличка, а не микрофон на все лицо в кадре)). Крутой материал!
Самое глубокое и информативное объяснение
Круто! спасибо!! Не совсем понял про снапшоты на 12:30
Большое спасибо за интересный ролик. В тему(или не очень) микросервисов, уважаемы Максим, хотелось бы узнать ваше мнение насчёт DDD. Недавно начал изучать тему, читаю книгу Вона Вернона, но пока все выглядит немного абстрактно и на уровне лозунгов. Возможно приходилось применять этот подход на практике?
Axon Framework вам в помощь
Совсем скоро будет новый выпуск. Он будет посвящен DDD. Там можно будет получить много ответов )) Если кратко, DDD это и есть форма абстракции при которой бизнес-потребности могут быть обрисованы на языке понятном для технических специалистов. Таком себе контракт между "технарем" и "нетехнарем".
Дисклеймер в начале в самое сердечко. ❤
Ну хоть сейчас до вас дошло, что мир это хорошо, а нападать на другие страны - это плохо. Столько лет вы ничего не замечали.
Когда читал книжку по паттернам тоже удивлялся, что оказывается абстрактный класс это тоже шаблон. Так и тут, оказывается ретрай - эт шаблон
Здравствуйте! А что посоветуете по микросервисам для джуна?)
Неплохой точкой вхождения может стать материал по ссылке ниже microservices.io/
Скажи, пожалуйста, с какой книги можно начать, чтобы войти в эту тему? С кабаном?
мне заходит microservices.io/ на этом сайте более чем подробно все расписано. как точка вхождения отлично помогает
Микросервисная архитектура - это стиль) Не шаблон. Специально смотрел этот момент и у Ричардсона и на других ресурсах типа azure arcitecture. Большое спасибо за материал, очень много нужного можно почерпнуть)
@Petr Dobrov Насмешил
Для справки Application architecture patterns Monolithic architecture - architect an application as a single deployable unit Microservice architecture - architect an application as a collection of loosely coupled, services
@@Jetbulb я написал ответ про путаницу у того же Ричардсона на всех его ресурсах. Кто то потер коммент)
Скоро этот академический пафос спадет. Я еще угораю с понятия CAP теорема. Так жеж умничают люди, при этом они даже теорему Пифагора не докажут.
@@oeaooя сам мягко говоря не поддерживаю собеседования в стиле телевикторины. Но раз уж так повелось в отрасли, то надо быть точным. Ну и насчёт теоремы cap я бы не был настолько категоричен.
Вопрос по поводу лайв кодинга на итервью. Почему дают кандидатам какие-то тупые ненужные задачи, когда можно, например, дать задачу написать простой микросервис с различными плюшками? Можно с Х2 базой данных, или пописать эксепшн хендлеры всякие. То, что в реальной жизни имеет смысл.
Отличный вопрос 👍 Но тут все просто. Времени столько нет чтобы сервисы организовывать, базы подключать. Если хочется проверить дизайнерские возможности кандидата, то как правило дают задачу на дом. Тогда человек в спокойной обстановке сможет все обдумать и собрать. За 1,5 часа познакомиться, вникнуть в задачу, прояснить детали и решить… просто нереально. Конечно же дают задачи. Но такие задачи отражают предметную область и не требуют сложных манипуляций. Как правило, это задачи на системный дизайн из предметной области бизнеса. Вот пример реальный: «Реализуйте метод для перевода средств с одного счета на другой». Разумеется там выдвигается куча требований: - многопоточка - отсутствие овердрафтов - проверки валидности данных - возможность работы в распределениях системах - и тд
@@Jetbulb На спрингбуте с гуглом любой достойный кандитат успеет что-нибудь да сделать. Я скорее про то, что частенько дают задачи, которые не имеют смысла в применении в реальной жизни. Я это по собственному опыту сужу, а также по Вашим видео.В целом, на интервью очень много теории, которая не дает гарантии хорошего кодинга, в чем я лично вижу разницу между джуном, мидом и синьором. Решить задачу может любой, а вот сделать ее хорошо - совсем другое дело. Я менторю людей по кодингу, и не понимаю, как некоторые из них прошли интервью на сеньор позиции. С большинством интервью явно что-то не так, но не могу сказать, как это сделать лучше )))).
Привіт Макс, чи можеш підказати, як дізнатися чи можна скейлити Спрінг Бут сервіс? Можливо знаєш якийсь ресурс де можна почитати. Буду дуже вдячний)
Привіт)) На мій погляд, за посиланням можливо знайти все що треба www.baeldung.com/spring-boot Також рекомендую офіційну документацію docs.spring.io/spring-boot/docs/current/reference/htmlsingle/
Отличное видео, затмевает только увы картинка про корабль и т. П.
Очень мало конечно информации но для джунов и тех кто хочет ими стать ,ултрополезная инфа ,что то услышать новое и инстагуглить ,спасибо огромное ,Макс ,очень полезно в этом деле все время узнавать то, что даже не слышал не разу)))))
Джунам ничего из этого ещё долго не пригодится, да и 100% на джуновском собесе таких вопросов не будет
@@Denis-sds сейчас вроде такая ситуация, что бы стать джуном нужно знать инфу на мидла
Неее. В дагонку полетит вопрос, если для нас так критична последовательность транзакций, то как быть если один сервис уже обработал т1, т2 и т3, а другой ещё не закончил обработку т1.
Изоляция?
Жаль, что нет тайм-кодов по паттернам
Loose coupling это слабая связность, а high cohesion сильная сцеппленность
Голова болит от этих микросервисов
бро, ну хватит троллить, когда сделаешь новую серию доктора дью?
Как у нас стали любить все эти красивые фразы на английском и шаблоны... Суть элементарна - есть какой-то метод, обернутый в API, который решает очень маленькую узкую задачу... Тысячи эти методов и образуют микросервисы. Один запросил, второй отдал, третий положил в Kafka, четвертый прочитал и раскидал.... Но ты должен с умным видом все это описывать, оперируя "модными" аббревиатурами ))
Если бы все было так просто) может быть сага, это тоже что-то такое простое и есть аналогии, типа, это просто ... )))
Правильно долой этой английский,надо на старославянском программу писать
К сожалению, на собесах тебе всегда будут задавать вопросы именно используя модные аббревиатуры , а ты должен подыгрывать, чтобы ответить правильно и получить оффер.
Спасибо за видео. В целом, вы просто перечислили что существует без системности и понимания. В целом все правильно, заголовок и не обещает что должны быть какие-то толковые объяснения, но стоило ли вообще давать какие-то ответы? Просто перечислите часто задаваемые вопросы, будет быстрее и не будет вызывать недоумение. Учитывая сколько труда стоило сделать это видео, действительно ли оно того стоило?
Микросервисы на джаве это почти оксюморон :)
Как же достали эти микросервисы. Везде нужен опыт работы с микросервисами, но где его взять-то? У меня вот есть опыт работы несколько лет но без микросервисом я ноль без палочки. Какие-то дурачки составляют вакансии с требованием "микросервисы от 3-х лет" и всё, плевать на остальной опыт и на то, что любой опытный разработчик эту хрень за неделю освоит. Просто идиотизм.
Спасибо за видео. Вы просто перечислили что существует без системности и понимания. В целом все правильно, заголовок и не обещает что должны быть какие-то объяснения, но стоило ли вообще давать какие-то ответы? Просто перечислите часто задаваемые вопросы, будет быстрее и не будет вызывать недоумение. Учитывая сколько труда стоило сделать это видео, действительно ли оно того стоило?
Максим, щиро тобі дякую за твою роботу та бажання зробити цей світ кращим)
Мне кажется, что тебе нужно больше показывать на примерах/картинках инфу. А то воспринимается, как будто тараторишь лекцию в универе
Офигеть, какой актуальный эпиграф. Индеец Соколиный глаз через 8 лет обнаружил, что в камере нет одной стены.
тошо микросервисы мертвы - ща серверлесс
не придумывай) монолиты еще живей всех)
На 10-й минуте смутила фраза про то что каждый экземпляр сервиса может иметь свою базу данных. Никогда такого подхода не видел ранее. Обычно экземпляры одного сервиса работают с одной базой. Максим вы используете такой подход в ваших реальных проектах? И как в этом случае организовано масштабирование? Каждый раз вместе с инстансом сервиса поднимется и новая база данных? Вообще не понятно
скорее он имел ввиду про то, что для множества инстансов одного сервиса существует 1 база
Очень очень много лишнего текста
Нафіга стільки води лити
это шоб на собесе ни спросили того, че ни знаешь)
ого ты накуренный!!!!!!
боже, сколько лишних слов... И как их мало по существу.
Слишком много болтовни
К сожалению рассказываешь не из собственного опыта, и даже не нормально разобравшись в теме, а скорее прочитав десяток таких же "100 самых популярных вопросов" и скомпилировав знания из них. Из-за этого половина рассказанного верна, но не релевантна. Условно спрашивают, что такое трактор, ты говоришь что это штука, на которой можно ездить и она жрет много соляры. И ещё она как-то связана с пьянством. А сама суть подходов и технологий упускается, и твой рассказ бесполезен в реальном мире. Но зато те, кто мечтает стать синьором, будут внимать твоей умной и продающей речи, так ничего к сожалению и не поняв, потому что даже я бы не понял, если бы не знал.
Короче меня запишите в хейтеры. Слишком поверхностно и оттого неверно.