Вы не должны следовать каждому правилу, как оно есть.
Существует много исключений из этого правила, и практика многих систем доказала, что оно не является правильным для каждого случая или системы.
Я не согласен с этим ограничением, согласно которому микросервис A никогда не должен вызывать микросервис B как общее правило, поскольку оно не распространяется на все случаи. Я работал с несколькими системами, используя
микро-сервисы, и мы не следуем за этим.
Связь между микроуслугами:
Вы можете использовать несколько способов связи между микро-сервисами, например:
События (с использованием очереди)
Команды - прямой вызов через API к другому микросервису (который является своего рода инструкцией для микросервиса), который
требуется изменение (создание, обновление, удаление).
Запросы - прямой вызов через API к другому микросервису (как ваш пример получения GUID).
Снова некоторые люди скажут, что это и Командование.
Использование запроса в качестве термина часто комбинируется при использовании CQRS .
Shared Db's (большинство онлайн-ресурсов скажут вам не делать этого)
по нескольким причинам)
В общем случае это не рекомендуемый подход.
В общем
Вы должны работать со своей системой исходя из своих потребностей, а не исходя из установленных в камне правил, таких как
«Микро Сервис А никогда не должен звонить в Микро Сервис Б».
Я приведу пример, почему:
Пример:
Допустим, у вас есть «микро-сервис А» и «микро-сервис Б». Ваш «микро-сервис B» потребляет события, которые «микро-сервис A» публикует через Kafka. «Микросервис B» при использовании событий сохраняет некоторые соответствующие «Внешние» данные в своей собственной базе данных (дублируя их).
Это обычный подход - не вызывать «микро-сервис А» каждый раз, когда вам нужны некоторые его данные. Это распространено например
если «micro-service A» - это какая-либо служба, имеющая параметры конфигурации системы или аналогичные.
Допустим, у вас есть сценарий катастрофы, когда ваша база данных и все данные из вашего "микро-сервиса B" разрушаются или повреждены.
Чтобы решить эту проблему, вы можете просто восстановить резервную копию и применить последние события, скажем, в последний 1 ч, где
ваш «микро-сервис B» не работал и решил проблему (если ваша обработка событий реализована как идемпотентная). Все хорошо в этом случае.
С другой стороны, если у вас какое-то время работает система на производстве. Через некоторое время вы разрабатываете «микро-сервис C» и решаете
развернуть его в производство. Оказывается, вам нужны данные, которые выдает «микро-сервис А». Вам нужны эти данные на вашем "микро-сервис C"
Внешние данные аналогичны тем, которые были у вас с «микро-сервисом Б». Как вы получаете эти данные?
Вы потребляете все события из "микросервиса А"? В идеальном мире вы бы сохранили все события в Кафке навсегда. В этом случае вы бы
Просто подпишитесь на события и примените их все, чтобы сохранить все необходимые данные в «микро-сервис C».
В действительности вам нужно установить срок хранения для вашей Kafka, скажем, на 5 дней. Если ваша система работает дольше 5 дней, вы не можете воссоздать данные из событий.
В этом случае вам нужно вызвать сервис напрямую с помощью Command / Query и заполнить базу данных «микро-сервис C».
Это всего лишь один крайний пример, для которого вам потребуется прямой вызов.
Резюме:
Есть много других примеров, где этот подход также действителен.
Например, очень часто вам необходимо синхронно вызывать другую микросервисную службу и ждать ответа (в зависимости от бизнес-сценария). Лучший способ сделать это - вызвать другой микро-сервис напрямую с помощью команды / запроса.