Двусторонняя связь для Restpect Microservices, разумна ли для уведомления?

Question

Многие книги и статьи показывают, что циклы в микросервисах обычно плохи, поскольку они вносят взаимную взаимозависимость, что в результате приводит к большей зависимости, проблемам управления версиями и развертывания.

Однако, предположим, что есть служба , вызов службы B, также полагают, что, поскольку этот вызов будет инициировать громоздкое вычисление таким образом, мы не должны делать этого вызова синхронно. Возможным решением является сервис A передает URL-адрес ресурса B, так что когда когда-либо B рассчитывает результат, он должен опубликовать результат с заданным URL-адресом после спокойной парадигмы. Итак, этот конечный ресурс похож на какой-то обратный вызов. Этот подход действительно решит мою проблему, однако, как объясняется в предыдущем параграфе, он вводит циклическую зависимость. Это нормально? если не так, как иначе вы решите ту же проблему?

Answer 1

Его хорошо, но не хороший дизайн, так как вы можете видеть зависимость довольно жестко.

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

Таким образом, ваше сообщение будет асинхронным, слабо связанным, и ни одна из служб не должна знать очень конкретно друг о друге и их местоположении/адресе. Это также способ общения в соответствии с рекомендациями Reactive Manifesto.