Согласен. Уважаю людей способных признать свои ошибки. Ненавижу руководителей не способных это сделать - бегите от них, такие ничего хорошего с проектом не сделают и вам не дадут.
Огромное спасибо! Очень крутая тема, очень хорошо рассказано! Сами так делаем. Делаешь например расчетчик в виде микросервиса и пожалуйста, возникли проблемы с нагрузкой разворачивай хоть на 10 сереров, хоть на 100 персоналок. Часть упала, пофиг досчитается на остальных. Просто устанавливаешь сервис на машину и настраиваешь в конфиге параметры очереди! Понравилось также, что сказал, что не надо делать DAL сервис, т.к. бесит на самом деле гонять данные через него, особоенно большие. Успехов!
А потом приходит настоящий программист, смотрит на код вашего расчетчика, говорит "что за дебилы, не учившиеся высшей математике и даже не читавшие Кнута, писали" (а большинство пейсателей микросервисов - они после юридического и курсов верстки html в профессии, к сожалению) и за 2 часа реализует новый "расчетчик", который всё нужное считает на 4 порядка быстрее и факт уменьшения расходов на процессорные мощности на амазоне на те же 4 порядка вынуждает руководителя проекта уволить нахер половину мамкиных пейсателей микросервисов, потому что скрыть это перед заказчиком уже невозможно, а значит невозможно обосновывать зубодробительный бюджет внедрения, под который и набрали мамкиных пейсателей микросервисов. История из жизни, к сожалению. А чё? Похер же на отдельные сервисы и качество их работы- пущай падают и тормозят - пара кликов и амазон сам нагенерит кучу копий серверов, а ещё пара кликов - и кубернетис сам всё свяжет и настроит...
Видимо парням очень хотелось получить опыт, нужный в реальном хайлоаде и они под 200rps, с которым справиться любой монолит, запилили модную архитектуру
Очень крутой cook book получился, узнал для себя новые моменты, буду использовать в работе. Но соглашусь с другим комментатором, на 200 rps это все не нужно)) Как стрелять из пушки по воробьям
16:26 Я думаю, вы не правильно сделали, создав API, которое напрямую связано с сервисами. Я тоже для себя разрабатываю такую систему. Пока она на уровне архитектуры, но в этом плане моя идея с вами расходится. Хотя всё остальное - то же самое. И как думаю я: нужно, чтобы API-морда была соединена с брокером сообщений, а не с сервисами напрямую. Во-первых, это делает их по-настоящему независимыми и изолированными, а во-вторых, брокер становится центром, который связывает друг с другом все части системы. К тому же он может хранить сообщения от API, которые ещё не обработаны и сохранять их на случай сбоя. В вашем же варианте API дёргает каждый модуль, когда ему вздумается, что может этот модуль подвесить, да и плюс это не безопасно. Прямых связей между модулями нужно избегать. Единственная прямая связь, которая должна быть у модуля - это связь с брокером, причём брокер должен работать по запросу - в стиле Kafka, чтобы, опять же, не дёргать модуль, когда тот занят (как это делает RabbitMQ). А API - это тоже, по сути, модуль. А у вас получается, что ваши модули связаны не только с брокером, но и с API. Это лишняя зависимость. Достаточно только брокера. Это и проще контролировать и логичнее выглядит.
Любую бизнес-систему можно разделить на данные, логику в виде разрабатываемого ПО и среду. Задача хайлоуд - быстро развернуть и масштабировать ПО и среду, чтобы клиент мог работать с данными
а в чем проблема в рамках монолитной архитектуры разбить приложение на модули/компоненты которыми будут заниматься отдельные команды? почему в рамках монолита мы не можем переиспользовать какие-то куски? что за чушь вообще? это емнип называется компоненто-ориентированная архитектура и точно так же как вы можете использовать хибернейт в разных приложениях что вам мешает так же использовать свой собственный ОРМ или расширение того же хибернейта?
Не стоит писать про чушь, если вы чего-то не поняли. Представьте себе, что у вас в рамках монолита одна часть приложения требует больше нагрузки, другая меньше, третья - средне. В рамках монолита для масштабирования вам придётся разворачивать ВЕСЬ монолит целиком и выделять памяти кратно больше на ВСЁ приложение, хотя вам столько не нужно, а нужномастшабировать только его часть. После разбиения вы можете запустить 10 контейнеров для одной части, 2 для другой и 1 для третьей, наименее нагруженной. Если нагрузка на третью часть в какой-то момент вырастает - добавляете ещё один контейнер, и это НИКАК не влияет на остальные сервисы. Пример из доклада - "платежи" и "история платежей" - вроде бы одна сущность, платёж, и данные должны храниться вместе. Но по факту - совершение платежей происходит намного чаще, чем запрос истории, то есть платежи совершённые сегодня - важнее и чаще запрашиваются чем, те, что были совершены неделю, месяц и тем более - год назад. Поэтому есть смысл разделить эти две сущности на разные сервисы.
это не правда. если разделить на правильные ограниченные контексты, которые не имеют зацеплений, тогда не будет никакого вообще замедления. например есть огромная база продукции, нам поставили задачу сделать витрину каких-то особенных продуктов с дикими фильтрами. завели микросервис, в него загрузили продукты из шины, побили при помощи СQRS на модель записи (то что летит из монолита), модель чтения - индексы в эластике под всякие влажные фантазии бизнеса. основная нагрузка это эластик - его на отдельные виртуалки. мало? кластер. можно не эластик. касандру например. и вот монолит живет себе как и жил. никто в его репе не пишет дикий код про работу с эластиком. а отдельная команда работает в отдельной репе, выпускает отдельные релизы. это офигеть как упрощает разработку. а значит - приносит деньги. и где здесь может работать медленнее? ну а если конечно прилетает запрос на микросервис, а он лезет за данными в другие три при помощи http - тогда, да. будет полная Ж. про это докладчик тоже рассказывал.
Это Вы на несчастных 200RPS определили что микросервисы подходят для высоких нагрузок? В чём проблема горизонтально масштабировать монолит? Каким образом микросервисы вообще решают проблему горизонтального масштабирования? В монолите плохая отказоустойчивость, а в микросервисах, где одни точки отказа, отличная?
микросервисы в нормальной реализации дадут вам изоляцию и graceful degradation так сказать. Может отвалиться конкретный сервис и приложение продолжит работать с частичной потерей функциональности. Как вот любят амазон приводить в пример. У них может отвалиться вообще вся система заказов, но главное, чтобы можно было класть в корзину, а там как-нить потом разрулят. Главное не пугать людей ошибками. Монолит если упадет, то упадет весь и пиши пропало. Проблема масштабировать монолит в том, что часто он пишется так, что это невозможно сделать. Огромный кусок кода, который ничего вокруг себя не видит и считает себя центром вселенной. Микросервисы сами по себе это не решают, но как подход он заставляет/поощрает/так принято писать так, что они потом легко масштабируются. Они изначально пишутся обычно так, чтобы быть готовыми, что вокруг них еще куча подвижных частей и надо как можно меньше состояния держать в себе. Везде свои нюансы конечно и микросервисы приносят много головной боли на девопсов, но они имеют свои преимущества, которые нужно просто понимать, а не кидаться на хайп или хейт. Как обычно, новомодную хрень либо хейтят, либо хайпят бездумно.
@@ErrorsMissing каким образом? База у вас легла, память кончилась, сборщик мусора повесил систему, коннекты до базы переполнились и еще миллион всяких ситуация, не говоря о багах своих собственных. Где у вас тут будет все это? Упадет все и сразу. Если у вас монолит может в нескольких экземплярах подниматься, то хоть как-то спасет, но это редко. Обычно один бэкэнд на всю систему. Чтобы монолит писать таким образом, это надо охренеть как подумать. А традиционно, а тем более в легаси системах, принцип простой - работает или все, или ничего. Если один какой-то метод кинул исключение, то нахер вся транзакция отваливается и юзеру выплевывается ошибка.
>> База у вас легла А Вы считаете что если используете микросервисы, то база уже не нужна? >> память кончилась, сборщик мусора повесил систему Это же касается и микросервисов. Разница лишь в том, что пока один инстанс микросервиса держит нагрузку, то решение таких проблем через резервирование, иначе как и в монолите - балансировка. Далее по тексту - полнейший бред. Подходы с отработкой исключений и тд одинаковый. Разделять на контексты Вам никто не запрещает. Инкапсуляцию никто не отменял. Про то что в монолите всё и сразу упадёт вообще идиотизм - Вы или обрабатываете всевозможные кейсы и тогда по возможности только часть системы не работает, или игнорируете данные правила и тогда всё лежит, И тут нет разницы монолит это или миллионы сервисов.
>> А Вы считаете что если используете микросервисы, то база уже не нужна? Я считаю, что вы ни видео не смотрели, ни про тему ничего не читали. Традиционно у каждого сервиса своя база. Упадет база одного сервиса - упадет этот один сервис. >> Это же касается и микросервисов. Да, только в их случае это коснется конкретных сервисов. >> И тут нет разницы монолит это или миллионы сервисов. Повторим еще раз. Это коснется одного конкретного сервиса, который от этого пострадал. Падение всей системы от одного неудачного null reference exception это, к сожалению, далеко не бред. И в случае монолита он грохнется весь и сразу. Если у вас монолит умеет работать в нескольких экземплярах и балансировать нагрузку, то вы уже заранее не в тех условиях, о которых обычно речь. В этом случае вам может достаточно распилить код на часть и у вас уже микросервисы, т.к. все написано правильно. Просто они прикидываются монолитом. В общем, идите туториалы читайте. Как и писал, либо бездумный хейт, либо хайп. Разберитесь в сути темы для начала.
Монолит сложно масштабировать, если требуется масштабировать конкретный функционал,например отправку sms, в случае с микросервисами можно поднять доп контейнеры отправляющие sms, а с монолитом пришлось бы вообще все приложение поднимать. А с кодом проблема в том, что микросервисы оч часто и быстро меняются и если написать библиотеку для трех микросервисов, то теперь эти микросервисы сильно зависят от этой бибилитеки и их сложно менять
Что? В монолите код невозможно использовать повторно??? Хайлоад начинается от 200 оп.сек? Про остальное вообще молчу. Монолит вам нужен только для того, чтобы поддерживать СВОЙ стек в актуальном состоянии!
Можно, только это будет проблемнее, особенно, если захочется иметь хороший встроенный шаблонизатор, а не отдельный бэк+фронт. Для простых блогов проще взять PHP-фреймворк (Laravel/Symfony) или вообще CMS а-ля wordpress
@@brodlovherrsov7097 да вы что? Это чем же сложно? Оформил оператор в отдельный класс и Алга. Дерзай его из любого места. Даже в старую функцию в мейне можно обернуть, если код часто нужен много где. В монолите то как раз проще делать реюз кода, ибо он при добавлении новой функции, использщей куски других функций тебе гораздо меньше надо сношаться по теме импорта и зависимостей кода.
Net Fret вы там в зарубежных банках головой в хранилище железное бьетесь на кастинге? У вас любой исходник на любом языке начинается со слов import или include, или use. Это и есть переиспользовние кода и его изобрели полвека назад, даже побольше.
а мне интересно, когда у вас 100500 запросов в секунду и один из сервисов не ацкает задачу из-за повторяющейся ошибки... Что будет с системой, когда память закончится? Вот написал и предположу, что помимо шины по-любому нужно хранить таски ещё и в бд с состояниями/статусами по всем пройденным микросервисам. Либо всё-таки мутить псевдотранзакционность с откатами и следить, чтобы ошибка по задаче не повторялась более N раз. Но реальные кейсы с решениями хотелось бы узнать.
1. У вас будет копиться очередь событий. Часто применяют retry policy и dead letter queue: если возникли ошибки при обработке (недоступна бд, как пример), то в соответствии с политикой ретраев он может попытаться еще несколько раз обработать и если не вышло, то перенаправить в dead letter queue для последующего разбора инцидента и работ по компенсации последствий 2. Вам придется в любом случае следить за гарантиями отправки событий в брокер и гарантиями идемпотентности обработки этих событий. 3. В своем предположении вы описываете сагу в виде command orchestration (еще ее называют менеджер процесса и распределенная транзакция). Если вы разделили ответственности сервисов так, что вам необходим оркестратор для какого-то процесса, то это противоречит практикам микросервисного подхода (smart endpoints and dumb pipes) и вы изобретаете ESB.
как это нет трансакций? а distributed transactions это что? например Кафка или МонгоДБ поддерживают трансакции, хотя могут быть на разных нодах данные. Так что, возможно, но сложно
Ээээм, чувак несёт чушь в вопросе rabbit-а и асинхроники. Описанная им схема в такой форме вообще нихрена не гарантирует. И нужен комплект контроля над рэббитом и сервисами. И да, рэббит гарантирует доставку только если не упал, это первое, а второе, то, что рэббит доставил сообщение - не гарантирует, что оно будет обработано. так что никакой гарантии здесь нет от слова совсем
Вероятно речь о JMS клиенте для ребит, и там вполне себе отлично настраивается акк только после успешного процессинга месседжа, ну тоесть констюи и процессинг происходит в единой транзакции и если вы получаете рантайм експешн, то этого успешного акка просто не будет. Таким образом месседж останется в брокере, в той же кьюхе или в длкью уже не столь важно. Важно, что вы не потеряли данные.
Доклад - прекрасный (хотя и очень поверхностный) сборник антипаттернов реализации микросервисной (вернее - просто распределенной) архитектуры. Какой пункт не возьми - всюду используется или неоптимальное решение или просто неверное утверждение, в лучшем случае - собственные костыли Грустно (
@@maximmaximych тоже такие комментарии забавляют - ой, у вас тут все очень плохо, а как хорошо ни за что не расскажу, секрет. :)))) Ничего он вам поконкретней не расскажет, потому что не знает, а высказаться хочется ) Опыта столько еще ни у кого не накоплено, разве что у гигантов вроде нетфликса, но что-то я сомневаюсь, что мистер Phillip Delgyado оттуда к нам пришел смотреть этот доклад.
очередной раз только убеждаюсь что микросервисы это новомодный бред. говорит о том что они убирают геморой, а потом сразу вываливает весь другой геморой этого микротанца с бубном...
Так никто и не говорит, что микросервисы решают все проблемы и все упрощают. Наоборот, все говорят, что станет сложнее, намного сложнее. Никакой адекватный человек, в том числе здесь в видео, не советует писать на них сразу все и вся. Хуже будет. Как всегда, все упирается в компромиссы. Микросервисы со своей сложностью решают другие проблемы, которые могут перевесить в общем итоге. Такое ощущение, что даже видео не смотрели и ничего про микросервисы не читали, кроме комментов на хабре. В интернете полно адекватных видео от нетфликса, убер и кучи других, где все это есть на огромных нагрузках. Там и говорят, зачем оно им и почему оно стоит дополнительной головной боли.
Вот че реально херня это их брокер сообщений на ровном месте. Они его добавили, все хорошо, но все равно осталась страховка в виде флажка, чтобы данные не ушли куда-то и надо попробовать еще раз. С тем же успехом и без лишней подсистемы это можно сделать без брокера прямыми запросами между сервисами. Не дошло - поставил флажок, оставил до лучших времен. В этом месте реально попахивает микросервисами головного мозга.
@@creker1 Брокер нужен, например, чтобы можно в n микросервисов раскидать запросы и чтобы не велосипедить очередь на самом микросервисе (который может упасть вместе с очередью). Каждому микросервису не нужно знать кому именно и куда кидать сообщения, нужен только адрес брокера.
Ключевое, перескажу: это модно, поэтому, чтобы привлечь новых, молодых, модных же разрабов, надо быть в модном тренде. Дичь, но, видимо, это и есть круговорот жизни.
Отлично рассказано. Почерпнул для себя много полезного. Приятно, что спикер говорил и об ошибках проектирования, которые были в его команде
Согласен. Уважаю людей способных признать свои ошибки. Ненавижу руководителей не способных это сделать - бегите от них, такие ничего хорошего с проектом не сделают и вам не дадут.
Еще и говорит ровно.
Кайф для ушей.
Жаль нельзя поставить несколько лайков! Один из лучших докладов!
Огромное спасибо! Очень крутая тема, очень хорошо рассказано! Сами так делаем. Делаешь например расчетчик в виде микросервиса и пожалуйста, возникли проблемы с нагрузкой разворачивай хоть на 10 сереров, хоть на 100 персоналок. Часть упала, пофиг досчитается на остальных. Просто устанавливаешь сервис на машину и настраиваешь в конфиге параметры очереди! Понравилось также, что сказал, что не надо делать DAL сервис, т.к. бесит на самом деле гонять данные через него, особоенно большие. Успехов!
А потом приходит настоящий программист, смотрит на код вашего расчетчика, говорит "что за дебилы, не учившиеся высшей математике и даже не читавшие Кнута, писали" (а большинство пейсателей микросервисов - они после юридического и курсов верстки html в профессии, к сожалению) и за 2 часа реализует новый "расчетчик", который всё нужное считает на 4 порядка быстрее и факт уменьшения расходов на процессорные мощности на амазоне на те же 4 порядка вынуждает руководителя проекта уволить нахер половину мамкиных пейсателей микросервисов, потому что скрыть это перед заказчиком уже невозможно, а значит невозможно обосновывать зубодробительный бюджет внедрения, под который и набрали мамкиных пейсателей микросервисов. История из жизни, к сожалению. А чё? Похер же на отдельные сервисы и качество их работы- пущай падают и тормозят - пара кликов и амазон сам нагенерит кучу копий серверов, а ещё пара кликов - и кубернетис сам всё свяжет и настроит...
Видимо парням очень хотелось получить опыт, нужный в реальном хайлоаде и они под 200rps, с которым справиться любой монолит, запилили модную архитектуру
Для сравнения у ВКонтакте пару лет назад было 3 млн запросов в секунду, сейчас должно быть больше.
@@constantinegeist1854 и что? это вообще не имеет никакой связи с выбором архитектуры - монолит или микросервисы
с чего вы взяли что там 200rps?
@@waagnermann в начале видео сказано.
Очень крутой cook book получился, узнал для себя новые моменты, буду использовать в работе. Но соглашусь с другим комментатором, на 200 rps это все не нужно)) Как стрелять из пушки по воробьям
Очень хороший доклад
классная презентация! очень доходчиво
Очень доходчиво рассказывает
Интересный доклад. Респект!
Не понимаю зачем нужно дублировать реализации в разных микросервисах ) 6:00
ok - тут пояснения 28:50
автор молодец, очень доходчиво и из реальных кейсов
Очень просто и доходчиво обьясняешь-респект)
Спасибо! отличное видео. немало узнал идей которые уже делали
Отличный доклад! Спасибо!
16:26 Я думаю, вы не правильно сделали, создав API, которое напрямую связано с сервисами. Я тоже для себя разрабатываю такую систему. Пока она на уровне архитектуры, но в этом плане моя идея с вами расходится. Хотя всё остальное - то же самое. И как думаю я: нужно, чтобы API-морда была соединена с брокером сообщений, а не с сервисами напрямую. Во-первых, это делает их по-настоящему независимыми и изолированными, а во-вторых, брокер становится центром, который связывает друг с другом все части системы. К тому же он может хранить сообщения от API, которые ещё не обработаны и сохранять их на случай сбоя. В вашем же варианте API дёргает каждый модуль, когда ему вздумается, что может этот модуль подвесить, да и плюс это не безопасно. Прямых связей между модулями нужно избегать. Единственная прямая связь, которая должна быть у модуля - это связь с брокером, причём брокер должен работать по запросу - в стиле Kafka, чтобы, опять же, не дёргать модуль, когда тот занят (как это делает RabbitMQ). А API - это тоже, по сути, модуль. А у вас получается, что ваши модули связаны не только с брокером, но и с API. Это лишняя зависимость. Достаточно только брокера. Это и проще контролировать и логичнее выглядит.
Брокер для асинхронного взаимодействия. Для синхронного http || grpc
Уже раз пятый смотрю )), супер интересно
Любую бизнес-систему можно разделить на данные, логику в виде разрабатываемого ПО и среду. Задача хайлоуд - быстро развернуть и масштабировать ПО и среду, чтобы клиент мог работать с данными
Шикарно, спасибо!
а в чем проблема в рамках монолитной архитектуры разбить приложение на модули/компоненты которыми будут заниматься отдельные команды?
почему в рамках монолита мы не можем переиспользовать какие-то куски? что за чушь вообще? это емнип называется компоненто-ориентированная архитектура и точно так же как вы можете использовать хибернейт в разных приложениях что вам мешает так же использовать свой собственный ОРМ или расширение того же хибернейта?
Не стоит писать про чушь, если вы чего-то не поняли.
Представьте себе, что у вас в рамках монолита одна часть приложения требует больше нагрузки, другая меньше, третья - средне. В рамках монолита для масштабирования вам придётся разворачивать ВЕСЬ монолит целиком и выделять памяти кратно больше на ВСЁ приложение, хотя вам столько не нужно, а нужномастшабировать только его часть. После разбиения вы можете запустить 10 контейнеров для одной части, 2 для другой и 1 для третьей, наименее нагруженной. Если нагрузка на третью часть в какой-то момент вырастает - добавляете ещё один контейнер, и это НИКАК не влияет на остальные сервисы.
Пример из доклада - "платежи" и "история платежей" - вроде бы одна сущность, платёж, и данные должны храниться вместе. Но по факту - совершение платежей происходит намного чаще, чем запрос истории, то есть платежи совершённые сегодня - важнее и чаще запрашиваются чем, те, что были совершены неделю, месяц и тем более - год назад. Поэтому есть смысл разделить эти две сущности на разные сервисы.
про зависимость внешних партнёров от супер старых версий не раскрыт до конца. не в сторону GraphQL ли там клонили...
мы изобрели пару лет назад велосипед и у нас почти получилось)
Спасибо, многое разъяснили в голове)
Почему никто не говорит, что микросервисная архетектура работает медленнее чем монолит ??
это не правда. если разделить на правильные ограниченные контексты, которые не имеют зацеплений, тогда не будет никакого вообще замедления. например есть огромная база продукции, нам поставили задачу сделать витрину каких-то особенных продуктов с дикими фильтрами. завели микросервис, в него загрузили продукты из шины, побили при помощи СQRS на модель записи (то что летит из монолита), модель чтения - индексы в эластике под всякие влажные фантазии бизнеса. основная нагрузка это эластик - его на отдельные виртуалки. мало? кластер. можно не эластик. касандру например. и вот монолит живет себе как и жил. никто в его репе не пишет дикий код про работу с эластиком. а отдельная команда работает в отдельной репе, выпускает отдельные релизы. это офигеть как упрощает разработку. а значит - приносит деньги. и где здесь может работать медленнее? ну а если конечно прилетает запрос на микросервис, а он лезет за данными в другие три при помощи http - тогда, да. будет полная Ж. про это докладчик тоже рассказывал.
Очень полезное видео! Спасибо!
На самом деле там не пустые прямоугольники, текст в них виден только просвященным
просто цензура. это тяжело давшиеся сервисы.
46:04 Как как вас зовут? Голодный?
Благодарю за доклад!
Для справки, JMS - это не протокол, а API. И указывать её на слайде на 13:20 не стоило - это грубая ошибка. Тот же AMQP доступен в Java через JMS.
Вот за что я не люблю хайлоад.
Вышел красавчик рассказал какие они хорошие. Позовите ихнованных опсов они расскажут всю правду.
Супер, очень много полезного
Это Вы на несчастных 200RPS определили что микросервисы подходят для высоких нагрузок?
В чём проблема горизонтально масштабировать монолит? Каким образом микросервисы вообще решают проблему горизонтального масштабирования?
В монолите плохая отказоустойчивость, а в микросервисах, где одни точки отказа, отличная?
микросервисы в нормальной реализации дадут вам изоляцию и graceful degradation так сказать. Может отвалиться конкретный сервис и приложение продолжит работать с частичной потерей функциональности. Как вот любят амазон приводить в пример. У них может отвалиться вообще вся система заказов, но главное, чтобы можно было класть в корзину, а там как-нить потом разрулят. Главное не пугать людей ошибками. Монолит если упадет, то упадет весь и пиши пропало.
Проблема масштабировать монолит в том, что часто он пишется так, что это невозможно сделать. Огромный кусок кода, который ничего вокруг себя не видит и считает себя центром вселенной. Микросервисы сами по себе это не решают, но как подход он заставляет/поощрает/так принято писать так, что они потом легко масштабируются. Они изначально пишутся обычно так, чтобы быть готовыми, что вокруг них еще куча подвижных частей и надо как можно меньше состояния держать в себе.
Везде свои нюансы конечно и микросервисы приносят много головной боли на девопсов, но они имеют свои преимущества, которые нужно просто понимать, а не кидаться на хайп или хейт. Как обычно, новомодную хрень либо хейтят, либо хайпят бездумно.
Монолит в нормальной реализации даст вам изоляцию и graceful degradation так сказать.
@@ErrorsMissing каким образом? База у вас легла, память кончилась, сборщик мусора повесил систему, коннекты до базы переполнились и еще миллион всяких ситуация, не говоря о багах своих собственных. Где у вас тут будет все это? Упадет все и сразу. Если у вас монолит может в нескольких экземплярах подниматься, то хоть как-то спасет, но это редко. Обычно один бэкэнд на всю систему. Чтобы монолит писать таким образом, это надо охренеть как подумать. А традиционно, а тем более в легаси системах, принцип простой - работает или все, или ничего. Если один какой-то метод кинул исключение, то нахер вся транзакция отваливается и юзеру выплевывается ошибка.
>> База у вас легла
А Вы считаете что если используете микросервисы, то база уже не нужна?
>> память кончилась, сборщик мусора повесил систему
Это же касается и микросервисов. Разница лишь в том, что пока один инстанс микросервиса держит нагрузку, то решение таких проблем через резервирование, иначе как и в монолите - балансировка.
Далее по тексту - полнейший бред. Подходы с отработкой исключений и тд одинаковый. Разделять на контексты Вам никто не запрещает. Инкапсуляцию никто не отменял. Про то что в монолите всё и сразу упадёт вообще идиотизм - Вы или обрабатываете всевозможные кейсы и тогда по возможности только часть системы не работает, или игнорируете данные правила и тогда всё лежит, И тут нет разницы монолит это или миллионы сервисов.
>> А Вы считаете что если используете микросервисы, то база уже не нужна?
Я считаю, что вы ни видео не смотрели, ни про тему ничего не читали. Традиционно у каждого сервиса своя база. Упадет база одного сервиса - упадет этот один сервис.
>> Это же касается и микросервисов.
Да, только в их случае это коснется конкретных сервисов.
>> И тут нет разницы монолит это или миллионы сервисов.
Повторим еще раз. Это коснется одного конкретного сервиса, который от этого пострадал. Падение всей системы от одного неудачного null reference exception это, к сожалению, далеко не бред. И в случае монолита он грохнется весь и сразу. Если у вас монолит умеет работать в нескольких экземплярах и балансировать нагрузку, то вы уже заранее не в тех условиях, о которых обычно речь. В этом случае вам может достаточно распилить код на часть и у вас уже микросервисы, т.к. все написано правильно. Просто они прикидываются монолитом.
В общем, идите туториалы читайте. Как и писал, либо бездумный хейт, либо хайп. Разберитесь в сути темы для начала.
4:30
Пацаны похоже вообще не слышали ничего про third party либы)))
Спасибо!
Спасибо большое!
Есть определение микросервисов? Что это такое? Почему нельзя говорит подпроект?
Вау! Браво!
Не совсем понятно почему монолиит сложно горизонтально масштабировать. И почему нельзя переисаользоват код, пишешь как пакет и все.
Монолит сложно масштабировать, если требуется масштабировать конкретный функционал,например отправку sms, в случае с микросервисами можно поднять доп контейнеры отправляющие sms, а с монолитом пришлось бы вообще все приложение поднимать. А с кодом проблема в том, что микросервисы оч часто и быстро меняются и если написать библиотеку для трех микросервисов, то теперь эти микросервисы сильно зависят от этой бибилитеки и их сложно менять
Классный доклад
Что? В монолите код невозможно использовать повторно??? Хайлоад начинается от 200 оп.сек? Про остальное вообще молчу. Монолит вам нужен только для того, чтобы поддерживать СВОЙ стек в актуальном состоянии!
А можно ли на го писать не микросервисы, а там например простой блог?
На го можно все))
Можно, только это будет проблемнее, особенно, если захочется иметь хороший встроенный шаблонизатор, а не отдельный бэк+фронт.
Для простых блогов проще взять PHP-фреймворк (Laravel/Symfony) или вообще CMS а-ля wordpress
@@MetalRex100 на го вообще-то есть шаблонизатор.
@@SpockSynckov можете попробовать на нем полноценный сайт написать)
круто!
Спасибо
Простите, 200 rps в пике это не мало, это не о чем
Сколько строк кода у Вас в микросервисах, что ">25 микросервисов" это большие система?
Внедряли туда - куда не нужны - все что нужно знать о микросервисах
Ну да, переиспользовать код в монолите вообще не возможно. Это все что нужно знать о современных разработчиках и архитекторах.
возможно, но сложно!
@@brodlovherrsov7097 да вы что? Это чем же сложно? Оформил оператор в отдельный класс и Алга. Дерзай его из любого места. Даже в старую функцию в мейне можно обернуть, если код часто нужен много где. В монолите то как раз проще делать реюз кода, ибо он при добавлении новой функции, использщей куски других функций тебе гораздо меньше надо сношаться по теме импорта и зависимостей кода.
@@zerocool4eg я работал на зарубежные банки
Net Fret вы там в зарубежных банках головой в хранилище железное бьетесь на кастинге? У вас любой исходник на любом языке начинается со слов import или include, или use. Это и есть переиспользовние кода и его изобрели полвека назад, даже побольше.
Егор не палите, давайте вдвоем знать секрет
а мне интересно, когда у вас 100500 запросов в секунду и один из сервисов не ацкает задачу из-за повторяющейся ошибки... Что будет с системой, когда память закончится?
Вот написал и предположу, что помимо шины по-любому нужно хранить таски ещё и в бд с состояниями/статусами по всем пройденным микросервисам. Либо всё-таки мутить псевдотранзакционность с откатами и следить, чтобы ошибка по задаче не повторялась более N раз.
Но реальные кейсы с решениями хотелось бы узнать.
1. У вас будет копиться очередь событий. Часто применяют retry policy и dead letter queue: если возникли ошибки при обработке (недоступна бд, как пример), то в соответствии с политикой ретраев он может попытаться еще несколько раз обработать и если не вышло, то перенаправить в dead letter queue для последующего разбора инцидента и работ по компенсации последствий
2. Вам придется в любом случае следить за гарантиями отправки событий в брокер и гарантиями идемпотентности обработки этих событий.
3. В своем предположении вы описываете сагу в виде command orchestration (еще ее называют менеджер процесса и распределенная транзакция). Если вы разделили ответственности сервисов так, что вам необходим оркестратор для какого-то процесса, то это противоречит практикам микросервисного подхода (smart endpoints and dumb pipes) и вы изобретаете ESB.
круто
Молодцы ребята, наняли Маслякова ведущим
9:40 такой распил грозит большими проблемами со связностью в будущем.
подскажите новичку, плиз. А как надо распилить правильно?
как это нет трансакций? а distributed transactions это что? например Кафка или МонгоДБ поддерживают трансакции, хотя могут быть на разных нодах данные.
Так что, возможно, но сложно
с упавшим брокером и БД какой-то вообще лютый велосипед
@@alexanderbikk8055 спасибо
резанули ухо слова, а шина гарантирует доставку до получателя :)))
Так а Ack на что?
базу про transactional outbox рассказал тупо)
Комитить в один репозиторий не сложно.
иногда даже полезно
Ээээм, чувак несёт чушь в вопросе rabbit-а и асинхроники.
Описанная им схема в такой форме вообще нихрена не гарантирует.
И нужен комплект контроля над рэббитом и сервисами.
И да, рэббит гарантирует доставку только если не упал, это первое, а второе, то, что рэббит доставил сообщение - не гарантирует, что оно будет обработано.
так что никакой гарантии здесь нет от слова совсем
Вероятно речь о JMS клиенте для ребит, и там вполне себе отлично настраивается акк только после успешного процессинга месседжа, ну тоесть констюи и процессинг происходит в единой транзакции и если вы получаете рантайм експешн, то этого успешного акка просто не будет. Таким образом месседж останется в брокере, в той же кьюхе или в длкью уже не столь важно. Важно, что вы не потеряли данные.
распределенность ради распределенности, микросервисы ради микросервисов, сплошная антиреклама микросервисов.
Идиотский подход. Плагины уже отменили?
Доклад - прекрасный (хотя и очень поверхностный) сборник антипаттернов реализации микросервисной (вернее - просто распределенной) архитектуры.
Какой пункт не возьми - всюду используется или неоптимальное решение или просто неверное утверждение, в лучшем случае - собственные костыли
Грустно (
А можно поконкретней?
@@maximmaximych тоже такие комментарии забавляют - ой, у вас тут все очень плохо, а как хорошо ни за что не расскажу, секрет. :)))) Ничего он вам поконкретней не расскажет, потому что не знает, а высказаться хочется ) Опыта столько еще ни у кого не накоплено, разве что у гигантов вроде нетфликса, но что-то я сомневаюсь, что мистер Phillip Delgyado оттуда к нам пришел смотреть этот доклад.
очередной раз только убеждаюсь что микросервисы это новомодный бред. говорит о том что они убирают геморой, а потом сразу вываливает весь другой геморой этого микротанца с бубном...
Все просто зависит от потребностей вашего бизнеса. Не стоит пихать микросервисы везде, да и вы вполне можете реализовывать просто SOA.
Так никто и не говорит, что микросервисы решают все проблемы и все упрощают. Наоборот, все говорят, что станет сложнее, намного сложнее. Никакой адекватный человек, в том числе здесь в видео, не советует писать на них сразу все и вся. Хуже будет. Как всегда, все упирается в компромиссы. Микросервисы со своей сложностью решают другие проблемы, которые могут перевесить в общем итоге. Такое ощущение, что даже видео не смотрели и ничего про микросервисы не читали, кроме комментов на хабре. В интернете полно адекватных видео от нетфликса, убер и кучи других, где все это есть на огромных нагрузках. Там и говорят, зачем оно им и почему оно стоит дополнительной головной боли.
Вот че реально херня это их брокер сообщений на ровном месте. Они его добавили, все хорошо, но все равно осталась страховка в виде флажка, чтобы данные не ушли куда-то и надо попробовать еще раз. С тем же успехом и без лишней подсистемы это можно сделать без брокера прямыми запросами между сервисами. Не дошло - поставил флажок, оставил до лучших времен. В этом месте реально попахивает микросервисами головного мозга.
@@creker1 Брокер нужен, например, чтобы можно в n микросервисов раскидать запросы и чтобы не велосипедить очередь на самом микросервисе (который может упасть вместе с очередью). Каждому микросервису не нужно знать кому именно и куда кидать сообщения, нужен только адрес брокера.
Ключевое, перескажу: это модно, поэтому, чтобы привлечь новых, молодых, модных же разрабов, надо быть в модном тренде. Дичь, но, видимо, это и есть круговорот жизни.
Слабый и несфокусированный доклад
"Это не серебряная пуля..." )))) Вообще-то есть нормальные аналоги на русском: не панацея, не волшебная палочка, не магическое средство...
если доклад нацелен в том числе и на людей, читавших Ф. Брукса, то уместно все же сказать «серебряная пуля»
Душнила. Путина любишь наверное?