Comments 8
В этом случае разработчики вынуждены обращаться напрямую к другим
сервисам, пересылая запросы и получая ответы на каждом этапе вручную.
Это создает большую нагрузку на сеть и увеличивает вероятность ошибок в
связи
А каким образом заворачивание всех меж-сервисных запросов на API gateway уменьшит нагрузку на сеть или вероятность сетевых ошибок?
Зачем "уменьшить"? Увеличить куда как полезнее, с т.з. заставления бизнеса закупать овер-гигабитные сети, маршрутизаторы и супер компьютеры! Неужели Вы против Технического Прогрессу? ;)
Заодно гейтвеем очень удобно создать единую точку отказа, заведомо перегруженную по нагрузке, особенно сетевой .. упало, так сразу всё, гадать, искать, читать логи .. сразу становится лишним. ;)
Я подозреваю что здесь смешаны в кучу api gateway и кэш/graphql
Неправильный выбор технологий и стека в микросервисной архитектуре может стать причиной множества проблем, которые будут затруднять разработку проекта и его поддержку в дальнейшем
Неправильный выбор технологий и стека станет причиной множества проблем при практически любой архитектуре, не только микросервисной
К сожалению время идёт и наблюдается перетекание качества в количество. Количество растёт, а вот качество.
Как известно, микросервисная архитектура позволяет разбивать приложения на более мелкие и управляемые блоки.
Ребят, ну вы серьёзно? Вы же вроде как курсы IT, должны же знать - вся история программирования есть разные способы разбиения приложения на более мелкие и управляемые блоки. Функции, подпрограммы, библиотеки, объекты, модули, программы, тысячи их. И нет, микросервисная архитектура не предлагает новых способов разбиенич приложения на более мелкие и управляемые блоки - просто использует существующие . Ну разве что затрудняет переиспользование.
Вроде же большая, уважаемая контора, с высоким рейтингом на хабре, вроде как обучающая людей, ну как же такое писать то можно.
Ну в конце то концов, несмотря на всю мою лютую, дикую ненависть к микросервисам, ну ведь у них тоже есть своя область применение, полезные свойства. Возможность быстрее делать апдейт маленького сервиса большого приложения (обычно не особо нужно, ну если, конечно у вас не монстр, стартующий два часа. И не работает на практике потому что в апдейт чаще выкатывают кучу микросервисов). Самое главное - независимость сервисов - делай свои сервисы так, чтоб они продолжали работать даже когда родительский микросервис недоступен - позволяет не растерять всех пользователей, когда что-то накрылось - типа что-то накрылось, но что-то ещё продолжает работать. Возможность гибко масштабироваться (обычно не нужно - load balancer-а обычно более чем достаточно). Решить проблему с нехваткой физических ресурсов (CPU, Memory). Но интернет-магазин, если это не озон-амазон в качестве примера - ну ё-маё. Всё равно, что использовать NoSQL просто для фана - ну и что, что одна нода, зато есть возможность масштабироваться, когда-нибудь.
Ну зайдите с другой стороны. "Когда вам придётся работать с заказчиком, который ничего не понимает в IT, то слова микросервис и k8s будут его сильно возбуждать - даже в баню везти не придётся. И сразу станет понятно почему под проект надо так много железна - кластер же, отказоустойчивость, микросервисы. И сразу станет не так важно, что мы просим за проект в 10 раз больше, чем нужно - на железо придётся потратиться ещё в 10 раз больше, так что всё обосновано, всё норм."
Вот уже прошли сезоны хайпа на orb, sql, xml, rest, docker - всё прошло и заняло своё место. А "микросервисы - это наша серебряная пуля" продолжает жить. "У нас всё очень современно. Java17, spring boot, микросервисы, k8s, scram, agile". "А почему к вас микросервисы? Да хз, консультант сказал - пилите микросервисы, монолит уже не модно".
Такое чувство, будто это сгенерированная статья. Пора заводить тег "сгенерировано ИИ".
Честно говоря, определение MSA спорное) А главная проблема MSA, на мой взгляд, - пихать ее во все места. Не понимая области применимости, плюсов минусов, которые она несет ) И ни логированием хорошим, ни api gateway'ем этого не решить как ни старайся)
Проблемы при реализации микросервисной архитектуры