Синхронная связь в архитектуре в основном асинхронных микросервисов

Question

Я пытаюсь извлечь некоторые услуги из моего монолитного приложения для домашних животных, в основном в качестве учебного упражнения. Я использую AMQP (RabbitMQ) для связи между службами, которая работает нормально. Однако у меня возникли проблемы с отделением веб-интерфейса от остальной части приложения. Веб-сервис заботится о представлениях и логике пользовательского интерфейса, но ему необходимо запросить базовую «основную» службу для основных данных. AMQP не подходит для этого, так как внешняя служба должна ждать ответа, а время ответа имеет решающее значение. Моя первая мысль заключалась в том, чтобы реализовать интерфейс REST только для этой линии связи, но одна и та же услуга также использует AMQP для подписки на связь других сервисов.

Похоже, что это должно быть довольно распространенное явление, но я не смог найти ответы.

Я предполагаю, что мой главный вопрос - что делать, когда один сервис должен предлагать как синхронную, так и асинхронную связь. Я также использую Ruby, который не поддается использованию нескольких потоков, которые потребуются для прослушивания на двух интерфейсах. Несколько вещей, которые я рассмотрел:

• Только с помощью AMQP, отправив сообщение с reply_to полем, и блокирование, пока не будет получен ответ.
• Извлеките часть доступа к данным базовой базовой службы и предоставите ей REST API. Тогда и веб-служба, и часть, которая «подписывается», будут запрашивать эту другую услугу. Нет необходимости иметь сервис только для доступа к базе данных.
• Наличие нескольких потоков и использование какого-либо цикла событий для прослушивания на двух интерфейсах. Кажется слишком сложным.

Answer 1

При построении распределенной системы (SOA/Microservices), вы будете использовать модель ОКК (Command Query Separation), это может быть переведен на 2-х разных каналов, один для команд и событий, для изменения состояния (асинхронного обмена сообщениями), а другой - для запросов, только для чтения моделей данных (синхронные чтения).

После того, как вы получите эту работу, вы можете посмотреть на создание моделей просмотра, которые отражают бизнес-состояние ваших данных (а не ваших временных OLTP-данных) с комбинацией pub/sub для распространения данных (не полные наборы данных, а контекстные данные - т.е. изменение цены продукта)

И да, это делает вещи более сложными, но и помогает уменьшить сцепление, которое помогает вам строить лучшие системы

имеет смысл?