Я бы еще раз взглянул на вашу архитектуру. В целом, с микросервисами - особенно с обращенными к пользователю, которые должны быть по существу синхронными, это - анти-паттерн, когда ServiceA приходится звонить на ServiceB (что, в свою очередь, может вызывать ServiceC и т. Д. ...) чтобы вернуть ответ. Это условие указывает, что эти сервисы тесно связаны, что делает их хрупкими. Например: если ServiceB выходит из строя или перегружен в вашем примере, ServiceA также отключается из-за собственной ошибки. Поэтому, вероятно, должно произойти одно или несколько из следующих действий:
- Развернуть связанные службы за фасадом, охватывающим весь домен, - разрешить клиенту синхронно взаимодействовать с фасадом и разрешить фасаду взаимодействовать с несколькими пользователями. сервисы за кулисами.
- Используйте MQTT или AMQP для публикации данных по мере их добавления / изменения в
ServiceB и имейте подписку ServiceA, чтобы получить то, что нужно, чтобы она могла выполнить запрос пользователя без явноговызов другой службы - Рассмотрите возможность объединения
ServiceA и ServiceB в одну службу, которая может обрабатывать запросы без необходимости выполнения внешних вызовов
Вы также можете отправить HTTP-запрос изклиенту службы, установите для состояния приложения значение waiting или аналогичное и попросите приложение-потребитель подписаться на интеграционное сообщение eventSuccess или eventFail с шины. Суть этой идеи заключается в том, что вы позволяете сервисам с последовательным подключением (которые, опять же, мне не нравятся) по очереди, и какой бы сервис «не заканчивал» работу, публикует событие интеграции, чтобы каждый, кто слушает, знал. Вы даже можете сделать что-то вроде передачи URI webhook с первоначальным запросом, чтобы службы вызывали приложение сразу после завершения (или использовали SignalR, или gRPC, или ...)
Способ, которым мы используем RabbitMQ, заключается в интеграциисервисы в режиме реального времени, так что каждый сервис всегда имеет информацию, необходимую для быстрого реагирования. Чтобы использовать ваш пример, в нашем мире ServiceB публикует события при изменении данных. ServiceA заботится только о небольшом подмножестве этих событий и подписывается на небольшое подмножество этих событий (и, как правило, только на одно или два поля данных события), но в течение нескольких секунд (обычно меньше) знает, когда B изменилось, и у него есть всеинформация, необходимая для ответа на запросы. Каждый сервис буквально не знает, какие существуют другие сервисы, он просто знает, какие события, о которых он заботится (и которые соответствуют договору), происходят время от времени, и ему необходимо обращать на них внимание.