Комментарии 12
Простите, но после прочтения складывается впечатление, что статью писал не QA-инженер, а ChatGPT по первому запросу " напиши легкую статью для всех про микросервисные паттерны". Тот самый уровень воды, который пытаются выдавить на собеседованиях джуны, когда делают вид, что в теме, но не могут ответить ни на один уточняющий вопрос
Возьмем тот же Circuit Breaker, автор пересказывает теорию про три состояния, но полностью игнорирует практическую реализацию. Где конкретика по порогам срабатывания? Какие метрики отслеживать, таймауты, 5xx, slow responses? Какой процент ошибок считать критическим, 50% или 80%? Как избежать ложных срабатываний при скачках нагрузки? Оказывается, можно написать целую статью и не ответить ни на один по-настоящему важный вопрос.
Статья не просто бесполезна, она вредна. Новички поведутся на этот псевдо-экспертный тон, а опытные ребята сразу увидят сборник очевидных тезисов, которые гуглятся за 5 минут. Уровень плохого реферата, а не материала для профессионального сообщества
Добрый вечер, большое спасибо за подробную обратную связь! Статья действительно больше обзорная (но про GPT было обидно, да)) и задумывалась как собеседовательный чек-лист без глубокого погружения, а не исчерпывающий материал по теме.
Что касается практической реализации, думаю не будет лишним сделать отдельную статью по тому же CB. Собственно, глубокий практический разбор каждого упомянутого паттерна тянет на собственную статью, потому что при попытках уместить все в одну получится талмуд.
К слову сказать более подробный материал, в том числе ответы на ваши вопросы, вы можете услышать на открытом уроке, ссылка есть в статье, подключайтесь)
Я лично не считаю что подобные обзоры бесполезны или вредны, при подготовке к собеседованиям имхо они служат хорошей точкой входа, в том числе на вводном уровне. Понятно же, что одной единственной прочитанной статьи не хватит для прохождения собеседования даже на уровень стажера.
QA про микросервисы?
Ну расскажите, что со временем, как деплоим новые версии, имеем backward compatibility, решаем сохранением старых версий апи, и потом получаем что?
Любая микросервисная архитектура сталкивается или с отсутствием декларируемой гибкости (много версий) в разработке, или отсутствием тестирования взаимной совместимости всех версий.
Чаще всего деплоим все зависимые сервисы вместе - основная фишка микросервисов идет мимо, или архитектор все решает, шаг в сторону - сразу по рукам.
Мне нравится ваш комментарий с точки зрения вещей, которые еще можно рассмотреть и добавить в статью, но с точки зрения критики микросервисов как таковых - это же всего лишь инструмент, который можно реализовать совершенно по разному. Логично, что у него есть свои недостатки и свои преимущества. Никто его не идеализирует (по крайней мере такой цели не стояло)
С другой стороны, я могу по пальцам пересчитать случаи, когда на последних моих двух проектах требовалось деплоить несколько сервисов одновременно из-за версионирования. Можно сказать, что для стартапов и относительно новых проектов проблема на первых этапах не так актуальна, как для зрелых проектов, но если взять какой нибудь амазон или нетфликс, у которых тоже микросервисы, так они и деплоятся независимо, и совместимость у них тестируется нормально, и брейкинг ченджес между версиями не наблюдается (вроде)
Ну и да, логично, что микросервисы независимости сами по себе не дают, но независимость это результат работы команды, а не свойство архитектуры из коробки само по себе.
Ну а зачем тогда отдельное приложение (микросервис), если его не надо отдельно деплоить? почему модули или под-системы монолита не использовать и не мучиться с проблемами микросервисов?
совместимость у них тестируется нормально
ага, да конечно. вы хоть представляете сложность тестирования ВСЕХ комбинаций ВСЕХ версий микросервисов? или у нас разное представление нормальности, или забили на совместимость И требования совместимости обеспечивает архитектор.
Единственное достоинство микросервисов, это - сложность всей системы, которая обеспечивает job security архитектору!
Все остальное можно делать модулями и плагинами, +кластер.
независимый деплой не единственная цель микросервисов. И я вам как раз как QA могу сказать, что никто никогда не будет тестировать все комбинации всех версий микросервисов :D это нереалистичный сценарий) но помимо этого он еще и избыточный, если мы налаживаем адекватные процессы и используем адекватные инструменты (как раз backward compatibility, тестирование контрактов и т.д.)
на самом деле я отчасти с вами даже согласна, потому что сейчас действительно в тренде повально юзать микросервисы там где надо и там где не надо, но говорить о том, что они не нужны в принципе, это все равно что говорить, что капельницы не нужны потому что сельские терапевты их регулярно назначают по приколу "чтобы сосудики почистить"
Соглашусь с человеком выше, статья похожа на сгенерированную нейросеткой.
В самых первых абзацах уже что-то странное:
Коммуникация упрощается - нифига! Межкомандная коммуникация намного хуже внутрикомандной. Автор никогда не работал в большой бюрократической компании. Бывает такое, чтобы заставить все работать нужно несколько раз созвониться и все проговаривать.
Тестировать как раз намного проще: у тебя есть контракты сервисов и просто описываешь в тесте все варианты.
Плохо если много связей - это не микросервисы, а распределённый монолит. Ну настолько непонимание - это жесть.
Версионирование - тут тоже особо проблем нет. Как люди версионируют библиотеки? Тот же спринг: сначала помечают depricated, потом удаляют в следующей мажорной версии. Так же и в версии апи: поддерживаешь старую и новую какое-то время, потом старую удаляешь.
И это я ещё только начал ...
На счет коммуникации - имеет место быть неоднозначная формулировка, я имела ввиду коммуникацию внутри команды одного сервиса.
На счет всего остального: мне кажется, вы описываете какую-то идеальную картинку) ну либо мы не до конца понимаем друг друга. Команда команде рознь, не в каждой команде адекватно формализуются и соблюдаются контракты. То же про версионирование - давайте смотреть правде в глаза, во-первых не каждая команда может себе позволить его нормально поддерживать, во-вторых не в каждой команде нормально выстроены процессы по его обеспечению, а магическим образом оно само, к сожалению, не настраивается
Чем предлагаете реализовать API Gateway? Неужели вручную оборачивать все вызовы?
И можно ли его заменить Ингресами Кубера?
Начало перехода на микросервисы: ship shit fast, fix later
Через пару лет:
Паттерны микросервисной архитектуры: от собеседования до прода