RPS на разные части системы разные: например, на микросервисы, отвечающие за бэкофис ресторанов нагрузка небольшая(речь идет о десятках-сотнях RPS), но на клиентские сервисы она существенна, речь уже о тысячах RPS.
Сейчас наш прод 50/50 заехал в Kubernetes, до конца года планируем заехать полностью. Кластер у нас один.
1) В основном используем Postgres, так как он в большинстве случаев лучше подходит под наши условия — со сложными запросами на больших и часто меняющихся данных он все же быстрее mysql. Но, конечно, для большинства наших сервисов в целом разницы особо нет, но чтобы не городить зоопарк технологий, взяли его за стандарт для всех новых сервисов.
2) Запись идет напрямую: продюсеры пишут через HTTP API, а консумеры подключается к брокерам напрямую, но используют для этого инструменты обертки, которые валидируют сообщение. Я думаю, у нас еще будет подробная статья на эту тему.
3) Все стораджи у нас вне Kubernetes. По второй части вопроса не совсем понял, у нас используются оба подхода, в зависимости от нагрузки.
Привет! У каждого сервиса есть техлид, который за него ответственен. Если в сервисе замечена какая-то неточность, то как правильно ее фикс идет в беклог команды техлида, либо в ту команду, которая ответственна за функционал, где он обнаружился.
Привет, спасибо за интересный вопрос. Мне кажется, здесь важно то, что мы вкладываем в понятие мастера данных — насколько ему нужно собирать все изменения со всех частей системы, которые работают с его доменом? Например, если взять заказ: есть сервис мастер данных по заказам и есть сервисы логистики, которые тоже работают с заказом. В сервисах логистики заказ обогащается очень многими специфическими данными, например, внутренние статусы доставки и обработки заказа. Но нужно ли знать об этих данных мастеру? Кажется, что нет — ему нужно сообщить скорее конкретные промежуточные и финальные результаты. Да, логика работы размазывается, но размазывается по четким логически отделенным частям, которые мастеру сообщают точечные конкретные результаты, которые не вносят усложнения в общую логику.
Сейчас наш прод 50/50 заехал в Kubernetes, до конца года планируем заехать полностью. Кластер у нас один.
1) В основном используем Postgres, так как он в большинстве случаев лучше подходит под наши условия — со сложными запросами на больших и часто меняющихся данных он все же быстрее mysql. Но, конечно, для большинства наших сервисов в целом разницы особо нет, но чтобы не городить зоопарк технологий, взяли его за стандарт для всех новых сервисов.
2) Запись идет напрямую: продюсеры пишут через HTTP API, а консумеры подключается к брокерам напрямую, но используют для этого инструменты обертки, которые валидируют сообщение. Я думаю, у нас еще будет подробная статья на эту тему.
3) Все стораджи у нас вне Kubernetes. По второй части вопроса не совсем понял, у нас используются оба подхода, в зависимости от нагрузки.