классная презентация! очень доходчиво

Интересный доклад. Респект!

Шикарно, спасибо!

Отличный доклад! Спасибо!

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

автор молодец, очень доходчиво и из реальных кейсов

Очень доходчиво рассказывает

Благодарю за доклад!

Спасибо, многое разъяснили в голове)

Очень полезное видео! Спасибо!

Спасибо! отличное видео. немало узнал идей которые уже делали

Очень просто и доходчиво обьясняешь-респект)

Жаль нельзя поставить несколько лайков! Один из лучших докладов!

Спасибо большое!

Вау! Браво!

Огромное спасибо! Очень крутая тема, очень хорошо рассказано! Сами так делаем. Делаешь например расчетчик в виде микросервиса и пожалуйста, возникли проблемы с нагрузкой разворачивай хоть на 10 сереров, хоть на 100 персоналок. Часть упала, пофиг досчитается на остальных. Просто устанавливаешь сервис на машину и настраиваешь в конфиге параметры очереди! Понравилось также, что сказал, что не надо делать DAL сервис, т.к. бесит на самом деле гонять данные через него, особоенно большие. Успехов!

Супер, очень много полезного

Уже раз пятый смотрю )), супер интересно

Очень хороший доклад

Видимо парням очень хотелось получить опыт, нужный в реальном хайлоаде и они под 200rps, с которым справиться любой монолит, запилили модную архитектуру

круто!

Очень крутой cook book получился, узнал для себя новые моменты, буду использовать в работе. Но соглашусь с другим комментатором, на 200 rps это все не нужно)) Как стрелять из пушки по воробьям

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

Спасибо

Классный доклад

Не понимаю зачем нужно дублировать реализации в разных микросервисах ) 6:00 ok - тут пояснения 28:50

круто

мы изобрели пару лет назад велосипед и у нас почти получилось)

На самом деле там не пустые прямоугольники, текст в них виден только просвященным

а в чем проблема в рамках монолитной архитектуры разбить приложение на модули/компоненты которыми будут заниматься отдельные команды? почему в рамках монолита мы не можем переиспользовать какие-то куски? что за чушь вообще? это емнип называется компоненто-ориентированная архитектура и точно так же как вы можете использовать хибернейт в разных приложениях что вам мешает так же использовать свой собственный ОРМ или расширение того же хибернейта?

Вот за что я не люблю хайлоад. Вышел красавчик рассказал какие они хорошие. Позовите ихнованных опсов они расскажут всю правду.

Сколько строк кода у Вас в микросервисах, что ">25 микросервисов" это большие система?

А можно ли на го писать не микросервисы, а там например простой блог?

Почему никто не говорит, что микросервисная архетектура работает медленнее чем монолит ??

46:04 Как как вас зовут? Голодный?

16:26 Я думаю, вы не правильно сделали, создав API, которое напрямую связано с сервисами. Я тоже для себя разрабатываю такую систему. Пока она на уровне архитектуры, но в этом плане моя идея с вами расходится. Хотя всё остальное - то же самое. И как думаю я: нужно, чтобы API-морда была соединена с брокером сообщений, а не с сервисами напрямую. Во-первых, это делает их по-настоящему независимыми и изолированными, а во-вторых, брокер становится центром, который связывает друг с другом все части системы. К тому же он может хранить сообщения от API, которые ещё не обработаны и сохранять их на случай сбоя. В вашем же варианте API дёргает каждый модуль, когда ему вздумается, что может этот модуль подвесить, да и плюс это не безопасно. Прямых связей между модулями нужно избегать. Единственная прямая связь, которая должна быть у модуля - это связь с брокером, причём брокер должен работать по запросу - в стиле Kafka, чтобы, опять же, не дёргать модуль, когда тот занят (как это делает RabbitMQ). А API - это тоже, по сути, модуль. А у вас получается, что ваши модули связаны не только с брокером, но и с API. Это лишняя зависимость. Достаточно только брокера. Это и проще контролировать и логичнее выглядит.

Для справки, JMS - это не протокол, а API. И указывать её на слайде на 13:20 не стоило - это грубая ошибка. Тот же AMQP доступен в Java через JMS.

резанули ухо слова, а шина гарантирует доставку до получателя :)))

Не совсем понятно почему монолиит сложно горизонтально масштабировать. И почему нельзя переисаользоват код, пишешь как пакет и все.

а мне интересно, когда у вас 100500 запросов в секунду и один из сервисов не ацкает задачу из-за повторяющейся ошибки... Что будет с системой, когда память закончится? Вот написал и предположу, что помимо шины по-любому нужно хранить таски ещё и в бд с состояниями/статусами по всем пройденным микросервисам. Либо всё-таки мутить псевдотранзакционность с откатами и следить, чтобы ошибка по задаче не повторялась более N раз. Но реальные кейсы с решениями хотелось бы узнать.

Молодцы ребята, наняли Маслякова ведущим

Внедряли туда - куда не нужны - все что нужно знать о микросервисах

с упавшим брокером и БД какой-то вообще лютый велосипед

Это Вы на несчастных 200RPS определили что микросервисы подходят для высоких нагрузок? В чём проблема горизонтально масштабировать монолит? Каким образом микросервисы вообще решают проблему горизонтального масштабирования? В монолите плохая отказоустойчивость, а в микросервисах, где одни точки отказа, отличная?

Простите, 200 rps в пике это не мало, это не о чем

Я правильно понял, что говоря про микросервисы автор подразумевал много много монолитов?

Ну да, переиспользовать код в монолите вообще не возможно. Это все что нужно знать о современных разработчиках и архитекторах.

Есть определение микросервисов? Что это такое? Почему нельзя говорит подпроект?

Что? В монолите код невозможно использовать повторно??? Хайлоад начинается от 200 оп.сек? Про остальное вообще молчу. Монолит вам нужен только для того, чтобы поддерживать СВОЙ стек в актуальном состоянии!

Комитить в один репозиторий не сложно.

распределенность ради распределенности, микросервисы ради микросервисов, сплошная антиреклама микросервисов.

9:40 такой распил грозит большими проблемами со связностью в будущем.

Ээээм, чувак несёт чушь в вопросе rabbit-а и асинхроники. Описанная им схема в такой форме вообще нихрена не гарантирует. И нужен комплект контроля над рэббитом и сервисами. И да, рэббит гарантирует доставку только если не упал, это первое, а второе, то, что рэббит доставил сообщение - не гарантирует, что оно будет обработано. так что никакой гарантии здесь нет от слова совсем

как это нет трансакций? а distributed transactions это что? например Кафка или МонгоДБ поддерживают трансакции, хотя могут быть на разных нодах данные. Так что, возможно, но сложно

Доклад - прекрасный (хотя и очень поверхностный) сборник антипаттернов реализации микросервисной (вернее - просто распределенной) архитектуры. Какой пункт не возьми - всюду используется или неоптимальное решение или просто неверное утверждение, в лучшем случае - собственные костыли Грустно (

Идиотский подход. Плагины уже отменили?

Ключевое, перескажу: это модно, поэтому, чтобы привлечь новых, молодых, модных же разрабов, надо быть в модном тренде. Дичь, но, видимо, это и есть круговорот жизни.

очередной раз только убеждаюсь что микросервисы это новомодный бред. говорит о том что они убирают геморой, а потом сразу вываливает весь другой геморой этого микротанца с бубном...

Слабый и несфокусированный доклад

"Это не серебряная пуля..." )))) Вообще-то есть нормальные аналоги на русском: не панацея, не волшебная палочка, не магическое средство...