Преимущества и недостатки микросервисной архитектуры в HeadHunter / Антон Иванов (HeadHunter)
Вставка
- Опубліковано 27 чер 2017
- Приглашаем на конференцию Saint HighLoad++ 2024, которая пройдет 24 и 25 июня в Санкт-Петербурге!
Программа, подробности и билеты по ссылке: vk.cc/cuyIqx
--------
--------
РИТ++ 2017
Тезисы:
ritfest.ru/2017/abstracts/2749...
Раньше HeadHunter был большим монолитным приложением. Несколько лет назад мы приняли решение выделять из него микросервисы. За несколько лет мы поняли, что микросервисы - это не серебряная пуля и при неправильном "распиле" создают существенные проблемы: сложность разработки, деплоя, эксплуатации и др. Иногда эти проблемы сводят на нет преимущества от использования микросервисов.
В докладе хочу взвесить преимущества и недостатки микросервисов при вертикальном и горизонтальном делении на микросервисы.
Люблю такие четкие, безводные доклады! Спасибищще!
И главное, что нет никаких «вот…», «ну…» и «аааааа…ээээээ» - сразу видно толкового докладчика.
Водные тоже хороши, хотя можно и поесть, если не куришь
Прекрасный оратор с четкой структурой доклада и великолепным русским языком. Никаких жаргонизмов, никаких беканий-меканий. Спасибо. Как глоток свежего воздуха в общем болоте.
Очень четко и обзорно! Слушается на одном дыхании! Респект докладчику!
Отличный доклад. Очень круто снято и смонтированно. Спасибо за проделанную работу!
Пилить, подгонять, подрезать, на коленке руками, да это же школа ремонта!
Отличный доклад, спасибо.
Отличный спикер, содержательный и интересный доклад
а что за доклад некоего Ивана, про сложность сетевых вызовов упоминается? Спасибо
всё ясно и понятно - побольше таких докладчиков
Отличный доклад.
Хорош доклад!
Хоть МА, хоть монолит, логов будет одинаково.
Команда - владелец может быть и у модуля.
Тестировать хороший модуль или микросервис - тоже без разницы.
Минус три пункта из плюсов микросервисов.
Ага. Хз что приходит в этот модуль, хз что оттуда уходит, хз какие данные он тащит с дао. Бери дебаггер, обмазывайся breackpoint'ами в вперед. Оч. удобно.
Владельца не может быть у модуля. Они все пилить начнут фичи через всю твою вонючую многослойку, а вечером все друг друга переубивают. Когда у команды микросервис, они сидят у себя в уголке, тихо его пилят и общаются с ними только через сетевые запросы. Ставишь задачу, надо на такой запрос такой ответ за такое время и всё. Никаких проблем с тем, что кто-то что-то наговнокодил в твоём монолите и у тебя всё зависло, сожрало память и т.п.
@@crutchmaster9637 Вы путаете технические и административные проблемы. Если кто-то говнокодит - то это административная проблема и микросервисами она не решается, а скорее усугубляется.
Если это монолит, то исходники общие и говнокодера в нём видно. Бывает можно даже что-то вероломно поправить самостоятельно, чтобы не мешало работе своего модуля.
А вот в ситуации с сервисами/отдельными компонентами вы случайным образом тормозящий/падающий говнокод не то, что поправить, а даже увидеть не сможете. Причём чтобы понять откуда идут проблемы, вы должны будете обложиться тестами и логами, не имеющими отношения к вашему сервису. Но даже когда всё станет очевидно - будете посланы в конец очень длинной очереди страждущих. Потому что у говнокодеров, увы, всегда неимоверная масса проблем.
Это я рассказываю по мотивам разбора реальной ситуации из одной крупной российской компании финансового сектора
Зачем показывать докладчика, когда нужны слайды. А так все круто!
Чтобы девушки заценили
Задолбали этим мусорным «круто»!
по "определению" у микросервисов свои данные и по сути они являются отдельными структурами, обычные сервисы дергают одну бд и просто разбивают монолит на уровне модулей
Мне понравилось👍🏻
Спасибо
Кликер плохо работает. Микросеовисы барогозят. Можно с этим что-то сделать?..
барагозят
вышел, без запинок рассказал, показал, на вопросы ответил, логику и знания не потерял на входе... а что, так можно было?
лайк и подписка
спасибо за доклад
Очень крутой чувак.
Задолбали этим вашим «крутой» 🤮
@@universum9876 ну, круто.
Норм
Так они только начали на докеры переходить? :) А с виду такие продвинутые :)
10:00 видимо он про этот доклад ua-cam.com/video/WASm5325GQg/v-deo.html
Мне показалось, докладчик хотел сказать что МС это полная дичь
Показалось
стека технологий не хватает.
На примере можно?
мде. судя по ответам там у них бардак. причем говорят что нагрузочное тестирование на бою делают.
все говорят, что классный доклад, но мне было скучно. Отдельно выделю практически отсутствие слов-паразитов у докладчика
Доклад огонь! Спасибо! но руки в карманах, это боль....
Наконец-то адекватный докладчик с конкретным предложением подумать: а стоит ли игра свеч. Я пропустил или было сказано про потерю согласованности данных и отсутствие ACID? Практически во всех микросервисных архитектурах, которые я видел, было написано самопальное неработающее решение для обеспечения транзакционности: и распределенные локи, и mvcc, и саги и даже умудрились запилить некое подобие 2pc. Но чаще на целостность тупо забивали -- есть служба саппорта, которая всегда разрулит что и где потерялось, и вернет клиенту деньги.
Ну hh по состоянию на 2017 год как видно набрал почти все грабли при переходе на микросервисную архитектуру.
Микросервисы это конечно сложно.
rpc у вас ни вывод не верный ни тест ваш, ось первым же запросом понимает что у вас оба приложения на одном компьютер, и ваш запрос даже до сетевой карты не дойдет, всё пойдет через процессорные сокеты. Так что оверхед по сути тока в парсинге http запроса и ответа.
туда же сариализацию (json\protobuf) и никто не говорит, что микросервисы на одно машине находятся, иначе как их тогда масштабировать
Да, в этом и был смысл слайда с графиком. Даже без участия сети оверхед на маленьких запросах достигает 20 %. Если добавить реальное сетевое взаимодействие, оверхед будет ещё больше.
просто слайды прочитал
Нормальный монолит нужно делать, а не питонить зоопарки.
Уэнтуорт Миллер хуйни не скажет)
Зачем оператор следит за докладчиком и мотает камеру туда сюда? Через 5 минут просмотра уже мутит.
Сударь так вы архитектуру то и не нюхали, и потом по так сказать из своих ошибок её выстраивали... ну это дичь
Доклад хороший, но докладчику нужно чаще выступать.
Доклад о том какие сложности несут микросервисы в больших и высоконагруженных системах.
Доклад ориентирован далеко не на среднего разработчика, разработчику как минимум нужно разбираться в микросервисах и иметь опыт работы с высоконагруженными проектами. Доклад перегружен терминами, его стоит разбить на несколько 40-ка минутных тематических докладов, с человеческим объяснением многих терминов и понятий.
Я сейчас делаю небольшой проект, и столкнусь с теми сложностями, о которых идет речь, только через пару лет после запуска, и только в том случае, если проект взлетит.
В предыдущей попытке я пытался сделать монолит, это было одной из причин провала.
Сейчас микросервисы позволяют сэкономить множество ресурсов на проектировке и быстро сделать конкретные вещи.
Что же касается больших и высоконагруженных проектов, то какого-то универсального решения об их устройстве нет.
Стоит помнить, что микросервисы - не панацея, а всего лишь один из подходов. А архитекторы, вообще-то, для того и нужны, чтобы выстраивать архитектуру исходя из потребностей проекта, а не бездумно запиливать то, что написано в умных книжках.
Ну если бы Антон читал как просите вы, я бы был против :) Всем не угодишь, я рад, что Антон сделал этот доклад для меня :)
+Алексей Камырин
"Микросервисы позволяют сэкономить множество ресурсов на проектировке и быстро сделать конкретные вещи" - вы уверены, что вы именно микросервисы делаете?) Ведь при проектировании микросервисов нужно куда больше внимания проектированию уделять. Вы говорите, что вам нужно было сделать небольшой проект и сделав его на монолите, вы провалились. Есть огромная куча успешных небольших, средних и крупных проектов, которые сделаны на монолитах. Я на 100% уверен, что причиной провала была совсем не монолитная архитектура)) Выбирать микросервисную архитектуру для небольших приложений - это выстрел себе в ногу, на самом деле.
Начинать надо с монолита, а потом его уже распиливать
@@qweqwe123qewweqwe так рекомендуют теоретики типа Фуллера и прочих богов ткорий. Но они не сталкивались с этим на практике. Монолит пилить на микросераисы не очень благодарное занятие..
Звучит так, словно продолжать сидеть на монолите - это тоже годная альтернатива. Ну купите вы 48 ядерный сервер с 3 ТБ оперативы под базу, потом у вас будет умирать база при 40-50 тыс. запросов в секунду как у нас и чё? А всё, оптимизация базы, индексы и прочие денормализации больше не помогают.
Значит получается если просто распилить ваш монолит без существенного, повторяю существенного, изменения бизнес-логик, то у вас все эти 40-50 тыс. запросов будут летать по сети. Буквально, окажется так, что "половина" базы туда-сюда летает по сети. Там будет очень много оверхеда не сетевое взаимодействие.
Но если делать грамотно, то будет куча баз поменьше. И под каждую базу можно будет выделить несколько реплик чтобы распределять нагрузку.
Но тогда что мешает базу монолита также распилить на кучу баз поменьше ?
У монолита БД можно пошардировать
Муть. Ничего конкретного не услышал.
Декомпозиция монолита. Т.е. в монлит вы, банально, не смогли.
А так доклад хороший.
Скучный доклад, потому что тематика HH скучная....
ХХ
@@universum9876 круто
Тимлид команды ? это что за чёрт такой ? по-русски слабо ?
Горит в одном месте от данных слов что ли? Может Вам стоит подумать о том, что все, что мы используем для разработки ПО в российском секторе создано в иностранных компаниях?! За 13 лет опыта в разработке ПО (правоохранительная система, бюджет, страхование, сейчас банк) не было ни единого отечественного программного продукта, применяемого для разработки! И почему же сообщество разработчиков должно с параноидальной патриотичностью использовать русские аналоги слов, если, по большому счету, ни в чем другом, кроме количества слов в словаре и вооружения мы не продвинулись?!
@@leonidsenko6370 Видимо он имел в виду масло масляное :)
Ага, командный лидер команды, получается)))
Леонид Сенько Русские аналоги слов? А можно просто русские слова?
@@leonidsenko6370 при чём тут it и аналоги? Почему не использовал именно русские?
Как не странно у вас фиговый опыт смотрю. Вот вам пример 1С)
Видимо, 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!!!