Микросервисная архитектура, подходы и технологии / Кирилл Ветчинкин (TYME)
Vložit
- čas přidán 19. 11. 2018
- Приглашаем на конференцию Saint HighLoad++ 2024, которая пройдет 24 и 25 июня в Санкт-Петербурге!
Программа, подробности и билеты по ссылке: vk.cc/cuyIqx
--------
--------
Backend Conf, РИТ++ 2018
Тезисы и презентация:
backendconf.ru/2018/abstracts/...
Последние годы все чаще говорят о микросервисной архитектуре приложений. Давайте разберемся, почему она так популярна, какие основные плюсы и минусы мы получаем. А самое главное, разберемся, как спроектировать микросервисную архитектуру, а не "монолит, распределенный по сети" и какие технологии нам в этом помогут.
….
--------
Нашли ошибку в видео? Пишите нам на support@ontico.ru
Отлично рассказано. Почерпнул для себя много полезного. Приятно, что спикер говорил и об ошибках проектирования, которые были в его команде
Согласен. Уважаю людей способных признать свои ошибки. Ненавижу руководителей не способных это сделать - бегите от них, такие ничего хорошего с проектом не сделают и вам не дадут.
Еще и говорит ровно.
Кайф для ушей.
Интересный доклад. Респект!
классная презентация! очень доходчиво
Шикарно, спасибо!
Жаль нельзя поставить несколько лайков! Один из лучших докладов!
автор молодец, очень доходчиво и из реальных кейсов
Очень доходчиво рассказывает
Отличный доклад! Спасибо!
Благодарю за доклад!
Очень просто и доходчиво обьясняешь-респект)
Спасибо, многое разъяснили в голове)
Очень крутой cook book получился, узнал для себя новые моменты, буду использовать в работе. Но соглашусь с другим комментатором, на 200 rps это все не нужно)) Как стрелять из пушки по воробьям
Очень полезное видео! Спасибо!
Очень хороший доклад
Видимо парням очень хотелось получить опыт, нужный в реальном хайлоаде и они под 200rps, с которым справиться любой монолит, запилили модную архитектуру
Для сравнения у ВКонтакте пару лет назад было 3 млн запросов в секунду, сейчас должно быть больше.
@@constantinegeist1854 и что? это вообще не имеет никакой связи с выбором архитектуры - монолит или микросервисы
Спасибо! отличное видео. немало узнал идей которые уже делали
Спасибо большое!
Огромное спасибо! Очень крутая тема, очень хорошо рассказано! Сами так делаем. Делаешь например расчетчик в виде микросервиса и пожалуйста, возникли проблемы с нагрузкой разворачивай хоть на 10 сереров, хоть на 100 персоналок. Часть упала, пофиг досчитается на остальных. Просто устанавливаешь сервис на машину и настраиваешь в конфиге параметры очереди! Понравилось также, что сказал, что не надо делать DAL сервис, т.к. бесит на самом деле гонять данные через него, особоенно большие. Успехов!
А потом приходит настоящий программист, смотрит на код вашего расчетчика, говорит "что за дебилы, не учившиеся высшей математике и даже не читавшие Кнута, писали" (а большинство пейсателей микросервисов - они после юридического и курсов верстки html в профессии, к сожалению) и за 2 часа реализует новый "расчетчик", который всё нужное считает на 4 порядка быстрее и факт уменьшения расходов на процессорные мощности на амазоне на те же 4 порядка вынуждает руководителя проекта уволить нахер половину мамкиных пейсателей микросервисов, потому что скрыть это перед заказчиком уже невозможно, а значит невозможно обосновывать зубодробительный бюджет внедрения, под который и набрали мамкиных пейсателей микросервисов. История из жизни, к сожалению. А чё? Похер же на отдельные сервисы и качество их работы- пущай падают и тормозят - пара кликов и амазон сам нагенерит кучу копий серверов, а ещё пара кликов - и кубернетис сам всё свяжет и настроит...
Уже раз пятый смотрю )), супер интересно
Вау! Браво!
Супер, очень много полезного
круто!
Любую бизнес-систему можно разделить на данные, логику в виде разрабатываемого ПО и среду. Задача хайлоуд - быстро развернуть и масштабировать ПО и среду, чтобы клиент мог работать с данными
Классный доклад
Спасибо
Не понимаю зачем нужно дублировать реализации в разных микросервисах ) 6:00
ok - тут пояснения 28:50
а в чем проблема в рамках монолитной архитектуры разбить приложение на модули/компоненты которыми будут заниматься отдельные команды?
почему в рамках монолита мы не можем переиспользовать какие-то куски? что за чушь вообще? это емнип называется компоненто-ориентированная архитектура и точно так же как вы можете использовать хибернейт в разных приложениях что вам мешает так же использовать свой собственный ОРМ или расширение того же хибернейта?
мы изобрели пару лет назад велосипед и у нас почти получилось)
круто
Вот за что я не люблю хайлоад.
Вышел красавчик рассказал какие они хорошие. Позовите ихнованных опсов они расскажут всю правду.
Не совсем понятно почему монолиит сложно горизонтально масштабировать. И почему нельзя переисаользоват код, пишешь как пакет и все.
На самом деле там не пустые прямоугольники, текст в них виден только просвященным
просто цензура. это тяжело давшиеся сервисы.
Молодцы ребята, наняли Маслякова ведущим
46:04 Как как вас зовут? Голодный?
Почему никто не говорит, что микросервисная архетектура работает медленнее чем монолит ??
это не правда. если разделить на правильные ограниченные контексты, которые не имеют зацеплений, тогда не будет никакого вообще замедления. например есть огромная база продукции, нам поставили задачу сделать витрину каких-то особенных продуктов с дикими фильтрами. завели микросервис, в него загрузили продукты из шины, побили при помощи СQRS на модель записи (то что летит из монолита), модель чтения - индексы в эластике под всякие влажные фантазии бизнеса. основная нагрузка это эластик - его на отдельные виртуалки. мало? кластер. можно не эластик. касандру например. и вот монолит живет себе как и жил. никто в его репе не пишет дикий код про работу с эластиком. а отдельная команда работает в отдельной репе, выпускает отдельные релизы. это офигеть как упрощает разработку. а значит - приносит деньги. и где здесь может работать медленнее? ну а если конечно прилетает запрос на микросервис, а он лезет за данными в другие три при помощи http - тогда, да. будет полная Ж. про это докладчик тоже рассказывал.
Для справки, JMS - это не протокол, а API. И указывать её на слайде на 13:20 не стоило - это грубая ошибка. Тот же AMQP доступен в Java через JMS.
Простите, 200 rps в пике это не мало, это не о чем
Сколько строк кода у Вас в микросервисах, что ">25 микросервисов" это большие система?
16:26 Я думаю, вы не правильно сделали, создав API, которое напрямую связано с сервисами. Я тоже для себя разрабатываю такую систему. Пока она на уровне архитектуры, но в этом плане моя идея с вами расходится. Хотя всё остальное - то же самое. И как думаю я: нужно, чтобы API-морда была соединена с брокером сообщений, а не с сервисами напрямую. Во-первых, это делает их по-настоящему независимыми и изолированными, а во-вторых, брокер становится центром, который связывает друг с другом все части системы. К тому же он может хранить сообщения от API, которые ещё не обработаны и сохранять их на случай сбоя. В вашем же варианте API дёргает каждый модуль, когда ему вздумается, что может этот модуль подвесить, да и плюс это не безопасно. Прямых связей между модулями нужно избегать. Единственная прямая связь, которая должна быть у модуля - это связь с брокером, причём брокер должен работать по запросу - в стиле Kafka, чтобы, опять же, не дёргать модуль, когда тот занят (как это делает RabbitMQ). А API - это тоже, по сути, модуль. А у вас получается, что ваши модули связаны не только с брокером, но и с API. Это лишняя зависимость. Достаточно только брокера. Это и проще контролировать и логичнее выглядит.
Брокер для асинхронного взаимодействия. Для синхронного http || grpc
Что? В монолите код невозможно использовать повторно??? Хайлоад начинается от 200 оп.сек? Про остальное вообще молчу. Монолит вам нужен только для того, чтобы поддерживать СВОЙ стек в актуальном состоянии!
Есть определение микросервисов? Что это такое? Почему нельзя говорит подпроект?
Это Вы на несчастных 200RPS определили что микросервисы подходят для высоких нагрузок?
В чём проблема горизонтально масштабировать монолит? Каким образом микросервисы вообще решают проблему горизонтального масштабирования?
В монолите плохая отказоустойчивость, а в микросервисах, где одни точки отказа, отличная?
микросервисы в нормальной реализации дадут вам изоляцию и graceful degradation так сказать. Может отвалиться конкретный сервис и приложение продолжит работать с частичной потерей функциональности. Как вот любят амазон приводить в пример. У них может отвалиться вообще вся система заказов, но главное, чтобы можно было класть в корзину, а там как-нить потом разрулят. Главное не пугать людей ошибками. Монолит если упадет, то упадет весь и пиши пропало.
Проблема масштабировать монолит в том, что часто он пишется так, что это невозможно сделать. Огромный кусок кода, который ничего вокруг себя не видит и считает себя центром вселенной. Микросервисы сами по себе это не решают, но как подход он заставляет/поощрает/так принято писать так, что они потом легко масштабируются. Они изначально пишутся обычно так, чтобы быть готовыми, что вокруг них еще куча подвижных частей и надо как можно меньше состояния держать в себе.
Везде свои нюансы конечно и микросервисы приносят много головной боли на девопсов, но они имеют свои преимущества, которые нужно просто понимать, а не кидаться на хайп или хейт. Как обычно, новомодную хрень либо хейтят, либо хайпят бездумно.
Монолит в нормальной реализации даст вам изоляцию и graceful degradation так сказать.
@@ErrorsMissing каким образом? База у вас легла, память кончилась, сборщик мусора повесил систему, коннекты до базы переполнились и еще миллион всяких ситуация, не говоря о багах своих собственных. Где у вас тут будет все это? Упадет все и сразу. Если у вас монолит может в нескольких экземплярах подниматься, то хоть как-то спасет, но это редко. Обычно один бэкэнд на всю систему. Чтобы монолит писать таким образом, это надо охренеть как подумать. А традиционно, а тем более в легаси системах, принцип простой - работает или все, или ничего. Если один какой-то метод кинул исключение, то нахер вся транзакция отваливается и юзеру выплевывается ошибка.
>> База у вас легла
А Вы считаете что если используете микросервисы, то база уже не нужна?
>> память кончилась, сборщик мусора повесил систему
Это же касается и микросервисов. Разница лишь в том, что пока один инстанс микросервиса держит нагрузку, то решение таких проблем через резервирование, иначе как и в монолите - балансировка.
Далее по тексту - полнейший бред. Подходы с отработкой исключений и тд одинаковый. Разделять на контексты Вам никто не запрещает. Инкапсуляцию никто не отменял. Про то что в монолите всё и сразу упадёт вообще идиотизм - Вы или обрабатываете всевозможные кейсы и тогда по возможности только часть системы не работает, или игнорируете данные правила и тогда всё лежит, И тут нет разницы монолит это или миллионы сервисов.
>> А Вы считаете что если используете микросервисы, то база уже не нужна?
Я считаю, что вы ни видео не смотрели, ни про тему ничего не читали. Традиционно у каждого сервиса своя база. Упадет база одного сервиса - упадет этот один сервис.
>> Это же касается и микросервисов.
Да, только в их случае это коснется конкретных сервисов.
>> И тут нет разницы монолит это или миллионы сервисов.
Повторим еще раз. Это коснется одного конкретного сервиса, который от этого пострадал. Падение всей системы от одного неудачного null reference exception это, к сожалению, далеко не бред. И в случае монолита он грохнется весь и сразу. Если у вас монолит умеет работать в нескольких экземплярах и балансировать нагрузку, то вы уже заранее не в тех условиях, о которых обычно речь. В этом случае вам может достаточно распилить код на часть и у вас уже микросервисы, т.к. все написано правильно. Просто они прикидываются монолитом.
В общем, идите туториалы читайте. Как и писал, либо бездумный хейт, либо хайп. Разберитесь в сути темы для начала.
А можно ли на го писать не микросервисы, а там например простой блог?
На го можно все))
Можно, только это будет проблемнее, особенно, если захочется иметь хороший встроенный шаблонизатор, а не отдельный бэк+фронт.
Для простых блогов проще взять PHP-фреймворк (Laravel/Symfony) или вообще CMS а-ля wordpress
@@MetalRex100 на го вообще-то есть шаблонизатор.
@@user-fg6jw1cy5v можете попробовать на нем полноценный сайт написать)
Я правильно понял, что говоря про микросервисы автор подразумевал много много монолитов?
а мне интересно, когда у вас 100500 запросов в секунду и один из сервисов не ацкает задачу из-за повторяющейся ошибки... Что будет с системой, когда память закончится?
Вот написал и предположу, что помимо шины по-любому нужно хранить таски ещё и в бд с состояниями/статусами по всем пройденным микросервисам. Либо всё-таки мутить псевдотранзакционность с откатами и следить, чтобы ошибка по задаче не повторялась более N раз.
Но реальные кейсы с решениями хотелось бы узнать.
1. У вас будет копиться очередь событий. Часто применяют retry policy и dead letter queue: если возникли ошибки при обработке (недоступна бд, как пример), то в соответствии с политикой ретраев он может попытаться еще несколько раз обработать и если не вышло, то перенаправить в dead letter queue для последующего разбора инцидента и работ по компенсации последствий
2. Вам придется в любом случае следить за гарантиями отправки событий в брокер и гарантиями идемпотентности обработки этих событий.
3. В своем предположении вы описываете сагу в виде command orchestration (еще ее называют менеджер процесса и распределенная транзакция). Если вы разделили ответственности сервисов так, что вам необходим оркестратор для какого-то процесса, то это противоречит практикам микросервисного подхода (smart endpoints and dumb pipes) и вы изобретаете ESB.
Внедряли туда - куда не нужны - все что нужно знать о микросервисах
резанули ухо слова, а шина гарантирует доставку до получателя :)))
Так а Ack на что?
Ну да, переиспользовать код в монолите вообще не возможно. Это все что нужно знать о современных разработчиках и архитекторах.
возможно, но сложно!
@@brodlovherrsov7097 да вы что? Это чем же сложно? Оформил оператор в отдельный класс и Алга. Дерзай его из любого места. Даже в старую функцию в мейне можно обернуть, если код часто нужен много где. В монолите то как раз проще делать реюз кода, ибо он при добавлении новой функции, использщей куски других функций тебе гораздо меньше надо сношаться по теме импорта и зависимостей кода.
@@zerocool4eg я работал на зарубежные банки
Net Fret вы там в зарубежных банках головой в хранилище железное бьетесь на кастинге? У вас любой исходник на любом языке начинается со слов import или include, или use. Это и есть переиспользовние кода и его изобрели полвека назад, даже побольше.
Егор не палите, давайте вдвоем знать секрет
с упавшим брокером и БД какой-то вообще лютый велосипед
@@alexanderbikk8055 спасибо
Комитить в один репозиторий не сложно.
иногда даже полезно
Ээээм, чувак несёт чушь в вопросе rabbit-а и асинхроники.
Описанная им схема в такой форме вообще нихрена не гарантирует.
И нужен комплект контроля над рэббитом и сервисами.
И да, рэббит гарантирует доставку только если не упал, это первое, а второе, то, что рэббит доставил сообщение - не гарантирует, что оно будет обработано.
так что никакой гарантии здесь нет от слова совсем
Вероятно речь о JMS клиенте для ребит, и там вполне себе отлично настраивается акк только после успешного процессинга месседжа, ну тоесть констюи и процессинг происходит в единой транзакции и если вы получаете рантайм експешн, то этого успешного акка просто не будет. Таким образом месседж останется в брокере, в той же кьюхе или в длкью уже не столь важно. Важно, что вы не потеряли данные.
распределенность ради распределенности, микросервисы ради микросервисов, сплошная антиреклама микросервисов.
как это нет трансакций? а distributed transactions это что? например Кафка или МонгоДБ поддерживают трансакции, хотя могут быть на разных нодах данные.
Так что, возможно, но сложно
9:40 такой распил грозит большими проблемами со связностью в будущем.
подскажите новичку, плиз. А как надо распилить правильно?
Доклад - прекрасный (хотя и очень поверхностный) сборник антипаттернов реализации микросервисной (вернее - просто распределенной) архитектуры.
Какой пункт не возьми - всюду используется или неоптимальное решение или просто неверное утверждение, в лучшем случае - собственные костыли
Грустно (
А можно поконкретней?
@@maximmaximych тоже такие комментарии забавляют - ой, у вас тут все очень плохо, а как хорошо ни за что не расскажу, секрет. :)))) Ничего он вам поконкретней не расскажет, потому что не знает, а высказаться хочется ) Опыта столько еще ни у кого не накоплено, разве что у гигантов вроде нетфликса, но что-то я сомневаюсь, что мистер Phillip Delgyado оттуда к нам пришел смотреть этот доклад.
Идиотский подход. Плагины уже отменили?
Ключевое, перескажу: это модно, поэтому, чтобы привлечь новых, молодых, модных же разрабов, надо быть в модном тренде. Дичь, но, видимо, это и есть круговорот жизни.
Слабый и несфокусированный доклад
очередной раз только убеждаюсь что микросервисы это новомодный бред. говорит о том что они убирают геморой, а потом сразу вываливает весь другой геморой этого микротанца с бубном...
Все просто зависит от потребностей вашего бизнеса. Не стоит пихать микросервисы везде, да и вы вполне можете реализовывать просто SOA.
Так никто и не говорит, что микросервисы решают все проблемы и все упрощают. Наоборот, все говорят, что станет сложнее, намного сложнее. Никакой адекватный человек, в том числе здесь в видео, не советует писать на них сразу все и вся. Хуже будет. Как всегда, все упирается в компромиссы. Микросервисы со своей сложностью решают другие проблемы, которые могут перевесить в общем итоге. Такое ощущение, что даже видео не смотрели и ничего про микросервисы не читали, кроме комментов на хабре. В интернете полно адекватных видео от нетфликса, убер и кучи других, где все это есть на огромных нагрузках. Там и говорят, зачем оно им и почему оно стоит дополнительной головной боли.
Вот че реально херня это их брокер сообщений на ровном месте. Они его добавили, все хорошо, но все равно осталась страховка в виде флажка, чтобы данные не ушли куда-то и надо попробовать еще раз. С тем же успехом и без лишней подсистемы это можно сделать без брокера прямыми запросами между сервисами. Не дошло - поставил флажок, оставил до лучших времен. В этом месте реально попахивает микросервисами головного мозга.
@@creker1 Брокер нужен, например, чтобы можно в n микросервисов раскидать запросы и чтобы не велосипедить очередь на самом микросервисе (который может упасть вместе с очередью). Каждому микросервису не нужно знать кому именно и куда кидать сообщения, нужен только адрес брокера.
"Это не серебряная пуля..." )))) Вообще-то есть нормальные аналоги на русском: не панацея, не волшебная палочка, не магическое средство...
если доклад нацелен в том числе и на людей, читавших Ф. Брукса, то уместно все же сказать «серебряная пуля»
Душнила. Путина любишь наверное?