Я использую Spring Boot 2.1.4, Kafka и React в качестве пользовательского интерфейса. У меня есть процесс регистрации пользователя из пользовательского интерфейса, для которого требуется серверный процесс и его данные до завершения регистрации.
Поток такой:
Я хочу, чтобы пользовательский интерфейс внешнего интерфейса делал первоначальный запрос API, который возвращался немедленно, показывал экран загрузки и отображал готовое сообщение, когда процесс регистрации завершен.
Я подумал о паре вариантов:
Прикрепите KafkaListener к очереди ответов. После появления ответного сообщения сохраните ответ и токен в хранилище данных (например, Redis). Предоставьте API для пользовательского интерфейса, который проверяет хранилище данных на наличие токена. Пользовательский интерфейс будет опрашивать этот API каждые 10 секунд. Если ответ недоступен через 2 минуты, пользователю будет предложено вернуться позже.
Используйте веб-сокеты с React. Я раньше не использовал WebSockets, но единственное, в чем я не уверен, так это в том, что если у меня есть несколько экземпляров микрослужбы регистрации, вызовет ли это какие-либо проблемы со связью клиент/API.
Любые рекомендации или любые другие варианты наилучшего способа справиться с этим?





- Attach a KafkaListener to the reply queue. Once the reply message appears, store the response and token in a datastore (e.g. Redis). Provide an API to the UI which checks the datastore for the token. The UI will poll this API every 10 seconds. If the response is not available after 2 mins, the user will be asked to check back later.
Это сработает. Я бы использовал встроенную RocksDB для хранения, просто для простоты. Ниже приведена документация по предоставлению доступа к хранилищу состояний вне потоков kafka.
https://kafka.apache.org/20/documentation/streams/developer-guide/interactive-queries.html
- Use WebSockets with React. I've not used WebSockets before but the only thing I'm unsure of is if I have multiple instances of the registration microservice, will this cause any issues with client/api communication.
Это потенциально может вызвать проблемы. Это зависит от реализации службы регистрации. Вы не будете знать, с каким экземпляром службы регистрации будет устанавливать соединение клиент. Например, сеансом необходимо управлять во внешнем источнике данных, таком как Redis, или вам придется использовать балансировщик laod, который поддерживает липкие сеансы (немного архаичное решение).
Большое спасибо за вашу помощь. Я думал, что веб-сокеты выглядят многообещающе, но я хочу, чтобы архитектура оставалась без гражданства, насколько это возможно.