Здравствуйте, scf, Вы писали:

scf>Здравствуйте, itslave, Вы писали:

scf>Первые три сценария — очереди используются там и только там, где обработка запроса может занимать неприличное (больше 1 минуты) время.
выносить в бекенд операции, которые выполняются милисекунды... наверное бывают такие кейсы, но в общем случае
это не нужно имха, даже с микросервисами.

scf>Четвертый сценарий — проблемы менеджмента и технологического стека.
Но esb порешал же с минимальными усилиями. Налаживать процессы. было бы больно, дорого и не факт что получилось бы.
scf> Микросервисы без единой системы логгирования и трассировки просто не взлетят, умение писать и поддерживать стабильное сетевое API тоже обязательно.
И полностью автоматизированный деплоймент. IaaC.
scf>Я так понял, у вас малонагруженные системы, где хранилища никогда не переполняются, а ресурсов всегда хватит, чтобы обработать запрос вовремя.
Все в мире относительно — десчтки(в пике сотни) тысяч конкурентных сессий система держит и все хорошо.


cf> В высоконагруженных системах всё не так — при отказе консумера очередь может переполниться за несколько минут, периодически кончается место на диске, одна из машин в кластере может "заболеть" непредсказуемым образом — от выключения до длительного раздумия над каждым запросом, ресурсов периодически не хватает для обработки всех запросов от клиентов.
Опять таки, все относительно. Я с трудом представляю что надо сделать, чтобы забить амазоновский sqs. Мониторинг, автоматическое масштабирование групп серверов, деплоймент всей стстемы в другой регион(и даже к другому клаудному провайдеру при первых признаках жопы решают огромное кол-во сценариев.


scf>В таких системах очереди нужно использовать очень осторожно, т.к. они передают данные в одном направлении, не позволяя консумеру предупредить паблишера о потенциальных проблемах в системе.
Опять таки, почему нотификация паблишера о проблемах — это задача консьюмера, а не мониторинга?