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

@Rogov_Oleg

3 жыл бұрын

Согласен. Уважаю людей способных признать свои ошибки. Ненавижу руководителей не способных это сделать - бегите от них, такие ничего хорошего с проектом не сделают и вам не дадут.

@sergeymurashov4365

5 ай бұрын

Еще и говорит ровно. Кайф для ушей.

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

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

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

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

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

@sergoordgonikidze6456

2 жыл бұрын

А потом приходит настоящий программист, смотрит на код вашего расчетчика, говорит "что за дебилы, не учившиеся высшей математике и даже не читавшие Кнута, писали" (а большинство пейсателей микросервисов - они после юридического и курсов верстки html в профессии, к сожалению) и за 2 часа реализует новый "расчетчик", который всё нужное считает на 4 порядка быстрее и факт уменьшения расходов на процессорные мощности на амазоне на те же 4 порядка вынуждает руководителя проекта уволить нахер половину мамкиных пейсателей микросервисов, потому что скрыть это перед заказчиком уже невозможно, а значит невозможно обосновывать зубодробительный бюджет внедрения, под который и набрали мамкиных пейсателей микросервисов. История из жизни, к сожалению. А чё? Похер же на отдельные сервисы и качество их работы- пущай падают и тормозят - пара кликов и амазон сам нагенерит кучу копий серверов, а ещё пара кликов - и кубернетис сам всё свяжет и настроит...

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

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

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

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

@constantinegeist1854

10 ай бұрын

Для сравнения у ВКонтакте пару лет назад было 3 млн запросов в секунду, сейчас должно быть больше.

@bluesdemon1

4 ай бұрын

@@constantinegeist1854 и что? это вообще не имеет никакой связи с выбором архитектуры - монолит или микросервисы

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

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

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

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

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

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

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

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

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

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

Вау! Браво!

круто!

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

Спасибо

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

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

@Grizlek

3 жыл бұрын

просто цензура. это тяжело давшиеся сервисы.

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

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

@odys-wise

Жыл бұрын

это не правда. если разделить на правильные ограниченные контексты, которые не имеют зацеплений, тогда не будет никакого вообще замедления. например есть огромная база продукции, нам поставили задачу сделать витрину каких-то особенных продуктов с дикими фильтрами. завели микросервис, в него загрузили продукты из шины, побили при помощи СQRS на модель записи (то что летит из монолита), модель чтения - индексы в эластике под всякие влажные фантазии бизнеса. основная нагрузка это эластик - его на отдельные виртуалки. мало? кластер. можно не эластик. касандру например. и вот монолит живет себе как и жил. никто в его репе не пишет дикий код про работу с эластиком. а отдельная команда работает в отдельной репе, выпускает отдельные релизы. это офигеть как упрощает разработку. а значит - приносит деньги. и где здесь может работать медленнее? ну а если конечно прилетает запрос на микросервис, а он лезет за данными в другие три при помощи http - тогда, да. будет полная Ж. про это докладчик тоже рассказывал.

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

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

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

круто

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

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

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

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

@roman.chudov

9 ай бұрын

Брокер для асинхронного взаимодействия. Для синхронного http || grpc

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

@user-bn8eb7um1g

2 жыл бұрын

На го можно все))

@MetalRex100

6 ай бұрын

Можно, только это будет проблемнее, особенно, если захочется иметь хороший встроенный шаблонизатор, а не отдельный бэк+фронт. Для простых блогов проще взять PHP-фреймворк (Laravel/Symfony) или вообще CMS а-ля wordpress

@user-fg6jw1cy5v

4 ай бұрын

@@MetalRex100 на го вообще-то есть шаблонизатор.

@MetalRex100

4 ай бұрын

@@user-fg6jw1cy5v можете попробовать на нем полноценный сайт написать)

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

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

@sevaelunin

2 жыл бұрын

