Микросервисная архитектура, подходы и технологии / Кирилл Ветчинкин (TYME) 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

круто!

Вау! Браво!

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

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

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

Спасибо

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

Не понимаю зачем нужно дублировать реализации в разных микросервисах ) 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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