Преимущества и недостатки микросервисной архитектуры в HeadHunter / Антон Иванов (HeadHunter) 

Люблю такие четкие, безводные доклады! Спасибищще!

Прекрасный оратор с четкой структурой доклада и великолепным русским языком. Никаких жаргонизмов, никаких беканий-меканий. Спасибо. Как глоток свежего воздуха в общем болоте.

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

Очень четко и обзорно! Слушается на одном дыхании! Респект докладчику!

Отличный доклад, спасибо.

а что за доклад некоего Ивана, про сложность сетевых вызовов упоминается? Спасибо

Отличный спикер, содержательный и интересный доклад

всё ясно и понятно - побольше таких докладчиков

Пилить, подгонять, подрезать, на коленке руками, да это же школа ремонта!

Отличный доклад.

Хорош доклад!

Мне понравилось👍🏻

Спасибо

Хоть МА, хоть монолит, логов будет одинаково. Команда - владелец может быть и у модуля. Тестировать хороший модуль или микросервис - тоже без разницы. Минус три пункта из плюсов микросервисов.

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

Зачем показывать докладчика, когда нужны слайды. А так все круто!

лайк и подписка

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

спасибо за доклад

Норм

Очень крутой чувак.

Кликер плохо работает. Микросеовисы барогозят. Можно с этим что-то сделать?..

10:00 видимо он про этот доклад ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-WASm5325GQg.html

Так они только начали на докеры переходить? :) А с виду такие продвинутые :)

стека технологий не хватает.

Доклад огонь! Спасибо! но руки в карманах, это боль....

Видимо, 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!!!

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

мде. судя по ответам там у них бардак. причем говорят что нагрузочное тестирование на бою делают.

Мне показалось, докладчик хотел сказать что МС это полная дичь

просто слайды прочитал

Наконец-то адекватный докладчик с конкретным предложением подумать: а стоит ли игра свеч. Я пропустил или было сказано про потерю согласованности данных и отсутствие ACID? Практически во всех микросервисных архитектурах, которые я видел, было написано самопальное неработающее решение для обеспечения транзакционности: и распределенные локи, и mvcc, и саги и даже умудрились запилить некое подобие 2pc. Но чаще на целостность тупо забивали -- есть служба саппорта, которая всегда разрулит что и где потерялось, и вернет клиенту деньги.

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

Уэнтуорт Миллер хуйни не скажет)

Нормальный монолит нужно делать, а не питонить зоопарки.

Муть. Ничего конкретного не услышал.

Сударь так вы архитектуру то и не нюхали, и потом по так сказать из своих ошибок её выстраивали... ну это дичь

Звучит так, словно продолжать сидеть на монолите - это тоже годная альтернатива. Ну купите вы 48 ядерный сервер с 3 ТБ оперативы под базу, потом у вас будет умирать база при 40-50 тыс. запросов в секунду как у нас и чё? А всё, оптимизация базы, индексы и прочие денормализации больше не помогают.

Зачем оператор следит за докладчиком и мотает камеру туда сюда? Через 5 минут просмотра уже мутит.

Доклад хороший, но докладчику нужно чаще выступать. Доклад о том какие сложности несут микросервисы в больших и высоконагруженных системах. Доклад ориентирован далеко не на среднего разработчика, разработчику как минимум нужно разбираться в микросервисах и иметь опыт работы с высоконагруженными проектами. Доклад перегружен терминами, его стоит разбить на несколько 40-ка минутных тематических докладов, с человеческим объяснением многих терминов и понятий. Я сейчас делаю небольшой проект, и столкнусь с теми сложностями, о которых идет речь, только через пару лет после запуска, и только в том случае, если проект взлетит. В предыдущей попытке я пытался сделать монолит, это было одной из причин провала. Сейчас микросервисы позволяют сэкономить множество ресурсов на проектировке и быстро сделать конкретные вещи. Что же касается больших и высоконагруженных проектов, то какого-то универсального решения об их устройстве нет. Стоит помнить, что микросервисы - не панацея, а всего лишь один из подходов. А архитекторы, вообще-то, для того и нужны, чтобы выстраивать архитектуру исходя из потребностей проекта, а не бездумно запиливать то, что написано в умных книжках.

Декомпозиция монолита. Т.е. в монлит вы, банально, не смогли. А так доклад хороший.

Скучный доклад, потому что тематика HH скучная....

Тимлид команды ? это что за чёрт такой ? по-русски слабо ?