Как организовать работу микросервисов в kafka?

Question

[Danya Kozlovskiy]

Здравствуйте. Есть три сервиса, которые грубо говоря реализуют интернет-магазин:
1. Принимает запрос и отправляет его в kafka.
2.Читает из kafka и отвечает за товары.
3. Читает из kafka и отвечает за кошелек пользователя.
То есть когда запрос с количеством и наименованием нужных пользователю товаров поступает на сервис 1, то мы идём в сервис 3 берем информацию о товарах отправляем их в сервис 2 и в нём уже снимаем деньги у пользователя, а в заключении отвечаем сервису 1 о результате.
Появились вопросы насчет организации работы сервисов:
1. Необходима ли тут синхронизировать работу сервисов (т.е. выполнять запросы поочередно), ибо возможна ситуация когда пользователи одновременно покупают товар, а на складе его хватает только для одного пользователя? И если да, то как это реализовать?
2. Правильно ли я построил алгоритм общения между сервисами описанный выше?
P.S.: С микросервисной архитектурой и кафкой знаком мало.

Comments

[d'Ivan]

А зачем здесь Kafka? Какое имеет преимущество при написании интернет-магазина?

[d'Ivan]

Andrei Brizhak, я боюсь, что автор не до конца понимает во что выльется такая архитектура. Очереди нужно использовать не где попало, а когда в этом есть необходимость. И Kafka, уж точно, будет вишенкой на торте.

Answer 1

[d'Ivan]

Почему Kafka? Почему микросервисы?

1. Принимает запрос и отправляет его в kafka.

От кого принимает и каким образом? Какой выдается ответ и каким образом?
Нужно разделить интернет-магазин на логические части. Проверить какие запросы могут обслуживаться синхронно, а какие - отложенно (асинхронно).
Когда на складе остается мало товара, пользователь должен знать об этом. Еще можно показывать наличие товара только если имеется свыше X единиц. А с точки зрения СУБД можно применить оптимистическую блокировку записи.

Answer 2

[Александр]

Мне видится, что правильнее информацию о остатке товара хранить в отдельном сервисе. Пусть это будет сервис 2 А кошелёк и оплату вместе-сервис 3 Так схема будет такой:
1. Сервис 1 получает запрос
2. Сервис 1 идет к сервису 2 за информацией есть ли запрошенный товар и если он есть то "резервирует" его.
3. Сервис 1 отправляет сервису 3 информацию для оформления оплаты.
4. Если оплата успешна (у пользователя достаточно средств и платёжная система отработала без ошибок) то сервис 1 "подтверждает резерв" товара через сервис 2. В противном случае сервис 1 "возвращает резерв" сервису 2. Резервированый товар не показывается при показе остатков другим пользователям.
Такая схема напоминает паттерн распределённой транзакции с двух-разным комитом. Поситайте про него. В данном случае использовать Кафку или нет большого значения не имеет, т к кафка-это только канал связи. Все те же самые манипуляции придётся проводить и при использовании обычного рест апи.
Если же делать синхронно, то в сервисе 1 операции станут последовательными, и микросервисная организация теряет смысл, т к это будет медленнее чем монолит и не масштабируемо. Но для такого усложнения должны быть объективные причины - высокая нагрузка. Если же еë нет то монолит проще и дешевле.

Comments

[Danya Kozlovskiy]

Александр, спасибо огромное за ответ, расписал ниже примерную логику и формат сообщений между сервисами (надеюсь правильно), но возник вопрос как лучше хранить\получить промежуточную информацию ( как и где опять получить список тех товаров которым хотим подтвердить резервирование ( шаг 6 ) ) если использовать kafka и асинхронность?
1. Запрос приходит в 1. {username: user, tovars: [{tovar1:2, tovar2:3}]}
2. 1 проверяет наличие товара и резервирует в 2. {message: {tovars: [{tovar1: 2},{tovar2: 3}]}}
3. 2 отвечает о результате в 1. {message: {total: 500, username: user}}
4. 1 изменяет баланс в 3. {message: {total: 500, username: user}}
5. 3 отвечает о результате в 1. {message: ok}
6. 1 подтверждает резервирование в 2. {message: {tovars: [{tovar1:2},{tovar2:3}]}}
7. 2 отвечает о результате в 1. {message: ok}

[Александр]

как и где опять получить список тех товаров которым хотим подтвердить резервирование ( шаг 6 )

Не совсем понимаю вопрос. У сервиса 1 этот список уже есть. Он ему пришел в п.1 и может полежать в памяти пока (вообще в переменной т к у сервиса 1 это неразрывный поток.

надеюсь правильно

В целом да, но на шаге 2 в сервисе 2 нужно создать сущность "резерв" куда и записать все зарезервированные товары. А вернуть её айдишник. Соответственно, на шаге 6 вместо списка товаров передать Id этой сущности. И сервис 2 может на этом шаге её удалить (или если была отмена резерва, вернуть товары из резерва обратно на склад и затем удалить резервирование) Где и как хранить эту сущность - детали реализации. Самое простое в той же БД где и остатки по товарам. Но если не в той же то опять же надо какой-то механизм что бы создание резерва и уменьшение количества товара производились как атомарная операция вместе.

[Danya Kozlovskiy]

Александр,

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

В целом да, но на шаге 2 в сервисе 2 нужно создать сущность "резерв" куда и записать все зарезервированные товары. А вернуть её айдишник. Соответственно, на шаге 6 вместо списка товаров передать Id этой сущности. И сервис 2 может на этом шаге её удалить (или если была отмена резерва, вернуть товары из резерва обратно на склад и затем удалить резервирование) Где и как хранить эту сущность - детали реализации. Самое простое в той же БД где и остатки по товарам. Но если не в той же то опять же надо какой-то механизм что бы создание резерва и уменьшение количества товара производились как атомарная операция вместе.

Спасибо большое, что поправили. Да подразумевается, что всё хранится в БД.

[Александр]

если допустим сервис один сохранит у себя в локальной памяти, а из кафки сообщение о подтверждении резерва прочитает второй поднятый первый сервис

Тут вам либо придется как то настроить кафку так, что бы из неё читал эти сообщения тот сервис который изначально делал резерв либо читать всеми инстансами и дальше уже разбирать. Насколько мне известно о kafka, то там можно сделать так, что бы сообщение получили все подписчики. Дальше можно извлечь из него id резерва и понять (сравнив с тем что в памяти), нужно его дальше обрабатывать этому инстансу или бросить. Если планируется прям очень большая нагрузка и прям куча инстансов, то наверное можно и другие схемы придумать. Например, если количество инстансов известно на этапе деплоя и не меняется в процессе работы, то можно для каждого завести свой топик в кафке. Но в кафка я не спец, поэтому с этим вопросом можно написать в тег "kafka". Он тут точно есть где то.