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

Добрый день!
Меня с моей командой схантили в новый проект, сханитили за наш успешный, четырехлетний опыт разработки для одного банка с нуля платформы с микросервисной архитектурой, в рамках которой функционирует: интернет-банкинг, электронные деньги и платежная система за разные услуги сынтегрированная с несколькими экваирингами.
По сути сейчас от нас хотят того же самого, что мы делали для банка, но есть одно но - требованиями нам заложили межсервисные вызовы через 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 у кажого свой топик на который подписан каждый сервис и в сервис-оркестратор просто в зависимости от типа платежа публикует событие в разные очереди. Пока что работает, но не лишен ли этот способ недостатков? Сейчас у меня есть мысль, о том, что я мог бы сделать одну единую очередь и подписать на нее все сервисы, к сообщению же просто добавил бы тип транзакции по которому каждый подписанный сервис понимал бы для него это сообщение или нет.

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

Спасибо за помощь и советы!
  • Вопрос задан
  • 602 просмотра
Решения вопроса 1
@ksimmi Автор вопроса
Решил сам ответить на ворос. Управление сервисами построено по паттерну SAGA основаному на оркестрации, сервис реализующий сагу имеет ИНДИВИДУАЛЬНЫЙ командный канал к каждому сервису-участнику саги, и ОБЩИЙ канал с ответами от них же.

Спасибо всем учавствовшим в обсуждении.

Zhainar
Спасибо за отсылку к книге Криса Ричардсона, я ее прочел всю. Было очень полезно, стал лучше понимать паттерн SAGA, ответ и помощь нашел в книге.

SirotaKazansky
То, что я называл "частым нарушением согласованности" по Крису Ричардсону называется "отложенной согласованностью". Это состояние, когда каждый сервис сам по себе находится в согласованном состоянии, но система в целом может быть в процессе установления этой согласованности. Специалист второй линии поддержки, о котором я говорил ранее, в случае возникновения ситуцаии когда система по какой-то причине не выходит из отложеной согласованости, после анализа этой ситуации просто перезапускает конкретный шаг саги или же иницирует ее отмену запуская компенсирующие транзакции.
Ответ написан
Комментировать
Пригласить эксперта
Ваш ответ на вопрос

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

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