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

Question

[lookingfor2]

Есть приложение клиент и два микросервиса: микросервис по выплатам, микросервис по формированию чеков.

Когда пользователь запросил вывод средств, приложение клиент делает запрос к микросервису по выплатам, тот в свою очередь в банк.
Как только я узнаю что транзакция закончилась успехом, должен поменять статус транзакции в основном приложении и сделать запрос в микросервис формирования чеков.

Хотелось бы понять какой стиль взаимодействия нужно использовать между клиентом и сервисами, какой более правильно выбрать коммуникационный протокол.
На данный момент, думаю использовать rabbitmq.

Насколько правильно было бы реализовать такой алгоритм?

Микросервис платежей слушает топик payment.create.command.
Приложение клиент слушает payment.success.command, payment.fail.command
Микросервис формирования чеков слушает payment.created.command

- В микросервис платежей приходит нагрузка из клиента, формируем guid транзакции и возвращаем его клиенту, клиент сохраняет его, в этот момент начинаем опрашивать банк
- В случае успеха из микросервиса платежей передаем сообщение в клиент(payment.success.command) и микросервис формирования чеков(payment.created.command).

Если использовать gRPC
Клиент делает запрос в микросервис платежей, после c задержкой опрашивает статус, в случае успеха делает запрос в микросервис по формированию чеков.

Как более верно это все сделать?

Comments

[Maksim B]

Я бы выбрал RabbitMQ, для таких целей он в принципе и был создан.

[Василий Банников]

Клиент делает запрос в микросервис платежей, после c задержкой опрашивает статус, в случае успеха делает запрос в микросервис по формированию чеков.

Вот это уже настораживает и наводит на мысль, что тут скорее подойдёт асинхронное взаимодействие через реббит.

[d'Ivan]

после c задержкой опрашивает статус

Нужно прояснить что за задержка: по окончанию чего-то, либо спустя 3 часа либо в 9 вечера.

[lookingfor2]

Капитан Пронин, задержка на формирование подписи запроса для банка и ожидания ответа от банка, обычно не больше 20 секунд

Answer 1

[Вадим]

Смотрите - вы должны смотреть на требования бизнеса. Те процессы, которые не требуют немедленного подтверждения могут быть сделаны через мессаж брокер, типа Кролика или Кафки (лучше имхо). Остальные могут быть сделаны через обычный http(s) протокол - советую через ssl, тк у вас серьезные данные. Теперь как выбирать прямое взаимодействие между сервисами по https? Я советую использовать какой-либо API Gateway со своим - внутреннем доменом и все взаимодействие между сервисами вести через него, а не напрямую внутри кластера K8S или Docker Swarm итд. Получается гораздо более организованно. Не знаю, нужно ли вам gRPC, по-моему и разрабам и девопсам легче будет работать со старым добрым http для устранения неполадок и tracinga.

После окончания дизайна проводите what-if анализ с ведущими разрабами и админом бд. А что если сообщение потерялось, брокер или база перегружена, или сеть отказала в соединении... как откатить деньги обратно итд. Все надо серьезно со всех сторон продумать! После этого вносите изменения в систему.

На всем протяжении одного длинного действия создавайте transaction_id, которое будет распространятся по системе, включая сообщения Кролика/Кафки и записи в базе, чтобы можно было легко его найти в логах или восстановить, если где-то произошла проблема.

Comments

[lookingfor2]

Спасибо!

[lookingfor2]

А почему по вашему мнению кафка лучше бы подошла для этой задачи ?

[Вадим]

lookingfor2, она быстрее доставляет сообщения и работает с большим количеством параллельных отправок.

[Вадим]

Из API Gateway самый удобный Traefik, - игрался с ним. Но мы используем платное частное решение.

[d'Ivan]

lookingfor2,

Вообще, надо отталкиваться от требуемой (достаточной, с учётом некоторой избыточности) скорости обработки количества сообщений в секунду. Она известна?

Сравнение:
https://www.cloudamqp.com/blog/when-to-use-rabbitm...