Как правильно построить работу с очередями/топиками брокера в транзакционной системе?

Добрый день!
Меня с моей командой схантили в новый проект, сханитили за наш успешный, четырехлетний опыт разработки для одного банка с нуля платформы с микросервисной архитектурой, в рамках которой функционирует: интернет-банкинг, электронные деньги и платежная система за разные услуги сынтегрированная с несколькими экваирингами.
По сути сейчас от нас хотят того же самого, что мы делали для банка, но есть одно но - требованиями нам заложили межсервисные вызовы через Apache Kafka. Текущий проект намного больше прошлого, транзакционная система (ответственность моей команды) составляет, примерно 1/6 от всего проекта. Другими словами у нас трудится 6 команд и транпортный уровень между сервсиами реализуется через Kafka. У нас есть опыт межсервисных вызовов только посредством HTTP. Я ничего не имею против Kafka, в целом я считаю, что это даже правильнее чем HTTP, но у нас совсем нет опыта работы ни с какми брокерами очередей вообще.

Предыстория проблемы вообще такая: сначала нам дали требования использовать rabbitMQ, который мы также не знали. Было интересно - почитали, применили, работает. Через два месяца, в команду взяли эксперта, который какими-то аргументами убедил архитектора поменять транспортный уровень на Kafka. Ну чтож, почитали, потратили неделю на переделку - работает, ничего принципиально не изменилось. Прошло еще 4 месяца и тот эксперт уволился. Фактически, сумарный штат 6-ти команд около 35 человек и никто не имеет опыта работы с брокерами сообщений.

На тестовых серверх все работает, но я боюсь выхода в продакшн. Грубо говоря транзакционная система реализована по паттерну SAGA основанной на оркестровке, т.е. есть главный сервис-оркестратор transactions и подчиненные ему сервисы, которые делятся на две группы:

1 за что производится оплата:
1.1 оплата заказа с нашего маркетплейса;
1.2 оплата заказа партнерских услуг;
1.3 оплата прочих услуг интегрированных через агрегаторы услуг, таких как QIWI;
2 чем производится оплата:
2.1 карта;
2.2 кредитом в одном из банков;
2.3 бонусами;
2.4 частично бонусами.

Каждый подпункт - это отдельный сервис или группа сервисов, на данный момент суммарно их 15 и еще несколько разработке. Сервис-оркестратор определяет "за что" и "чем" происходит оплата и делегирует ведомым сервисам. Если бы это был HTTP, то это были бы два-три обычных HTTP-запроса и все. Как же быть с Kafka? Сейчас по аналогии с HTTP у кажого свой топик на который подписан каждый сервис и в сервис-оркестратор просто в зависимости от типа платежа публикует событие в разные очереди. Пока что работает, но не лишен ли этот способ недостатков? Сейчас у меня есть мысль, о том, что я мог бы сделать одну единую очередь и подписать на нее все сервисы, к сообщению же просто добавил бы тип транзакции по которому каждый подписанный сервис понимал бы для него это сообщение или нет.

Какой из вариантов правильнее? Может оба плохие, как нужно делать?

Спасибо за помощь и советы!
  • Вопрос задан
  • 412 просмотров
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы