Как мне поймать ответ на запрос, а потом что-то выполнить?

Question

У меня есть приложение, в котором у меня есть конечная точка, где запрос отправляется другой службой для сбора запросов от моего приложения к этой службе. Затем эта служба выполняет запросы и отправляет мне ответы на другую конечную точку.

Предположим, у меня есть конечная точка ( api/get_cost), по которому мы предоставляем заказчику информацию о стоимости. Мы получаем информацию о стоимости только из другого сервиса. Поэтому, прежде чем отвечать пользователю, я должен создать запрос информации о стоимости, получить ответ и только затем ответить пользователю. Как лучше всего это сделать с архитектурной точки зрения?

Answer 1

Я думаю, вы можете сделать две вещи.

Давайте упростим это. У вас есть 2 компонента в данном сценарии использования.

Клиент (пользователь) U1 - (хочет получить информацию о расходах, используя )-> B1(ваш внутренний сервер) ---> C1 (сторонний сервер API)

Подход 1:

В этом сценарии вы можете создать службу в своей папке lib, в которой будет клиент, который будет отвечать за выполнение вызовов api, и службу в качестве интерфейса, через который вы будете предоставлять методы для выполнения вызовов api от B1 к C1.

Итак, вы будете использовать методы службы для выполнения вызовов API к C1.

Удачным случаем будет:U1 запрашивает информацию о стоимости от B1 -> B1 запрашивает C1-> C1 отвечает данными -> B1 отвечает данными на U1

Что может пойти не так:

U1 -> B1 -> C1 (но сервер U1 не работает) -> (время ожидания истекло) -> возвращается к B1 -> B1 выдает ошибку U1.

U1 -> B1 -> C1 (C1 требуется много времени, чтобы дать ответ) -> отвечает данными на B1-> B1 возвращает данные обратно на C1

Итак, чтобы было надежнее.

• Добавьте тайм-аут при вызове B1 -> C1, чтобы, если данные не были получены в определенное время, вы показывали пользователю ошибку.

• Вы можете добавить кеширование между B1 -> C1, например: (Если пользователь хочет получить данные для элемента 1, вы запрашиваете данные из C1, затем кешируете их и устанавливаете срок действия на 15 минут (зависит от вас)). Теперь, когда в следующий раз пользователь будет запрашивать те же данные в течение 15 минут, данные будут извлечены из кеша, а не из C1). Примечание. Это также зависит от типа данных. Если вы считаете, что данные динамические и меняются каждые 2 минуты, то добавлять кеширование нет необходимости.

Другой способ, но требует немного больше усилий:

Подход 2:

Используйте короткий опрос. Его можно использовать в сценарии, когда существует строгое требование получения данных, независимо от того, занимает ли это 2 секунды из 4.

Вы можете запустить фоновое задание для связи от B1 к C1 и вернуть ответ U1 с помощью uuid или идентификатора запроса, а также переслать его в фоновом задании. Поддерживайте статус задания в Redis против этого: В фоновом режиме при получении ответа обновите redis по идентификатору запроса с данными.

Также создайте один api для проверки статуса по запросу uuid, который вы получили, и опрашивайте api через регулярные промежутки времени, пока вы не получите либо неудачный, либо успешный). Вы также можете установить ограничение по времени, чтобы система не опрашивала api через 2 минуты, если статус остается «запущен».

Я знаю, что это немного больше, чем ожидалось:3. Кроме того, в программной архитектуре нет ничего хорошего или плохого. Есть только компромиссы.