Прекрасный оратор с четкой структурой доклада и великолепным русским языком. Никаких жаргонизмов, никаких беканий-меканий. Спасибо. Как глоток свежего воздуха в общем болоте.
Хоть МА, хоть монолит, логов будет одинаково. Команда - владелец может быть и у модуля. Тестировать хороший модуль или микросервис - тоже без разницы. Минус три пункта из плюсов микросервисов.
Ага. Хз что приходит в этот модуль, хз что оттуда уходит, хз какие данные он тащит с дао. Бери дебаггер, обмазывайся breackpoint'ами в вперед. Оч. удобно. Владельца не может быть у модуля. Они все пилить начнут фичи через всю твою вонючую многослойку, а вечером все друг друга переубивают. Когда у команды микросервис, они сидят у себя в уголке, тихо его пилят и общаются с ними только через сетевые запросы. Ставишь задачу, надо на такой запрос такой ответ за такое время и всё. Никаких проблем с тем, что кто-то что-то наговнокодил в твоём монолите и у тебя всё зависло, сожрало память и т.п.
@@crutchmaster9637 Вы путаете технические и административные проблемы. Если кто-то говнокодит - то это административная проблема и микросервисами она не решается, а скорее усугубляется. Если это монолит, то исходники общие и говнокодера в нём видно. Бывает можно даже что-то вероломно поправить самостоятельно, чтобы не мешало работе своего модуля. А вот в ситуации с сервисами/отдельными компонентами вы случайным образом тормозящий/падающий говнокод не то, что поправить, а даже увидеть не сможете. Причём чтобы понять откуда идут проблемы, вы должны будете обложиться тестами и логами, не имеющими отношения к вашему сервису. Но даже когда всё станет очевидно - будете посланы в конец очень длинной очереди страждущих. Потому что у говнокодеров, увы, всегда неимоверная масса проблем. Это я рассказываю по мотивам разбора реальной ситуации из одной крупной российской компании финансового сектора
по "определению" у микросервисов свои данные и по сути они являются отдельными структурами, обычные сервисы дергают одну бд и просто разбивают монолит на уровне модулей
Видимо, 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 запроса и ответа.
Да, в этом и был смысл слайда с графиком. Даже без участия сети оверхед на маленьких запросах достигает 20 %. Если добавить реальное сетевое взаимодействие, оверхед будет ещё больше.
Доклад хороший, но докладчику нужно чаще выступать. Доклад о том какие сложности несут микросервисы в больших и высоконагруженных системах. Доклад ориентирован далеко не на среднего разработчика, разработчику как минимум нужно разбираться в микросервисах и иметь опыт работы с высоконагруженными проектами. Доклад перегружен терминами, его стоит разбить на несколько 40-ка минутных тематических докладов, с человеческим объяснением многих терминов и понятий. Я сейчас делаю небольшой проект, и столкнусь с теми сложностями, о которых идет речь, только через пару лет после запуска, и только в том случае, если проект взлетит. В предыдущей попытке я пытался сделать монолит, это было одной из причин провала. Сейчас микросервисы позволяют сэкономить множество ресурсов на проектировке и быстро сделать конкретные вещи. Что же касается больших и высоконагруженных проектов, то какого-то универсального решения об их устройстве нет. Стоит помнить, что микросервисы - не панацея, а всего лишь один из подходов. А архитекторы, вообще-то, для того и нужны, чтобы выстраивать архитектуру исходя из потребностей проекта, а не бездумно запиливать то, что написано в умных книжках.
+Алексей Камырин "Микросервисы позволяют сэкономить множество ресурсов на проектировке и быстро сделать конкретные вещи" - вы уверены, что вы именно микросервисы делаете?) Ведь при проектировании микросервисов нужно куда больше внимания проектированию уделять. Вы говорите, что вам нужно было сделать небольшой проект и сделав его на монолите, вы провалились. Есть огромная куча успешных небольших, средних и крупных проектов, которые сделаны на монолитах. Я на 100% уверен, что причиной провала была совсем не монолитная архитектура)) Выбирать микросервисную архитектуру для небольших приложений - это выстрел себе в ногу, на самом деле.
@@qweqwe123qewweqwe так рекомендуют теоретики типа Фуллера и прочих богов ткорий. Но они не сталкивались с этим на практике. Монолит пилить на микросераисы не очень благодарное занятие..
Звучит так, словно продолжать сидеть на монолите - это тоже годная альтернатива. Ну купите вы 48 ядерный сервер с 3 ТБ оперативы под базу, потом у вас будет умирать база при 40-50 тыс. запросов в секунду как у нас и чё? А всё, оптимизация базы, индексы и прочие денормализации больше не помогают.
Значит получается если просто распилить ваш монолит без существенного, повторяю существенного, изменения бизнес-логик, то у вас все эти 40-50 тыс. запросов будут летать по сети. Буквально, окажется так, что "половина" базы туда-сюда летает по сети. Там будет очень много оверхеда не сетевое взаимодействие. Но если делать грамотно, то будет куча баз поменьше. И под каждую базу можно будет выделить несколько реплик чтобы распределять нагрузку. Но тогда что мешает базу монолита также распилить на кучу баз поменьше ?
Горит в одном месте от данных слов что ли? Может Вам стоит подумать о том, что все, что мы используем для разработки ПО в российском секторе создано в иностранных компаниях?! За 13 лет опыта в разработке ПО (правоохранительная система, бюджет, страхование, сейчас банк) не было ни единого отечественного программного продукта, применяемого для разработки! И почему же сообщество разработчиков должно с параноидальной патриотичностью использовать русские аналоги слов, если, по большому счету, ни в чем другом, кроме количества слов в словаре и вооружения мы не продвинулись?!
Люблю такие четкие, безводные доклады! Спасибищще!
И главное, что нет никаких «вот…», «ну…» и «аааааа…ээээээ» - сразу видно толкового докладчика.
Водные тоже хороши, хотя можно и поесть, если не куришь
Прекрасный оратор с четкой структурой доклада и великолепным русским языком. Никаких жаргонизмов, никаких беканий-меканий. Спасибо. Как глоток свежего воздуха в общем болоте.
Отличный доклад. Очень круто снято и смонтированно. Спасибо за проделанную работу!
Очень четко и обзорно! Слушается на одном дыхании! Респект докладчику!
Отличный доклад, спасибо.
Отличный спикер, содержательный и интересный доклад
а что за доклад некоего Ивана, про сложность сетевых вызовов упоминается? Спасибо
Хорош доклад!
всё ясно и понятно - побольше таких докладчиков
Пилить, подгонять, подрезать, на коленке руками, да это же школа ремонта!
Хоть МА, хоть монолит, логов будет одинаково.
Команда - владелец может быть и у модуля.
Тестировать хороший модуль или микросервис - тоже без разницы.
Минус три пункта из плюсов микросервисов.
Ага. Хз что приходит в этот модуль, хз что оттуда уходит, хз какие данные он тащит с дао. Бери дебаггер, обмазывайся breackpoint'ами в вперед. Оч. удобно.
Владельца не может быть у модуля. Они все пилить начнут фичи через всю твою вонючую многослойку, а вечером все друг друга переубивают. Когда у команды микросервис, они сидят у себя в уголке, тихо его пилят и общаются с ними только через сетевые запросы. Ставишь задачу, надо на такой запрос такой ответ за такое время и всё. Никаких проблем с тем, что кто-то что-то наговнокодил в твоём монолите и у тебя всё зависло, сожрало память и т.п.
@@crutchmaster9637 Вы путаете технические и административные проблемы. Если кто-то говнокодит - то это административная проблема и микросервисами она не решается, а скорее усугубляется.
Если это монолит, то исходники общие и говнокодера в нём видно. Бывает можно даже что-то вероломно поправить самостоятельно, чтобы не мешало работе своего модуля.
А вот в ситуации с сервисами/отдельными компонентами вы случайным образом тормозящий/падающий говнокод не то, что поправить, а даже увидеть не сможете. Причём чтобы понять откуда идут проблемы, вы должны будете обложиться тестами и логами, не имеющими отношения к вашему сервису. Но даже когда всё станет очевидно - будете посланы в конец очень длинной очереди страждущих. Потому что у говнокодеров, увы, всегда неимоверная масса проблем.
Это я рассказываю по мотивам разбора реальной ситуации из одной крупной российской компании финансового сектора
10:00 видимо он про этот доклад th-cam.com/video/WASm5325GQg/w-d-xo.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. Но чаще на целостность тупо забивали -- есть служба саппорта, которая всегда разрулит что и где потерялось, и вернет клиенту деньги.
Ну hh по состоянию на 2017 год как видно набрал почти все грабли при переходе на микросервисную архитектуру.
Микросервисы это конечно сложно.
Очень крутой чувак.
Задолбали этим вашим «крутой» 🤮
@@UniversumXX ну, круто.
стека технологий не хватает.
На примере можно?
Так они только начали на докеры переходить? :) А с виду такие продвинутые :)
Мне показалось, докладчик хотел сказать что МС это полная дичь
все говорят, что классный доклад, но мне было скучно. Отдельно выделю практически отсутствие слов-паразитов у докладчика
лайк и подписка
rpc у вас ни вывод не верный ни тест ваш, ось первым же запросом понимает что у вас оба приложения на одном компьютер, и ваш запрос даже до сетевой карты не дойдет, всё пойдет через процессорные сокеты. Так что оверхед по сути тока в парсинге http запроса и ответа.
туда же сариализацию (json\protobuf) и никто не говорит, что микросервисы на одно машине находятся, иначе как их тогда масштабировать
Да, в этом и был смысл слайда с графиком. Даже без участия сети оверхед на маленьких запросах достигает 20 %. Если добавить реальное сетевое взаимодействие, оверхед будет ещё больше.
спасибо за доклад
Доклад огонь! Спасибо! но руки в карманах, это боль....
Норм
Нормальный монолит нужно делать, а не питонить зоопарки.
просто слайды прочитал
Уэнтуорт Миллер хуйни не скажет)
Муть. Ничего конкретного не услышал.
Зачем оператор следит за докладчиком и мотает камеру туда сюда? Через 5 минут просмотра уже мутит.
Сударь так вы архитектуру то и не нюхали, и потом по так сказать из своих ошибок её выстраивали... ну это дичь
Доклад хороший, но докладчику нужно чаще выступать.
Доклад о том какие сложности несут микросервисы в больших и высоконагруженных системах.
Доклад ориентирован далеко не на среднего разработчика, разработчику как минимум нужно разбираться в микросервисах и иметь опыт работы с высоконагруженными проектами. Доклад перегружен терминами, его стоит разбить на несколько 40-ка минутных тематических докладов, с человеческим объяснением многих терминов и понятий.
Я сейчас делаю небольшой проект, и столкнусь с теми сложностями, о которых идет речь, только через пару лет после запуска, и только в том случае, если проект взлетит.
В предыдущей попытке я пытался сделать монолит, это было одной из причин провала.
Сейчас микросервисы позволяют сэкономить множество ресурсов на проектировке и быстро сделать конкретные вещи.
Что же касается больших и высоконагруженных проектов, то какого-то универсального решения об их устройстве нет.
Стоит помнить, что микросервисы - не панацея, а всего лишь один из подходов. А архитекторы, вообще-то, для того и нужны, чтобы выстраивать архитектуру исходя из потребностей проекта, а не бездумно запиливать то, что написано в умных книжках.
Ну если бы Антон читал как просите вы, я бы был против :) Всем не угодишь, я рад, что Антон сделал этот доклад для меня :)
+Алексей Камырин
"Микросервисы позволяют сэкономить множество ресурсов на проектировке и быстро сделать конкретные вещи" - вы уверены, что вы именно микросервисы делаете?) Ведь при проектировании микросервисов нужно куда больше внимания проектированию уделять. Вы говорите, что вам нужно было сделать небольшой проект и сделав его на монолите, вы провалились. Есть огромная куча успешных небольших, средних и крупных проектов, которые сделаны на монолитах. Я на 100% уверен, что причиной провала была совсем не монолитная архитектура)) Выбирать микросервисную архитектуру для небольших приложений - это выстрел себе в ногу, на самом деле.
Начинать надо с монолита, а потом его уже распиливать
@@qweqwe123qewweqwe так рекомендуют теоретики типа Фуллера и прочих богов ткорий. Но они не сталкивались с этим на практике. Монолит пилить на микросераисы не очень благодарное занятие..
Звучит так, словно продолжать сидеть на монолите - это тоже годная альтернатива. Ну купите вы 48 ядерный сервер с 3 ТБ оперативы под базу, потом у вас будет умирать база при 40-50 тыс. запросов в секунду как у нас и чё? А всё, оптимизация базы, индексы и прочие денормализации больше не помогают.
Значит получается если просто распилить ваш монолит без существенного, повторяю существенного, изменения бизнес-логик, то у вас все эти 40-50 тыс. запросов будут летать по сети. Буквально, окажется так, что "половина" базы туда-сюда летает по сети. Там будет очень много оверхеда не сетевое взаимодействие.
Но если делать грамотно, то будет куча баз поменьше. И под каждую базу можно будет выделить несколько реплик чтобы распределять нагрузку.
Но тогда что мешает базу монолита также распилить на кучу баз поменьше ?
У монолита БД можно пошардировать
Декомпозиция монолита. Т.е. в монлит вы, банально, не смогли.
А так доклад хороший.
Скучный доклад, потому что тематика HH скучная....
ХХ
@@UniversumXX круто
Тимлид команды ? это что за чёрт такой ? по-русски слабо ?
Горит в одном месте от данных слов что ли? Может Вам стоит подумать о том, что все, что мы используем для разработки ПО в российском секторе создано в иностранных компаниях?! За 13 лет опыта в разработке ПО (правоохранительная система, бюджет, страхование, сейчас банк) не было ни единого отечественного программного продукта, применяемого для разработки! И почему же сообщество разработчиков должно с параноидальной патриотичностью использовать русские аналоги слов, если, по большому счету, ни в чем другом, кроме количества слов в словаре и вооружения мы не продвинулись?!
@@leonidsenko6370 Видимо он имел в виду масло масляное :)
Ага, командный лидер команды, получается)))
Леонид Сенько Русские аналоги слов? А можно просто русские слова?
@@leonidsenko6370 при чём тут it и аналоги? Почему не использовал именно русские?
Как не странно у вас фиговый опыт смотрю. Вот вам пример 1С)