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

G>Ну так в любой нормальной конторе, которая переходит на микросервисы, разворачивается и система мониторинга и сбора метрик, и они постоянно анализируются, особенно на проде. Узкие места выявляются достаточно быстро. Не вижу здесь проблемы.

Система мониторинга и сбора метрик разворачивается в любом проекте, к микросервисам это отношения не имеет. У микросервисов здесь только недостаток — метрик в разы больше и их корелляции могут быть супер неожиданны. Более того, кроме метрик обязательно еще и трейсинги, без которых вполне можно обойтись на монолите.

G>А начальные ресурсы рассчитываются по такой схеме: SLA по микросервису от аналитиков и бизнеса -> разрабы делают первую сборку микросервиса -> команда НТ проводит тестирование по SLA из ТЗ и выдает заключение, на основании которого делается вывод о том, нужно ли увеличивать мощности, масштабирование или оптимизировать код чтобы уложиться в целевые SLA
G>Мне кажется, микросервисы уже достаточно зрелая технология, все такие моменты уже имеют стандартные и отработанные решения.

А где же про эти решения можно почитать? Допустим мы нагрузили, latency 50 микросервисов начало расти с разным коэффициентом геометрической прогрессии от RPS (в реальности зависимости гораздо сложнее и найти закономерности почти нереально, но пусть будет так). В разных нагрузочных сценариях эти коэффициенты разные и задействованы разные микросервисы. Бизнес месяц провел в совещаниях по планируемой нагрузке и пришел с конкретными цифрами: говорит, что система должна выдерживать миллион пользователей в день, что бы они не захотели делать на платформе.

На одном сценарии вебморда стейджа у нас ложится по таймаутам на 5к RPS, на втором на 3К, не третьем не держит и 500RPS. Какие решения нам предложит достаточно зрелая технология, как считаешь? Как найти узкие места и что именно улучшать?

Это я еще не учел всякие сюрпризы типа cache hit ratio и зависимости от конкретных данных.