Огинище!!!! Сейчас готовлюсь к собесу в крупный банк на работу мечты!!))) И тут такой материал!!!)))) Благодарность огромная!!! Тысячу бы лайков поставил!!!) Но можно только один!)))
CQRS родился не совсем из EventSourcing-а, изначально был Command-query separation (CQS) который решает проблему сильной разницы в количестве запросов на чтение и запись. И в видео больше сказано именно про него, в то время как у CQRS имеет более строгие ограничения в реализации, главный из которых состоит в том что Comand никогда не возвращает данные, и работа идет в двумя разными бд который синхронизируются обычно через очередь. Этот подход крайне удобен для EventSourcing-а
Ну вопрос синхронизации это уже другой вопрос это могут быть просто master-slave реплики. Если это это база данных одного типа, какой то постгрес например. Если это sql+nosql то тогда нужно свой солюшин писать для синхронизации.
Спасибо Максим, как всегда очень круто! Когда я хотел попасть в престижную консалтинговую компанию меня минут 20 расспрашивали о microservices. Сначала в ролевой игре надо было убедить клиента использовать у себя microservices architecture. Он очень жёстко держался за свой монолит. :) А ещё спросили о microservices orchestration tools таких как Kafka или Zeeba
отличная подача материала! Радуют примеры собеседований и вопросов для более продвинутого уровня. Было бы круто поработать вместе на реальных проектах :)
Говоря о Circuit Breaker, если брать электрические термины, то Апв как аналогия больше подходит. А вообще спасибо за очень полезный ролик, смог некоторые концепции для себя разложить по полочкам
Огромное спасибо автору за краткую систематизацию основных паттернов проектирования мисросервисов. Как раз реализовывали недавно timeout retry через webhook-и
Спасибо за видео. В целом, вы просто перечислили что существует без системности и понимания. В целом все правильно, заголовок и не обещает что должны быть какие-то толковые объяснения, но стоило ли вообще давать какие-то ответы? Просто перечислите часто задаваемые вопросы, будет быстрее и не будет вызывать недоумение. Учитывая сколько труда стоило сделать это видео, действительно ли оно того стоило?
J2EE разве уже не актуальны? Шикарные книжки были для подготовки к сдаче на Sun Certified Enterprise Architect.. Рано списывать то, на чем строили монолиты - вполне себе можно и внутри микросервисов применять. А по микросервисам ничего толкового я не припомню.. мало кто вообще может внятно сформулировать - для чего именно нужен Spring Boot? Включая коучей всяких..
Stability patterns очень хорошо упорядочены в подаче теперь понятно, по какой логике их применять, а то я в принципе знал как их подключить, но как они правильно должны подключаться не знал.
Как у нас стали любить все эти красивые фразы на английском и шаблоны... Суть элементарна - есть какой-то метод, обернутый в API, который решает очень маленькую узкую задачу... Тысячи эти методов и образуют микросервисы. Один запросил, второй отдал, третий положил в Kafka, четвертый прочитал и раскидал.... Но ты должен с умным видом все это описывать, оперируя "модными" аббревиатурами ))
К сожалению, на собесах тебе всегда будут задавать вопросы именно используя модные аббревиатуры , а ты должен подыгрывать, чтобы ответить правильно и получить оффер.
Про CQRS ничего не понял из объяснения. Приемущества cqrs в том что для записи можно использовать один сторейдж например mysql а для чтения совсем другой, например dynamodb и апликухи, которые конектятся к этим сторейджам можно горизонтально скейлить независимо друг от друга. Например если запись в write model у тебя может быть 20 раз в день, а чтение с read model 20 млн в день. То возможно на чтение лучше поставить базу, которая работает быстрее на чтение и отдает например не нормализованные данные, сразу json as is.
При таком перекосе, думаю ее же можно использовать и для записи. Уж 20 раз в день она что-то записать, думаю, сможет. И на скорость чтения єто повлияет примерно никак.
Одна база может выполнять очень тяжёлую работу тормозящую всю базу, например получает каталог из какой нибудь 1С и смерживает с каталогом для сайта, результат реплицируется в базу с которой происходит показ каталога на сайте. Более близкий к паттерну пример - заказ получает с сайта одна база для обработок, воркфлоу итп, и реплицируется в другую базу "в переваренном виде" для показа на сайте в списке заказов клиента. Третий пример классика - логирование идёт в одну базу, а чтение обработанных логов делается из другой базы. Ну и естественно реплик для чтения можно иметь сколько хочешь что повышает скорость и устойчивость.
Микросервисная архитектура - это стиль) Не шаблон. Специально смотрел этот момент и у Ричардсона и на других ресурсах типа azure arcitecture. Большое спасибо за материал, очень много нужного можно почерпнуть)
Для справки 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
@@oeaooя сам мягко говоря не поддерживаю собеседования в стиле телевикторины. Но раз уж так повелось в отрасли, то надо быть точным. Ну и насчёт теоремы cap я бы не был настолько категоричен.
И добавлю что в описании Circuit Breaker стоит описывать состояния не как открытый или закрытый а OPEN - разрыв цепи, CLOSED - соединение цепи, на русском как то это будет понятнее.
Очень мало конечно информации но для джунов и тех кто хочет ими стать ,ултрополезная инфа ,что то услышать новое и инстагуглить ,спасибо огромное ,Макс ,очень полезно в этом деле все время узнавать то, что даже не слышал не разу)))))
Спасибо за видео. Вы просто перечислили что существует без системности и понимания. В целом все правильно, заголовок и не обещает что должны быть какие-то объяснения, но стоило ли вообще давать какие-то ответы? Просто перечислите часто задаваемые вопросы, будет быстрее и не будет вызывать недоумение. Учитывая сколько труда стоило сделать это видео, действительно ли оно того стоило?
Спасибо автору за видео. Согласен с начальной заставкой. Ее поддержали бы также жители Белграда, Ливии, Ирака, городов Газы. Странно только при этом видеть картинку с солдатом известного военного блока на заднем фоне. Я немного застал советское время. О многом в истории просто не знал, многое трактовал субъективно. Чтобы не вестись на идеологическую пропаганду, важно пытаться сохранять критический взгляд и пользоваться разными источниками информации, а не только слушать то, что вещает рупор в стране твоего проживания. Иначе совершенно очевидные противоречия будут для тебя незаметны.
@@nicholasnobody7412разумеется замечали - ирак, ливия, югославия, палестина, .......... . К сожалению если какая то страна нацепила на себя маску всемирного полицейского, она всегда будет пытаться решить свои проблемы военным путём под видом полицейской операции. Ну а к России у этой страны особое отношение, поэтому украина просто попала между молотом и наковальней, точнее стала полем боя для больших стран, а украинцы послужили в качестве одноразовых пулек в этом страйкболе, причём добровольно.
Как же достали эти микросервисы. Везде нужен опыт работы с микросервисами, но где его взять-то? У меня вот есть опыт работы несколько лет но без микросервисом я ноль без палочки. Какие-то дурачки составляют вакансии с требованием "микросервисы от 3-х лет" и всё, плевать на остальной опыт и на то, что любой опытный разработчик эту хрень за неделю освоит. Просто идиотизм.
Вопрос по поводу лайв кодинга на итервью. Почему дают кандидатам какие-то тупые ненужные задачи, когда можно, например, дать задачу написать простой микросервис с различными плюшками? Можно с Х2 базой данных, или пописать эксепшн хендлеры всякие. То, что в реальной жизни имеет смысл.
Отличный вопрос 👍 Но тут все просто. Времени столько нет чтобы сервисы организовывать, базы подключать. Если хочется проверить дизайнерские возможности кандидата, то как правило дают задачу на дом. Тогда человек в спокойной обстановке сможет все обдумать и собрать. За 1,5 часа познакомиться, вникнуть в задачу, прояснить детали и решить… просто нереально. Конечно же дают задачи. Но такие задачи отражают предметную область и не требуют сложных манипуляций. Как правило, это задачи на системный дизайн из предметной области бизнеса. Вот пример реальный: «Реализуйте метод для перевода средств с одного счета на другой». Разумеется там выдвигается куча требований: - многопоточка - отсутствие овердрафтов - проверки валидности данных - возможность работы в распределениях системах - и тд
@@Jetbulb На спрингбуте с гуглом любой достойный кандитат успеет что-нибудь да сделать. Я скорее про то, что частенько дают задачи, которые не имеют смысла в применении в реальной жизни. Я это по собственному опыту сужу, а также по Вашим видео.В целом, на интервью очень много теории, которая не дает гарантии хорошего кодинга, в чем я лично вижу разницу между джуном, мидом и синьором. Решить задачу может любой, а вот сделать ее хорошо - совсем другое дело. Я менторю людей по кодингу, и не понимаю, как некоторые из них прошли интервью на сеньор позиции. С большинством интервью явно что-то не так, но не могу сказать, как это сделать лучше )))).
Большое спасибо за интересный ролик. В тему(или не очень) микросервисов, уважаемы Максим, хотелось бы узнать ваше мнение насчёт DDD. Недавно начал изучать тему, читаю книгу Вона Вернона, но пока все выглядит немного абстрактно и на уровне лозунгов. Возможно приходилось применять этот подход на практике?
Совсем скоро будет новый выпуск. Он будет посвящен DDD. Там можно будет получить много ответов )) Если кратко, DDD это и есть форма абстракции при которой бизнес-потребности могут быть обрисованы на языке понятном для технических специалистов. Таком себе контракт между "технарем" и "нетехнарем".
Неее. В дагонку полетит вопрос, если для нас так критична последовательность транзакций, то как быть если один сервис уже обработал т1, т2 и т3, а другой ещё не закончил обработку т1.
Привіт)) На мій погляд, за посиланням можливо знайти все що треба www.baeldung.com/spring-boot Також рекомендую офіційну документацію docs.spring.io/spring-boot/docs/current/reference/htmlsingle/
К сожалению рассказываешь не из собственного опыта, и даже не нормально разобравшись в теме, а скорее прочитав десяток таких же "100 самых популярных вопросов" и скомпилировав знания из них. Из-за этого половина рассказанного верна, но не релевантна. Условно спрашивают, что такое трактор, ты говоришь что это штука, на которой можно ездить и она жрет много соляры. И ещё она как-то связана с пьянством. А сама суть подходов и технологий упускается, и твой рассказ бесполезен в реальном мире. Но зато те, кто мечтает стать синьором, будут внимать твоей умной и продающей речи, так ничего к сожалению и не поняв, потому что даже я бы не понял, если бы не знал.
Согласен. Я немного работал с микросервисной архитектурой, но у меня сложилось аналогичное впечатление от рассказанного, как будто у автора у самого каша в голове.
На 10-й минуте смутила фраза про то что каждый экземпляр сервиса может иметь свою базу данных. Никогда такого подхода не видел ранее. Обычно экземпляры одного сервиса работают с одной базой. Максим вы используете такой подход в ваших реальных проектах? И как в этом случае организовано масштабирование? Каждый раз вместе с инстансом сервиса поднимется и новая база данных? Вообще не понятно
Так легко и позитивно препадаешь информацию, что с легкостью можно включить утром и послушать пока умываешся.
Спасибо друг!
Огинище!!!! Сейчас готовлюсь к собесу в крупный банк на работу мечты!!))) И тут такой материал!!!)))) Благодарность огромная!!! Тысячу бы лайков поставил!!!) Но можно только один!)))
Один лайк уже как тысяча))
Респект!
С других аккаунтов ставь :)
Сбер на 250к?)
@@Dmitri915 450
Как работа?
Спасибище!!!
Сколько не учись - всю жизнь что-то новое узнаешь)) Крутой материал!
CQRS родился не совсем из EventSourcing-а, изначально был Command-query separation (CQS) который решает проблему сильной разницы в количестве запросов на чтение и запись. И в видео больше сказано именно про него, в то время как у CQRS имеет более строгие ограничения в реализации, главный из которых состоит в том что Comand никогда не возвращает данные, и работа идет в двумя разными бд который синхронизируются обычно через очередь. Этот подход крайне удобен для EventSourcing-а
Ну вопрос синхронизации это уже другой вопрос это могут быть просто master-slave реплики. Если это это база данных одного типа, какой то постгрес например. Если это sql+nosql то тогда нужно свой солюшин писать для синхронизации.
Невероятное количество полезной информации, благодарю!
Очень полезно! Макс, спасибо👍👍👍
Спасибо Максим, как всегда очень круто! Когда я хотел попасть в престижную консалтинговую компанию меня минут 20 расспрашивали о microservices. Сначала в ролевой игре надо было убедить клиента использовать у себя microservices architecture. Он очень жёстко держался за свой монолит. :)
А ещё спросили о microservices orchestration tools таких как Kafka или Zeeba
Самое прикольное было бы если бы в том же собеседовании попросили "а теперь убеди меня использовать монолит"
отличная подача материала! Радуют примеры собеседований и вопросов для более продвинутого уровня. Было бы круто поработать вместе на реальных проектах :)
Спасибо! Актуально и увлекательно❤
Очередной коммент для продвижения авансом. Спасибо)
вот это я понимаю контент, спасибо вам большое
Говоря о Circuit Breaker, если брать электрические термины, то Апв как аналогия больше подходит. А вообще спасибо за очень полезный ролик, смог некоторые концепции для себя разложить по полочкам
Очень полезно, спасибо!
Огромное спасибо автору за краткую систематизацию основных паттернов проектирования мисросервисов. Как раз реализовывали недавно timeout retry через webhook-и
Здорово, очень полезный материал. На сколько помню проводил опрос про реактивщину, если это было в твоём тг то очень сильно жду)
Да, в ТГ-канале уже было неоднократно про реактивы)
И будет еще)))
Спасибо за отзыв!
Самое глубокое и информативное объяснение
Макс, сколько новых слов 😅 Спасибо большое!
Спасибо за видео. В целом, вы просто перечислили что существует без системности и понимания. В целом все правильно, заголовок и не обещает что должны быть какие-то толковые объяснения, но стоило ли вообще давать какие-то ответы? Просто перечислите часто задаваемые вопросы, будет быстрее и не будет вызывать недоумение. Учитывая сколько труда стоило сделать это видео, действительно ли оно того стоило?
Спасибо! 👍👍👍
Подача огонь! Спасибо)
J2EE разве уже не актуальны? Шикарные книжки были для подготовки к сдаче на Sun Certified Enterprise Architect.. Рано списывать то, на чем строили монолиты - вполне себе можно и внутри микросервисов применять. А по микросервисам ничего толкового я не припомню.. мало кто вообще может внятно сформулировать - для чего именно нужен Spring Boot? Включая коучей всяких..
Классная подача)
Интересно смотреть
Stability patterns очень хорошо упорядочены в подаче теперь понятно, по какой логике их применять, а то я в принципе знал как их подключить, но как они правильно должны подключаться не знал.
Как у нас стали любить все эти красивые фразы на английском и шаблоны... Суть элементарна - есть какой-то метод, обернутый в API, который решает очень маленькую узкую задачу... Тысячи эти методов и образуют микросервисы. Один запросил, второй отдал, третий положил в Kafka, четвертый прочитал и раскидал.... Но ты должен с умным видом все это описывать, оперируя "модными" аббревиатурами ))
Если бы все было так просто) может быть сага, это тоже что-то такое простое и есть аналогии, типа, это просто ... )))
Правильно долой этой английский,надо на старославянском программу писать
К сожалению, на собесах тебе всегда будут задавать вопросы именно используя модные аббревиатуры , а ты должен подыгрывать, чтобы ответить правильно и получить оффер.
Про CQRS ничего не понял из объяснения. Приемущества cqrs в том что для записи можно использовать один сторейдж например mysql а для чтения совсем другой, например dynamodb и апликухи, которые конектятся к этим сторейджам можно горизонтально скейлить независимо друг от друга. Например если запись в write model у тебя может быть 20 раз в день, а чтение с read model 20 млн в день. То возможно на чтение лучше поставить базу, которая работает быстрее на чтение и отдает например не нормализованные данные, сразу json as is.
Полезно, спасибо
При таком перекосе, думаю ее же можно использовать и для записи. Уж 20 раз в день она что-то записать, думаю, сможет. И на скорость чтения єто повлияет примерно никак.
@@yuriy.kostenko Так это образно. В реальных проектах совсем другие цифры.
Одна база может выполнять очень тяжёлую работу тормозящую всю базу, например получает каталог из какой нибудь 1С и смерживает с каталогом для сайта, результат реплицируется в базу с которой происходит показ каталога на сайте. Более близкий к паттерну пример - заказ получает с сайта одна база для обработок, воркфлоу итп, и реплицируется в другую базу "в переваренном виде" для показа на сайте в списке заказов клиента. Третий пример классика - логирование идёт в одну базу, а чтение обработанных логов делается из другой базы. Ну и естественно реплик для чтения можно иметь сколько хочешь что повышает скорость и устойчивость.
Короче, что я понял. Самое главное в микросервисах что? Не угадаете. Сторителлинг!
Как всегда! Просто лучший формат видео!
Микросервисная архитектура - это стиль) Не шаблон. Специально смотрел этот момент и у Ричардсона и на других ресурсах типа 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 я бы не был настолько категоричен.
И добавлю что в описании Circuit Breaker стоит описывать состояния не как открытый или закрытый а OPEN - разрыв цепи, CLOSED - соединение цепи, на русском как то это будет понятнее.
Голова болит от этих микросервисов
Максим, щиро тобі дякую за твою роботу та бажання зробити цей світ кращим)
Привет! Спасибо за видео)
Было бы супер, если бы писал названи терминов, которые упоминаешь, чтобы лучше связывать через визуальное восприятие
спасибо за видео !!1!1
Очень мало конечно информации но для джунов и тех кто хочет ими стать ,ултрополезная инфа ,что то услышать новое и инстагуглить ,спасибо огромное ,Макс ,очень полезно в этом деле все время узнавать то, что даже не слышал не разу)))))
Джунам ничего из этого ещё долго не пригодится, да и 100% на джуновском собесе таких вопросов не будет
@@Denis-sds сейчас вроде такая ситуация, что бы стать джуном нужно знать инфу на мидла
Спасибо за видео. Вы просто перечислили что существует без системности и понимания. В целом все правильно, заголовок и не обещает что должны быть какие-то объяснения, но стоило ли вообще давать какие-то ответы? Просто перечислите часто задаваемые вопросы, будет быстрее и не будет вызывать недоумение. Учитывая сколько труда стоило сделать это видео, действительно ли оно того стоило?
Благодарю!
Спасибо автору за видео.
Согласен с начальной заставкой. Ее поддержали бы также жители Белграда, Ливии, Ирака, городов Газы. Странно только при этом видеть картинку с солдатом известного военного блока на заднем фоне.
Я немного застал советское время. О многом в истории просто не знал, многое трактовал субъективно. Чтобы не вестись на идеологическую пропаганду, важно пытаться сохранять критический взгляд и пользоваться разными источниками информации, а не только слушать то, что вещает рупор в стране твоего проживания. Иначе совершенно очевидные противоречия будут для тебя незаметны.
Дисклеймер в начале в самое сердечко. ❤
Ну хоть сейчас до вас дошло, что мир это хорошо, а нападать на другие страны - это плохо. Столько лет вы ничего не замечали.
@@nicholasnobody7412 до кого до вас? Эти Вы с тобой в одной комнате?
@@dreamer_vi905 до тебя и тебе подобных.
@@dreamer_vi905 до тебя и тебе подобных. Могу потом ещё пару раз, если медленно доходит.
@@nicholasnobody7412разумеется замечали - ирак, ливия, югославия, палестина, .......... . К сожалению если какая то страна нацепила на себя маску всемирного полицейского, она всегда будет пытаться решить свои проблемы военным путём под видом полицейской операции. Ну а к России у этой страны особое отношение, поэтому украина просто попала между молотом и наковальней, точнее стала полем боя для больших стран, а украинцы послужили в качестве одноразовых пулек в этом страйкболе, причём добровольно.
Когда читал книжку по паттернам тоже удивлялся, что оказывается абстрактный класс это тоже шаблон. Так и тут, оказывается ретрай - эт шаблон
Круто! спасибо!! Не совсем понял про снапшоты на 12:30
Как же достали эти микросервисы. Везде нужен опыт работы с микросервисами, но где его взять-то? У меня вот есть опыт работы несколько лет но без микросервисом я ноль без палочки. Какие-то дурачки составляют вакансии с требованием "микросервисы от 3-х лет" и всё, плевать на остальной опыт и на то, что любой опытный разработчик эту хрень за неделю освоит. Просто идиотизм.
Отличное видео, затмевает только увы картинка про корабль и т. П.
Полезно👍
В результате каждый микросервис разрастается толще монолита.
Вопрос по поводу лайв кодинга на итервью. Почему дают кандидатам какие-то тупые ненужные задачи, когда можно, например, дать задачу написать простой микросервис с различными плюшками? Можно с Х2 базой данных, или пописать эксепшн хендлеры всякие. То, что в реальной жизни имеет смысл.
Отличный вопрос 👍
Но тут все просто. Времени столько нет чтобы сервисы организовывать, базы подключать. Если хочется проверить дизайнерские возможности кандидата, то как правило дают задачу на дом. Тогда человек в спокойной обстановке сможет все обдумать и собрать.
За 1,5 часа познакомиться, вникнуть в задачу, прояснить детали и решить… просто нереально.
Конечно же дают задачи. Но такие задачи отражают предметную область и не требуют сложных манипуляций. Как правило, это задачи на системный дизайн из предметной области бизнеса.
Вот пример реальный: «Реализуйте метод для перевода средств с одного счета на другой». Разумеется там выдвигается куча требований:
- многопоточка
- отсутствие овердрафтов
- проверки валидности данных
- возможность работы в распределениях системах
- и тд
@@Jetbulb На спрингбуте с гуглом любой достойный кандитат успеет что-нибудь да сделать. Я скорее про то, что частенько дают задачи, которые не имеют смысла в применении в реальной жизни. Я это по собственному опыту сужу, а также по Вашим видео.В целом, на интервью очень много теории, которая не дает гарантии хорошего кодинга, в чем я лично вижу разницу между джуном, мидом и синьором. Решить задачу может любой, а вот сделать ее хорошо - совсем другое дело. Я менторю людей по кодингу, и не понимаю, как некоторые из них прошли интервью на сеньор позиции. С большинством интервью явно что-то не так, но не могу сказать, как это сделать лучше )))).
Скажи, пожалуйста, с какой книги можно начать, чтобы войти в эту тему? С кабаном?
мне заходит microservices.io/
на этом сайте более чем подробно все расписано. как точка вхождения отлично помогает
Осталось только понять в чём преимущество микросервисной архитектуры если гемора больше чем у монолита.
Loose coupling это слабая связность, а high cohesion сильная сцеппленность
Офигеть, какой актуальный эпиграф. Индеец Соколиный глаз через 8 лет обнаружил, что в камере нет одной стены.
бро, ну хватит троллить, когда сделаешь новую серию доктора дью?
Большое спасибо за интересный ролик.
В тему(или не очень) микросервисов, уважаемы Максим, хотелось бы узнать ваше мнение насчёт DDD. Недавно начал изучать тему, читаю книгу Вона Вернона, но пока все выглядит немного абстрактно и на уровне лозунгов. Возможно приходилось применять этот подход на практике?
Axon Framework вам в помощь
Совсем скоро будет новый выпуск. Он будет посвящен DDD.
Там можно будет получить много ответов ))
Если кратко, DDD это и есть форма абстракции при которой бизнес-потребности могут быть обрисованы на языке понятном для технических специалистов. Таком себе контракт между "технарем" и "нетехнарем".
Жаль, что нет тайм-кодов по паттернам
Неее. В дагонку полетит вопрос, если для нас так критична последовательность транзакций, то как быть если один сервис уже обработал т1, т2 и т3, а другой ещё не закончил обработку т1.
Изоляция?
Из 40 минут 4 воды в начале. 10 % это очень много даже для скорости 1.5
Здравствуйте! А что посоветуете по микросервисам для джуна?)
Неплохой точкой вхождения может стать материал по ссылке ниже
microservices.io/
Мне кажется, что тебе нужно больше показывать на примерах/картинках инфу. А то воспринимается, как будто тараторишь лекцию в универе
Привіт Макс, чи можеш підказати, як дізнатися чи можна скейлити Спрінг Бут сервіс? Можливо знаєш якийсь ресурс де можна почитати. Буду дуже вдячний)
Привіт))
На мій погляд, за посиланням можливо знайти все що треба
www.baeldung.com/spring-boot
Також рекомендую офіційну документацію
docs.spring.io/spring-boot/docs/current/reference/htmlsingle/
Микросервисы на джаве это почти оксюморон :)
К сожалению рассказываешь не из собственного опыта, и даже не нормально разобравшись в теме, а скорее прочитав десяток таких же "100 самых популярных вопросов" и скомпилировав знания из них.
Из-за этого половина рассказанного верна, но не релевантна. Условно спрашивают, что такое трактор, ты говоришь что это штука, на которой можно ездить и она жрет много соляры. И ещё она как-то связана с пьянством.
А сама суть подходов и технологий упускается, и твой рассказ бесполезен в реальном мире. Но зато те, кто мечтает стать синьором, будут внимать твоей умной и продающей речи, так ничего к сожалению и не поняв, потому что даже я бы не понял, если бы не знал.
Короче меня запишите в хейтеры. Слишком поверхностно и оттого неверно.
Согласен. Я немного работал с микросервисной архитектурой, но у меня сложилось аналогичное впечатление от рассказанного, как будто у автора у самого каша в голове.
@@Warrior_Shadeдополню насчёт каши - он её ещё и на нас вылил. Горшочек не вари!
боже, сколько лишних слов... И как их мало по существу.
На 10-й минуте смутила фраза про то что каждый экземпляр сервиса может иметь свою базу данных. Никогда такого подхода не видел ранее. Обычно экземпляры одного сервиса работают с одной базой. Максим вы используете такой подход в ваших реальных проектах? И как в этом случае организовано масштабирование? Каждый раз вместе с инстансом сервиса поднимется и новая база данных? Вообще не понятно
скорее он имел ввиду про то, что для множества инстансов одного сервиса существует 1 база
Слишком много болтовни
Нафіга стільки води лити
это шоб на собесе ни спросили того, че ни знаешь)
тошо микросервисы мертвы - ща серверлесс
не придумывай) монолиты еще живей всех)
Очень очень много лишнего текста
ого ты накуренный!!!!!!
Наконец-то петличка, а не микрофон на все лицо в кадре)). Крутой материал!