1. У вас будет копиться очередь событий. Часто применяют retry policy и dead letter queue: если возникли ошибки при обработке (недоступна бд, как пример), то в соответствии с политикой ретраев он может попытаться еще несколько раз обработать и если не вышло, то перенаправить в dead letter queue для последующего разбора инцидента и работ по компенсации последствий 2. Вам придется в любом случае следить за гарантиями отправки событий в брокер и гарантиями идемпотентности обработки этих событий. 3. В своем предположении вы описываете сагу в виде command orchestration (еще ее называют менеджер процесса и распределенная транзакция). Если вы разделили ответственности сервисов так, что вам необходим оркестратор для какого-то процесса, то это противоречит практикам микросервисного подхода (smart endpoints and dumb pipes) и вы изобретаете ESB.

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

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

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

@creker1

5 жыл бұрын

микросервисы в нормальной реализации дадут вам изоляцию и graceful degradation так сказать. Может отвалиться конкретный сервис и приложение продолжит работать с частичной потерей функциональности. Как вот любят амазон приводить в пример. У них может отвалиться вообще вся система заказов, но главное, чтобы можно было класть в корзину, а там как-нить потом разрулят. Главное не пугать людей ошибками. Монолит если упадет, то упадет весь и пиши пропало. Проблема масштабировать монолит в том, что часто он пишется так, что это невозможно сделать. Огромный кусок кода, который ничего вокруг себя не видит и считает себя центром вселенной. Микросервисы сами по себе это не решают, но как подход он заставляет/поощрает/так принято писать так, что они потом легко масштабируются. Они изначально пишутся обычно так, чтобы быть готовыми, что вокруг них еще куча подвижных частей и надо как можно меньше состояния держать в себе. Везде свои нюансы конечно и микросервисы приносят много головной боли на девопсов, но они имеют свои преимущества, которые нужно просто понимать, а не кидаться на хайп или хейт. Как обычно, новомодную хрень либо хейтят, либо хайпят бездумно.

@ErrorsMissing

5 жыл бұрын

Монолит в нормальной реализации даст вам изоляцию и graceful degradation так сказать.

@creker1

5 жыл бұрын

@@ErrorsMissing каким образом? База у вас легла, память кончилась, сборщик мусора повесил систему, коннекты до базы переполнились и еще миллион всяких ситуация, не говоря о багах своих собственных. Где у вас тут будет все это? Упадет все и сразу. Если у вас монолит может в нескольких экземплярах подниматься, то хоть как-то спасет, но это редко. Обычно один бэкэнд на всю систему. Чтобы монолит писать таким образом, это надо охренеть как подумать. А традиционно, а тем более в легаси системах, принцип простой - работает или все, или ничего. Если один какой-то метод кинул исключение, то нахер вся транзакция отваливается и юзеру выплевывается ошибка.

@ErrorsMissing

5 жыл бұрын

>> База у вас легла А Вы считаете что если используете микросервисы, то база уже не нужна? >> память кончилась, сборщик мусора повесил систему Это же касается и микросервисов. Разница лишь в том, что пока один инстанс микросервиса держит нагрузку, то решение таких проблем через резервирование, иначе как и в монолите - балансировка. Далее по тексту - полнейший бред. Подходы с отработкой исключений и тд одинаковый. Разделять на контексты Вам никто не запрещает. Инкапсуляцию никто не отменял. Про то что в монолите всё и сразу упадёт вообще идиотизм - Вы или обрабатываете всевозможные кейсы и тогда по возможности только часть системы не работает, или игнорируете данные правила и тогда всё лежит, И тут нет разницы монолит это или миллионы сервисов.

@creker1

5 жыл бұрын

>> А Вы считаете что если используете микросервисы, то база уже не нужна? Я считаю, что вы ни видео не смотрели, ни про тему ничего не читали. Традиционно у каждого сервиса своя база. Упадет база одного сервиса - упадет этот один сервис. >> Это же касается и микросервисов. Да, только в их случае это коснется конкретных сервисов. >> И тут нет разницы монолит это или миллионы сервисов. Повторим еще раз. Это коснется одного конкретного сервиса, который от этого пострадал. Падение всей системы от одного неудачного null reference exception это, к сожалению, далеко не бред. И в случае монолита он грохнется весь и сразу. Если у вас монолит умеет работать в нескольких экземплярах и балансировать нагрузку, то вы уже заранее не в тех условиях, о которых обычно речь. В этом случае вам может достаточно распилить код на часть и у вас уже микросервисы, т.к. все написано правильно. Просто они прикидываются монолитом. В общем, идите туториалы читайте. Как и писал, либо бездумный хейт, либо хайп. Разберитесь в сути темы для начала.

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

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

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

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

