Я предоставляю два микросервиса API, оба на архитектуре RESTful для вызовов транзакций.
API A отвечает либо S, NS, либо OK / NOT OK.S это стандартный ответ.NS - это нестандартный ответ, который может быть результатом: - x секунд, прошедших с первого S ответа - API B получил прямой запрос на ответ API A NS в следующий раз API B также всегда может создать API Aответ OK или NOT OK, исключающий необходимость в дальнейшем обратном отсчете (впоследствии это приведет к ошибке для определенного идентификатора транзакции в API A).
Другими словами, есть два компонента: события и таймеры,Решение проблемы грубой силы состояло бы в том, чтобы запустить таймер после начального вызова API A и каждую секунду или около того проверять наличие каких-либо обновлений в БД статуса транзакции, поступающих из API B. По истечении x секунд состояние в БД обновляется в любом случае, так что по новойAPI Вызов, новый API. Процесс знает, что он должен ответить NS.
Этот сценарий является перебором, поскольку существует процесс блокировки потока с таймером.Я бродил, если бы я мог достичь чего-то похожего с событиями / очередями или другой архитектурой, которая заменит оба с использованием БД в качестве посредника между двумя API и уменьшит потребность в таймере?Может ли Azure Event-Hub выдвинуть условно?