Преимущества и недостатки микросервисной архитектуры в HeadHunter / Антон Иванов (HeadHunter)
Приглашаем на конференцию Saint HighLoad++ 2024, которая пройдет 24 и 25 июня в Санкт-Петербурге!
Программа, подробности и билеты по ссылке: vk.cc/cuyIqx
--------
--------
РИТ++ 2017
Тезисы:
ritfest.ru/2017/abstracts/2749...
Раньше HeadHunter был большим монолитным приложением. Несколько лет назад мы приняли решение выделять из него микросервисы. За несколько лет мы поняли, что микросервисы - это не серебряная пуля и при неправильном "распиле" создают существенные проблемы: сложность разработки, деплоя, эксплуатации и др. Иногда эти проблемы сводят на нет преимущества от использования микросервисов.
В докладе хочу взвесить преимущества и недостатки микросервисов при вертикальном и горизонтальном делении на микросервисы.
Пікірлер: 79
Прекрасный оратор с четкой структурой доклада и великолепным русским языком. Никаких жаргонизмов, никаких беканий-меканий. Спасибо. Как глоток свежего воздуха в общем болоте.
Люблю такие четкие, безводные доклады! Спасибищще!
@dixydo
5 жыл бұрын
И главное, что нет никаких «вот…», «ну…» и «аааааа…ээээээ» - сразу видно толкового докладчика.
@protiv_bio
Жыл бұрын
Водные тоже хороши, хотя можно и поесть, если не куришь
Очень четко и обзорно! Слушается на одном дыхании! Респект докладчику!
Отличный доклад. Очень круто снято и смонтированно. Спасибо за проделанную работу!
Отличный доклад, спасибо.
Отличный спикер, содержательный и интересный доклад
всё ясно и понятно - побольше таких докладчиков
а что за доклад некоего Ивана, про сложность сетевых вызовов упоминается? Спасибо
Хорош доклад!
Отличный доклад.
Пилить, подгонять, подрезать, на коленке руками, да это же школа ремонта!
Мне понравилось👍🏻
Хоть МА, хоть монолит, логов будет одинаково. Команда - владелец может быть и у модуля. Тестировать хороший модуль или микросервис - тоже без разницы. Минус три пункта из плюсов микросервисов.
@crutchmaster9637
5 жыл бұрын
Ага. Хз что приходит в этот модуль, хз что оттуда уходит, хз какие данные он тащит с дао. Бери дебаггер, обмазывайся breackpoint'ами в вперед. Оч. удобно. Владельца не может быть у модуля. Они все пилить начнут фичи через всю твою вонючую многослойку, а вечером все друг друга переубивают. Когда у команды микросервис, они сидят у себя в уголке, тихо его пилят и общаются с ними только через сетевые запросы. Ставишь задачу, надо на такой запрос такой ответ за такое время и всё. Никаких проблем с тем, что кто-то что-то наговнокодил в твоём монолите и у тебя всё зависло, сожрало память и т.п.
@johngraham8220
5 жыл бұрын
@@crutchmaster9637 Вы путаете технические и административные проблемы. Если кто-то говнокодит - то это административная проблема и микросервисами она не решается, а скорее усугубляется. Если это монолит, то исходники общие и говнокодера в нём видно. Бывает можно даже что-то вероломно поправить самостоятельно, чтобы не мешало работе своего модуля. А вот в ситуации с сервисами/отдельными компонентами вы случайным образом тормозящий/падающий говнокод не то, что поправить, а даже увидеть не сможете. Причём чтобы понять откуда идут проблемы, вы должны будете обложиться тестами и логами, не имеющими отношения к вашему сервису. Но даже когда всё станет очевидно - будете посланы в конец очень длинной очереди страждущих. Потому что у говнокодеров, увы, всегда неимоверная масса проблем. Это я рассказываю по мотивам разбора реальной ситуации из одной крупной российской компании финансового сектора
по "определению" у микросервисов свои данные и по сути они являются отдельными структурами, обычные сервисы дергают одну бд и просто разбивают монолит на уровне модулей
Спасибо
Зачем показывать докладчика, когда нужны слайды. А так все круто!
@t3m8ch79
4 жыл бұрын
Чтобы девушки заценили
@universum9876
4 жыл бұрын
Задолбали этим мусорным «круто»!
спасибо за доклад
Норм
лайк и подписка
10:00 видимо он про этот доклад kzread.info/dash/bejne/iXWHz5dsYpitgco.html
Очень крутой чувак.
@universum9876
4 жыл бұрын
Задолбали этим вашим «крутой» 🤮
@mehabox
4 жыл бұрын
@@universum9876 ну, круто.
Кликер плохо работает. Микросеовисы барогозят. Можно с этим что-то сделать?..
@universum9876
4 жыл бұрын
барагозят
Так они только начали на докеры переходить? :) А с виду такие продвинутые :)
Доклад огонь! Спасибо! но руки в карманах, это боль....
вышел, без запинок рассказал, показал, на вопросы ответил, логику и знания не потерял на входе... а что, так можно было?
стека технологий не хватает.
@TheoDoricusMalicus
5 жыл бұрын
На примере можно?
мде. судя по ответам там у них бардак. причем говорят что нагрузочное тестирование на бою делают.
Наконец-то адекватный докладчик с конкретным предложением подумать: а стоит ли игра свеч. Я пропустил или было сказано про потерю согласованности данных и отсутствие ACID? Практически во всех микросервисных архитектурах, которые я видел, было написано самопальное неработающее решение для обеспечения транзакционности: и распределенные локи, и mvcc, и саги и даже умудрились запилить некое подобие 2pc. Но чаще на целостность тупо забивали -- есть служба саппорта, которая всегда разрулит что и где потерялось, и вернет клиенту деньги.
@vifvrTtb0vmFtbyrM_Q
2 жыл бұрын
Ну hh по состоянию на 2017 год как видно набрал почти все грабли при переходе на микросервисную архитектуру. Микросервисы это конечно сложно.
Мне показалось, докладчик хотел сказать что МС это полная дичь
@user-ur9fs8cx4f
4 жыл бұрын
Показалось
все говорят, что классный доклад, но мне было скучно. Отдельно выделю практически отсутствие слов-паразитов у докладчика
просто слайды прочитал
rpc у вас ни вывод не верный ни тест ваш, ось первым же запросом понимает что у вас оба приложения на одном компьютер, и ваш запрос даже до сетевой карты не дойдет, всё пойдет через процессорные сокеты. Так что оверхед по сути тока в парсинге http запроса и ответа.
@vladislavsabenin8473
4 жыл бұрын
туда же сариализацию (json\protobuf) и никто не говорит, что микросервисы на одно машине находятся, иначе как их тогда масштабировать
@vryaboshapko
2 жыл бұрын
Да, в этом и был смысл слайда с графиком. Даже без участия сети оверхед на маленьких запросах достигает 20 %. Если добавить реальное сетевое взаимодействие, оверхед будет ещё больше.
Уэнтуорт Миллер хуйни не скажет)
Нормальный монолит нужно делать, а не питонить зоопарки.
Звучит так, словно продолжать сидеть на монолите - это тоже годная альтернатива. Ну купите вы 48 ядерный сервер с 3 ТБ оперативы под базу, потом у вас будет умирать база при 40-50 тыс. запросов в секунду как у нас и чё? А всё, оптимизация базы, индексы и прочие денормализации больше не помогают.
@vifvrTtb0vmFtbyrM_Q
2 жыл бұрын
Значит получается если просто распилить ваш монолит без существенного, повторяю существенного, изменения бизнес-логик, то у вас все эти 40-50 тыс. запросов будут летать по сети. Буквально, окажется так, что "половина" базы туда-сюда летает по сети. Там будет очень много оверхеда не сетевое взаимодействие. Но если делать грамотно, то будет куча баз поменьше. И под каждую базу можно будет выделить несколько реплик чтобы распределять нагрузку. Но тогда что мешает базу монолита также распилить на кучу баз поменьше ?
@constantinegeist1854
10 ай бұрын
У монолита БД можно пошардировать
Видимо, 5 лет назад грепать логи, видимо, было не очень удобно, но сейчас этим занимается loki/grafana, ELK, Sentry поиск хоть вдоль, хоть поперек не проблема. Ошибок становится больше, да - задача аналитики Каждый сервис должен отдавать метрики, логи, трейсы - задача разработчика Переписывание api - пользуемся принципом open/close Интеграционное тестирование, а также нагрузочное тестирование необходимо проводить в отдельных средах Архитектурные решения должны быть продуманы, да. Есть на это паттерны highLoad Отдельная железка на БД - это overhead! Kubernetes must have!!! (5 лет назад это было супер. А теперь это обыденность!) Как пилить монолит на сервисы - есть уже DDD/EventStorming В МСА как раз роль разработчиков становится меньше, а других больше. В самом идеально случае разработчики как самый большой отдел не нужен в штате. Можно иметь разрозненные команды, которые мы можем держать за штатом и платить по результату. При этом должны быть четкие контркты, включая тесты, бенчмарки, какие метрики должны выплевывать, какие ошибки могут быть и т.д. Но на стороне штата должны быть такие сильные компетенции, как аналитики, архитекторы (архитектура должна проходить ежегодный прув у таких компаний, как Онтеко, Флант). Далее должны быть QA, которые с помощью, допустим, k6 делать нагрузочные тесты, интеграционные тесты можно пистаь с помощью postman. Далее, должны быть очень сильные штатные SRE, которые бы смогли быстро развернуть среду, накатить данные, поднимать всякие ELK, Grafana, Prometheus и т.д. Поднимать свое железо в наше время нонсенс. Покупать можно только тогда, когда затраты на облако за год превышают железо. Иметь свое SSO - нонсенс. Можно ли стартапам сразу пилить в МСА? Конечно! Во-первых, это драйвово с точки зрения RnD. Во-вторых, разработка в МСА не такая кусачая! Код должен быть хорошо изменяем! То есть код должен разрабатываться не с бухты-барахты, а по какому-то шаблону. Желательно на одном языке, например, на Go. Могу предложить бутстрапинг от goKratos. При этом изменение вызова с RPC на publish в Kafka делается достаточно быстро. Также можно автоматом во все репы (мультирепа, поскольку мы передаем разным командам) можно добавлять/подправлять всякие правильные строчки кода. И вообще это всё не rocket science!!!
Доклад хороший, но докладчику нужно чаще выступать. Доклад о том какие сложности несут микросервисы в больших и высоконагруженных системах. Доклад ориентирован далеко не на среднего разработчика, разработчику как минимум нужно разбираться в микросервисах и иметь опыт работы с высоконагруженными проектами. Доклад перегружен терминами, его стоит разбить на несколько 40-ка минутных тематических докладов, с человеческим объяснением многих терминов и понятий. Я сейчас делаю небольшой проект, и столкнусь с теми сложностями, о которых идет речь, только через пару лет после запуска, и только в том случае, если проект взлетит. В предыдущей попытке я пытался сделать монолит, это было одной из причин провала. Сейчас микросервисы позволяют сэкономить множество ресурсов на проектировке и быстро сделать конкретные вещи. Что же касается больших и высоконагруженных проектов, то какого-то универсального решения об их устройстве нет. Стоит помнить, что микросервисы - не панацея, а всего лишь один из подходов. А архитекторы, вообще-то, для того и нужны, чтобы выстраивать архитектуру исходя из потребностей проекта, а не бездумно запиливать то, что написано в умных книжках.
@dzen1234
6 жыл бұрын
Ну если бы Антон читал как просите вы, я бы был против :) Всем не угодишь, я рад, что Антон сделал этот доклад для меня :)
@kd8437
5 жыл бұрын
+Алексей Камырин "Микросервисы позволяют сэкономить множество ресурсов на проектировке и быстро сделать конкретные вещи" - вы уверены, что вы именно микросервисы делаете?) Ведь при проектировании микросервисов нужно куда больше внимания проектированию уделять. Вы говорите, что вам нужно было сделать небольшой проект и сделав его на монолите, вы провалились. Есть огромная куча успешных небольших, средних и крупных проектов, которые сделаны на монолитах. Я на 100% уверен, что причиной провала была совсем не монолитная архитектура)) Выбирать микросервисную архитектуру для небольших приложений - это выстрел себе в ногу, на самом деле.
@qweqwe123qewweqwe
5 жыл бұрын
Начинать надо с монолита, а потом его уже распиливать
@TheoDoricusMalicus
5 жыл бұрын
@@qweqwe123qewweqwe так рекомендуют теоретики типа Фуллера и прочих богов ткорий. Но они не сталкивались с этим на практике. Монолит пилить на микросераисы не очень благодарное занятие..
Зачем оператор следит за докладчиком и мотает камеру туда сюда? Через 5 минут просмотра уже мутит.
Сударь так вы архитектуру то и не нюхали, и потом по так сказать из своих ошибок её выстраивали... ну это дичь
Муть. Ничего конкретного не услышал.
Декомпозиция монолита. Т.е. в монлит вы, банально, не смогли. А так доклад хороший.
Тимлид команды ? это что за чёрт такой ? по-русски слабо ?
@leonidsenko6370
5 жыл бұрын
Горит в одном месте от данных слов что ли? Может Вам стоит подумать о том, что все, что мы используем для разработки ПО в российском секторе создано в иностранных компаниях?! За 13 лет опыта в разработке ПО (правоохранительная система, бюджет, страхование, сейчас банк) не было ни единого отечественного программного продукта, применяемого для разработки! И почему же сообщество разработчиков должно с параноидальной патриотичностью использовать русские аналоги слов, если, по большому счету, ни в чем другом, кроме количества слов в словаре и вооружения мы не продвинулись?!
@qweqwe123qewweqwe
5 жыл бұрын
@@leonidsenko6370 Видимо он имел в виду масло масляное :)
@TheoDoricusMalicus
5 жыл бұрын
Ага, командный лидер команды, получается)))
@universum9876
4 жыл бұрын
Леонид Сенько Русские аналоги слов? А можно просто русские слова?
@NikK0lay
4 жыл бұрын
@@leonidsenko6370 при чём тут it и аналоги? Почему не использовал именно русские? Как не странно у вас фиговый опыт смотрю. Вот вам пример 1С)
Скучный доклад, потому что тематика HH скучная....
@universum9876
4 жыл бұрын
ХХ
@mehabox
4 жыл бұрын
@@universum9876 круто