Фон:
Я создаю приложение, и предлагаемая архитектура - Event/Message Driven на архитектуре микросервиса.
Монолитный способ делать то, что у меня есть User/HTTP request
и который выполняет некоторые команды, которые имеют прямой synchronous response
. Таким образом, для ответа на один и тот же запрос User/HTTP "бесполезно".
Эта проблема:
Пользователь отправляет HTTP request
в службу пользовательского интерфейса (имеется несколько служб пользовательского интерфейса), который запускает некоторые события в очередь (Kafka/RabbitMQ/any). N служб выбирает, что событие/сообщение совершают какое-то волшебство на этом пути, а затем в какой-то момент тот же UI-сервис должен выбрать ответ и вернуть его пользователю, который инициировал HTTP-запрос. Обработка запроса - это ASYNC
но User/HTTP REQUEST->RESPONSE
- SYNC
в соответствии с вашим типичным взаимодействием HTTP.
Вопрос. Как отправить ответ на ту же службу пользовательского интерфейса, которая инициировала действие (служба, взаимодействующая с пользователем через HTTP) в этом мире, управляемом агностиками?
Мои исследования до сих пор я оглядывался, и кажется, что некоторые люди решают эту проблему с помощью WebSockets.
Но уровень сложности заключается в том, что должна быть какая-то таблица, которая отображает (RequestId->Websocket(Client-Server))
который используется для "обнаружения того, какой узел на шлюзе имеет соединение с веб-сайтами для определенного ответа. Но даже если я понимаю проблему и сложность, я застрял, что не могу найти статей, которые бы дали мне информацию о том, как решить эту проблему на уровне реализации. И это все еще не является жизнеспособным вариантом из-за сторонних интеграций, таких как поставщики платежей (WorldPay), которые ожидают REQUEST->RESPONSE
- специально для проверки 3DS.
Поэтому я не хочу думать, что WebSockets - это вариант. Но даже если WebSockets подходят для приложений Webfacing, API, который подключается к внешним системам, не является отличной архитектурой.
** ** ** Обновление: ** ** **
Даже если длительный опрос является возможным решением для API WebService с Location header
202 Accepted
a Location header
retry-after header
он не будет работать для веб-сайта с высокой совместимостью и высокой способностью. Представьте себе огромное количество людей, пытающихся получить обновление состояния транзакции на каждом запросе, которое они делают, и вы должны аннулировать кеш CDN (идите и играйте с этой проблемой сейчас! Ha).
Но самое важное и относимое к моему делу. У меня есть сторонние API, такие как платежные системы, в которых системы 3DS имеют автоматические переадресации, которые обрабатываются системой поставщиков платежей, и они ожидают типичного REQUEST/RESPONSE flow
, поэтому эта модель не будет работать для меня или модель сокетов будут работать.
Из-за этого варианта использования HTTP REQUEST/RESPONSE
следует обрабатывать в типичном режиме, когда у меня есть немой клиент, который ожидает, что сложность прецессии будет обработана в фоновом режиме.
Поэтому я ищу решение, где извне у меня есть типичный REQUEST->Response
(SYNC) и сложность состояния (ASYNCrony системы) обрабатывается внутренне
Пример длинного опроса, но эта модель не будет работать для стороннего API, такого как поставщик платежей по 3DS Redirects
, которые не входят в мой контроль.
POST /user
Payload {userdata}
RETURNs:
HTTP/1.1 202 Accepted
Content-Type: application/json; charset=utf-8
Date: Mon, 27 Nov 2018 17:25:55 GMT
Location: https://mydomain/user/transaction/status/:transaction_id
Retry-After: 10
GET
https://mydomain/user/transaction/status/:transaction_id