Вначале был монолит: как мы меняем нашу архитектуру, не мешая бизнесу

[mixsture]

Про задачу с курьерами замечу, что на скорость тут влияет совсем не архитектура монолит vs микросервисы. Вы по своей сути сделали управляемый кэш поближе к клиенту. Это даст ускорение на любой архитектуре — в монолите тоже бы дало ускорение :)

[Rigorbb]

Все так, а пример был больше про потоки данных, не про сервисы ;)

[sergey_shambir]

Спасибо за статью, хотелось бы ещё узнать

• Почему решили с MySQL переходить на PostgreSQL? Были ли трудности при внедрении в новых сервисах PostgreSQL?
• Запись в микросервис, абстрагирующий Kafka, выполняется напрямую или через базу и Transactional Outbox?
• Базы данных и Kafka развёрнуты вне Kubernetes? Есть ли ситуации, когда одна машина с инстансами БД или один инстанс БД с разными database используется несколькими микросервисами?

[Rigorbb]

Привет!

1) В основном используем Postgres, так как он в большинстве случаев лучше подходит под наши условия — со сложными запросами на больших и часто меняющихся данных он все же быстрее mysql. Но, конечно, для большинства наших сервисов в целом разницы особо нет, но чтобы не городить зоопарк технологий, взяли его за стандарт для всех новых сервисов.

2) Запись идет напрямую: продюсеры пишут через HTTP API, а консумеры подключается к брокерам напрямую, но используют для этого инструменты обертки, которые валидируют сообщение. Я думаю, у нас еще будет подробная статья на эту тему.

3) Все стораджи у нас вне Kubernetes. По второй части вопроса не совсем понял, у нас используются оба подхода, в зависимости от нагрузки.

[maxim_ge]

Интересно было бы узнать, хотя бы в первом приближении, каков поток запросов (RPS), какие требования по latency.

И такой вопрос, микросервисов у вас 162, в качестве системы оркестровки используется kubernetes, а сколько кластеров?

[Rigorbb]

RPS на разные части системы разные: например, на микросервисы, отвечающие за бэкофис ресторанов нагрузка небольшая(речь идет о десятках-сотнях RPS), но на клиентские сервисы она существенна, речь уже о тысячах RPS.

Сейчас наш прод 50/50 заехал в Kubernetes, до конца года планируем заехать полностью. Кластер у нас один.

[Frintezza93]

Мастер данных этого домена продюсит всю сущность в стрим, а сервисы аккумулируют нужные части.

Вот тут получается мне лично не понятен момент — как изменения попадают в мастер? Потому что если много сервисов потребителей сущности, то возможно появление, как минимум, нескольких сервисов «обновителей» сущности. Получается трейдофф — вы либо пишите из разных мест в мастер (что размазывает логику работы с сущностью), либо поднимаете обёртку в виде сервиса (которая становится узким местом и от которой всё зависит), либо…
Сам когда то столкнулся с такой проблемой, но хорошего решения не нашёл.

[Rigorbb]

Привет, спасибо за интересный вопрос. Мне кажется, здесь важно то, что мы вкладываем в понятие мастера данных — насколько ему нужно собирать все изменения со всех частей системы, которые работают с его доменом? Например, если взять заказ: есть сервис мастер данных по заказам и есть сервисы логистики, которые тоже работают с заказом. В сервисах логистики заказ обогащается очень многими специфическими данными, например, внутренние статусы доставки и обработки заказа. Но нужно ли знать об этих данных мастеру? Кажется, что нет — ему нужно сообщить скорее конкретные промежуточные и финальные результаты. Да, логика работы размазывается, но размазывается по четким логически отделенным частям, которые мастеру сообщают точечные конкретные результаты, которые не вносят усложнения в общую логику.

[erebmaethor]

Добрый вечер.

Расскажите, пожалуйста, кто отвечает за поиск и исправление багов в уже эксплуатирующемся микросервисе? Команда эксплуатации, какая-то выделенная команда починки багов, или те разработчики, которые его создавали? Если те, кто создавал, то как долго они продолжают поддерживать этот сервис после передачи в боевую эксплуатацию?

[Rigorbb]

Привет! У каждого сервиса есть техлид, который за него ответственен. Если в сервисе замечена какая-то неточность, то как правильно ее фикс идет в беклог команды техлида, либо в ту команду, которая ответственна за функционал, где он обнаружился.