@SuperBizon012

3 жыл бұрын

@@alexanderbikk8055 спасибо

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

@angry-qa

4 жыл бұрын

Так а Ack на что?

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

@brodlovherrsov7097

4 жыл бұрын

возможно, но сложно!

@zerocool4eg

4 жыл бұрын

@@brodlovherrsov7097 да вы что? Это чем же сложно? Оформил оператор в отдельный класс и Алга. Дерзай его из любого места. Даже в старую функцию в мейне можно обернуть, если код часто нужен много где. В монолите то как раз проще делать реюз кода, ибо он при добавлении новой функции, использщей куски других функций тебе гораздо меньше надо сношаться по теме импорта и зависимостей кода.

@brodlovherrsov7097

4 жыл бұрын

@@zerocool4eg я работал на зарубежные банки

@xbevice

4 жыл бұрын

Net Fret вы там в зарубежных банках головой в хранилище железное бьетесь на кастинге? У вас любой исходник на любом языке начинается со слов import или include, или use. Это и есть переиспользовние кода и его изобрели полвека назад, даже побольше.

@xbevice

4 жыл бұрын

Егор не палите, давайте вдвоем знать секрет

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

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

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

@Rustamushko

Жыл бұрын

иногда даже полезно

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

@dmitriysarzhan2655

4 жыл бұрын

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

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

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

@maximmaximych

4 жыл бұрын

А можно поконкретней?

@dmitriypronichev7048

3 жыл бұрын

@@maximmaximych тоже такие комментарии забавляют - ой, у вас тут все очень плохо, а как хорошо ни за что не расскажу, секрет. :)))) Ничего он вам поконкретней не расскажет, потому что не знает, а высказаться хочется ) Опыта столько еще ни у кого не накоплено, разве что у гигантов вроде нетфликса, но что-то я сомневаюсь, что мистер Phillip Delgyado оттуда к нам пришел смотреть этот доклад.

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

@deffy18

4 жыл бұрын

подскажите новичку, плиз. А как надо распилить правильно?

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

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

@vasiukovvladimir8391

5 жыл бұрын

Все просто зависит от потребностей вашего бизнеса. Не стоит пихать микросервисы везде, да и вы вполне можете реализовывать просто SOA.

@creker1

5 жыл бұрын

Так никто и не говорит, что микросервисы решают все проблемы и все упрощают. Наоборот, все говорят, что станет сложнее, намного сложнее. Никакой адекватный человек, в том числе здесь в видео, не советует писать на них сразу все и вся. Хуже будет. Как всегда, все упирается в компромиссы. Микросервисы со своей сложностью решают другие проблемы, которые могут перевесить в общем итоге. Такое ощущение, что даже видео не смотрели и ничего про микросервисы не читали, кроме комментов на хабре. В интернете полно адекватных видео от нетфликса, убер и кучи других, где все это есть на огромных нагрузках. Там и говорят, зачем оно им и почему оно стоит дополнительной головной боли.

@creker1

5 жыл бұрын

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

@crutchmaster9637

5 жыл бұрын

@@creker1 Брокер нужен, например, чтобы можно в n микросервисов раскидать запросы и чтобы не велосипедить очередь на самом микросервисе (который может упасть вместе с очередью). Каждому микросервису не нужно знать кому именно и куда кидать сообщения, нужен только адрес брокера.

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

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

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

@dipyalov

3 жыл бұрын

если доклад нацелен в том числе и на людей, читавших Ф. Брукса, то уместно все же сказать «серебряная пуля»

@johnd.3293

2 жыл бұрын

Душнила. Путина любишь наверное?