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

Приглашаем на конференцию Saint HighLoad++ 2024, которая пройдет 24 и 25 июня в Санкт-Петербурге!
Программа, подробности и билеты по ссылке: vk.cc/cuyIqx
--------
--------
Backend Conf, РИТ++ 2018
Тезисы и презентация:
backendconf.ru/2018/abstracts/...
Последние годы все чаще говорят о микросервисной архитектуре приложений. Давайте разберемся, почему она так популярна, какие основные плюсы и минусы мы получаем. А самое главное, разберемся, как спроектировать микросервисную архитектуру, а не "монолит, распределенный по сети" и какие технологии нам в этом помогут.
….
--------
Нашли ошибку в видео? Пишите нам на [e-mail]

[@rtcw1984]

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

[@Rogov_Oleg]

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

[@sergeymurashov4365]

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

[@theantferdy]

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

[@aikolkoikelov7514]

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

[@user-cw7ed5rf4e]

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

[@devtaubayev]

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

[@rashrash1178]

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

[@azazello505]

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

[@alexricher2554]

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

[@xandra3218]

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

[@ruslansitdikov1489]

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

[@asqarfarhadi3789]

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

[@PostMapping]

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

[@ainurbektemirova2158]

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

[@daniilevsienko4060]

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

[@andreyyagovkin3945]

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

[@sergoordgonikidze6456]

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

[@AlexeySivak]

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

[@user-qx3km6wp1p]

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

[@constantinegeist1854]

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

[@bluesdemon1]

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

[@whereispie]

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

[@ev_geniy17]

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

[@Andrzej3935]

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

[@user-wj3rv9gj2v]

Вау! Браво!

[@nikenuke]

круто!

[@monoteis]

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

[@FaizUndead]

Спасибо

[@tomozi1]

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

[@vladimirpovyshev166]

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

[@alexeykononov5596]

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

[@ilyadakuchayeu784]

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

[@dieff_automation]

круто

[@vifvrTtb0vmFtbyrM_Q]

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

[@Grizlek]

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

[@codememory]

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

[@odys-wise]

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

[@MikhailKa40]

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

[@ssssss799]

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

[@ErrorsMissing]

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

[@ognivo777]

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

[@tsunami1100]

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

[@user-yz9uw3pd5t]

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

[@user-bn8eb7um1g]

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

[@MetalRex100]

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

[@user-fg6jw1cy5v]

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

[@MetalRex100]

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

[@lemeshenko]

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

[@-dubok-]

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

[@roman.chudov]

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

[@TeppopucT]

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

[@sevaelunin]

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

[@andreybazhenov9741]

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

[@user-botogame]

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

[@vladimirpopov6841]

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

[@ErrorsMissing]

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

[@creker1]

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

[@ErrorsMissing]

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

[@creker1]

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

[@ErrorsMissing]

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

[@creker1]

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

[@andreyrudin2286]

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

[@angry-qa]

Так а Ack на что?

[@SuperBizon012]

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

[@SuperBizon012]

@@alexanderbikk8055 спасибо

[@axiomadevelopper4665]

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

[@andreymanaenko1638]

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

[@xbevice]

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

[@brodlovherrsov7097]

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

[@zerocool4eg]

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

[@brodlovherrsov7097]

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

[@xbevice]

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

[@xbevice]

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

[@DenisG631]

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

[@sanyaua4074]

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

[@Rustamushko]

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

[@Sergey-tr2pz]

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

[@psialt9720]

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

[@deffy18]

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

[@zerocool4eg]

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

[@dmitriysarzhan2655]

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

[@amz2mov]

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

[@phillipdelgyado9790]

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

[@maximmaximych]

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

[@dmitriypronichev7048]

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

[@openidqd]

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

[@winfle]

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

[@NikK0lay]

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

[@vasiukovvladimir8391]

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

[@creker1]

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

[@creker1]

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

[@crutchmaster9637]

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

[@somarble]

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

[@dipyalov]

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

[@johnd.3293]

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