p
Ну да, можно самому напилить себе лимитов.
Size: a a a
2021 July 12
D
ну это я просто, чтобы не уходить в тему обсуждения оркестраторов, потому что лимиты это функционал ОС
PD
Ограничения на создание объектов, например. Это реально не проблема.
PD
А что делает сервис, если у него память кончилась? Падает с OOM?
p
А как песочницу себе сделать в монолите? Например, у нас чувствительные данные и мы хотим запретить подсистеме аутентификации создавать tcp-соединения?
p
Как вариант. Но есть более мягкий сценарий с PSI
PD
А зачем? Разве у тебя монолит пишут враги? Ты просто не создаешь эти соединения (правда, не понятно, а в чем смысл такого ограничения для монолита...)
PD
Если падает, то какая разница, сервис или монолит?
p
Так мы должны знать сколько объект весит + каждую аллокацию обвесить проверкой "а не вылезли мы за лимиты?".
PD
Зачем? Там достаточно довольно верхнеуровневой оценки. Типа "кэшируй не более 10mln объектов".
Это все легко настраивается и конфигурируется в реальной жизни под реальный сайзинг.
Это все легко настраивается и конфигурируется в реальной жизни под реальный сайзинг.
p
Падаёт только часть, а не весь монолит. Опять же, до падения уже будет алерт по памяти(и мы сразу будем знать какой сервис), а через PSI сервис сам узнает о проблемах и может что-то с этим делать.
PD
Точно так же у тебя и для монолита будет алерт.
И какая разница, сколько упадет, если бизнес-функции встали.
И какая разница, сколько упадет, если бизнес-функции встали.
PD
Но, еще раз, в большей части проектов вообще нет таких задач, если эти задачи появляются - для них есть свои решения.
А переходить на микросервисы (со всем ростом стоимости разработки под микросервисы) только ради бюджетов - нужен очень специалный проект, мне такой даже в голову не приходит.
А переходить на микросервисы (со всем ростом стоимости разработки под микросервисы) только ради бюджетов - нужен очень специалный проект, мне такой даже в голову не приходит.
PD
Проблема распределенных транзакций обойдется в разы дороже, нежели добавить еще пару сотен гигов памяти или написать нормальные тесты )
p
Я не про кеширование, а про объекты которые создаются в нормальной жизни. Обработка 1 запроса создаёт не так много объектов, но из-за того что запросов много суммарно может оказаться что память уже кончилась. А дальше цирк в виде пейджинга(и время ответа улетает в небеса), либо OOM.
p
Разница в частичной недоступности или полной. Я ж не просто так пишу про graceful degradation. То что клиенту не покажут какой-то саджест не так страшно, как полная недоступность(потому что мы таки решили всем пришедшим показать саджесты).
PD
Ну, если запросов настолько много, что они съедят всю память (гм, не видел такого, обычно скорее в проц упираемся), то там логично думать о горизонтальном масштабировании (или просто добавить память).
PD
Еще раз, graceful degradation требует отдельного подхода к проектированию и реализации.
И да, в монолите тоже можно делать )
И да, в монолите тоже можно делать )
p
Там была проблема low latency. Т.е. если мы ответили не за 10ms, то это уже фейл.
PD
Это довольно специфические требования для системы. Это где такое было?