Понимание микросервисов, управляемых событиями

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

https://thenewstack.io/synchronous-rest-turns-microservices-back-monoliths/

Итак, управляемая событиями архитектура, похоже, помогает с общим дизайном, но я не понимаю, как будет работать запрос GET для данных, если вызываемому API нужны данные из другой службы? Отправит ли он запрос в автобус и подпишется на ответ? Вам просто нужно ждать ответа, который может задержать ответ потребителю?

Или это тот случай, когда вам нужно будет напрямую вызвать другой API? Будем очень признательны за любые ресурсы.


person Joel Holmes    schedule 26.07.2017    source источник
comment
как будет работать запрос GET ...? Запроса GET не будет, потому что у службы уже есть все необходимые данные от другой службы. Как? Здесь может помочь событийная архитектура. У службы уже есть все необходимые данные, потому что у нее есть подписка на события другой службы.   -  person tom redfern    schedule 26.07.2017


Ответы (1)


Книга Архитектура микросервисов содержит хорошие примеры поиска событий (глава 5), поскольку он моделирует компанию по доставке посылок. Идея поиска событий заключается в следующем:

Вместо хранения структур, моделирующих состояние нашего мира, мы можем хранить события, которые приводят к текущему состоянию нашего мира.

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

person AR1    schedule 26.07.2017