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

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

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

Ну так трейсинг же из коробки делается, библиотеками типа sleuth, zipkin, там тебе даже фронт готовый есть для анализа трейсов. Просто юзай трейсы и наслаждайся.

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

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

>А где же про эти решения можно почитать? — например в книгах и статьях про Spring Cloud, про реактивный подход или про современные паттерны отказоустойчивости. Также есть статьи и блоги про стек нетфликса, нетфликс как раз одна из компаний, которая многие такие вещи придумала и внедрила, т.к. столкнулась с большой нагрузкой на микросервисы.

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

Какая технология? Ну так реактивщину придумал и для этих задач (повышение перформанса) + паттерны отказоустойчивости (например, из библиотеки resilience). В частности, если у вас кто-то ложится по таймаутам, реализуйте паттерны Circuit Breaker и Bulkhead (https://sysout.ru/otkazoustojchivost-mikroservisov-shablon-circuit-breaker/). Это позволит проблемному микросервису обслуживать больший спектр запросов, а не ложиться от нагрузки на однотипных запросах. Спектр можно распределить по разным параметрам, например по конкретным эндпоинтам.
Как найти узкие места — анализ метрик, прогон микросервиса с профайлером. Тут уже всё упирается к компетенции разрабов. С монолитом точно так же приходится анализировать перформанс, только вот в монолите бывает тяжело провести оптимизацию, если она упирается в монолитную природу. Не раз с этим сталкивался, т.е. проводим анализ перформанса профалингом, находим узкие места в монолите, но понимаем, что проще вынести точки нагрузки в отдельные микросервисы на физические узлы, чем заниматься миллионом микро-оптимизаций монолита, которые все равно не гарантируют что узкое место будет устранено. А при выносе точки нагрузки в микросервис можно просто написать код без этих оптимизационных заморочек, что выйдет дешевле и быстрее.

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

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

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

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

Ну так трейсинг же из коробки делается, библиотеками типа sleuth, zipkin, там тебе даже фронт готовый есть для анализа трейсов. Просто юзай трейсы и наслаждайся.

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

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

>А где же про эти решения можно почитать? — например в книгах и статьях про Spring Cloud, про реактивный подход или про современные паттерны отказоустойчивости. Также есть статьи и блоги про стек нетфликса, нетфликс как раз одна из компаний, которая многие такие вещи придумала и внедрила, т.к. столкнулась с большой нагрузкой на микросервисы.

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

Какая технология? Ну так реактивщину придумал и для этих задач (повышение перформанса) + паттерны отказоустойчивости (например, из библиотеки resilience). В частности, если у вас кто-то ложится по таймаутам, реализуйте паттерны Circuit Breaker и Bulkhead (https://sysout.ru/otkazoustojchivost-mikroservisov-shablon-circuit-breaker/). Это позволит проблемному микросервису обслуживать больший спектр запросов, а не ложиться от нагрузки на однотипных запросах. Спектр можно распределить по разным параметрам, например по конкретным эндпоинтам.
Как найти узкие места — анализ метрик, прогон микросервиса с профайлером. Тут уже всё упирается к компетенции разрабов. С монолитом точно так же приходится анализировать перформанс, только вот в монолите бывает тяжело провести оптимизацию, если она упирается в монолитную природу. Не раз с этим сталкивался, т.е. проводим анализ перформанса профалингом, находим узкие места в монолите, но понимаем, что проще вынести точки нагрузки в отдельные микросервисы на физические узлы, чем заниматься миллионом микро-оптимизаций монолита, которые все равно не гарантируют что узкое место будет устранено. А при выносе точки нагрузки в микросервис можно просто написать код без этих оптимизационных заморочек, что выйдет дешевле и быстрее.

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

Я не спорю, что задачи при разработке микросервисов непростые. Но моё мнение, что с монолитом эти задачи решать намного тяжелее.