Comments 12
ты опоздал лет так на 7 точно со статьей
Можно построить кластерный монолит, где каждая нода имеет полную независимость и запросы распределяются через балансировщик нагрузки. Тогда нет необходимости иметь сложную микросервисную архитектуру. Сильно упрощает деплоймент и поддержку.
А если какой-то сервис в монолите роняет все приложение? Микросервисы сложнее, но явно надежнее. Плюс, если какое-то узкое место начинает нагружаться - добавили инстанс этого сервиса и уже красота, а поднимать еще один монолит такое себе..
Так монолитов несколько. Один упал, остальные бегут.
И остальные упадут, т.к. инстансы одного и того же монолита, значит ошибка будет во всех. Скажем ошибка возникает при дергании какого-то эндпоинта, пока монолит не пересоберут с исправлением - ошибка будет в нем сидеть
А если такая же ошибка в микросервисе, то они тоже будут падать и вся система перестанет нормально работать. У нас такая монолитно-кластерная архитектура работает уже лет десять и, в нескольких случаях, когда падала система, это были проблемы с сетесетевым оборудованием.
Если падает микросервис - перестаёт работать часть системы. Если падает монолит - падает все) но все это конечно примеры высосанные из пальца, просто как по мне мс более надёжный, хоть и разрабатывать сложнее)
Вполне возможно, хотя опять-же говорю только со своего опыта, поддержка монолитов намного проще для компаний с ограниченными ресурсами поддержки. Наша система обслуживает параллельно около 2х тысяч работников службы поддержки крупного оператора кабельного ТВ и, ежедневно опрашивает около 4 миллионов приставок на предмет диагностики. Всё бежит на двух физических серверах разбитых на 8 виртуалок. При апгрейде только один инстанс перегружается и система всегда доступна.
По-моему аннотация сервисов @EnableEurekaClientнынче не актуальна. Поправьте если я не прав.
Микросервисы сына маминой подруги. Пишем правильные микросервисные приложения на Java