приложение веб-API, подписывающееся на очередь.Это хорошая идея? - PullRequest
Новая
       32

приложение веб-API, подписывающееся на очередь.Это хорошая идея?

0 голосов
/ 18 мая 2018

Мы разрабатываем систему отчетности с использованием микросервисной архитектуры.Предполагается, что все сервисы являются подписчиками шины событий, и они общаются, вызывая события.Мы также решили выставить каждый из наших сервисов, используя REST API.Теперь вопрос в том, является ли хорошей идеей создание наших сервисов в виде приложений web api [RESTful], которые также являются подписчиками шины событий?так что в основном есть 2 ponits входа в каждый сервис - API и события.У меня есть ощущение, что мы должны отделить эти 2, так как это 2 разные проблемы.Есть идеи?

1 Ответ

0 голосов
/ 19 мая 2018

Поскольку архитектура микросервисов имеет несомненный программный дизайн.Таким образом, вы можете получить разные ответы на эти вопросы.Да, REST и Event based это две разные вещи, но иногда оба вместе дают дизайн для достижения большей гибкости.

Отвечая на ваши вопросы, Я не вижу никакого вреда, если REST API также подписываются на очередь до тех пор, пока вы можете поддерживать их оба, т. Е. Изменения в сообщении не влияют на API, и у вас есть надлежащий запасной вариант и Механизм возможной согласованности на месте.Вы можете проверить обсуждение .Уже есть несколько проектов, которые пробовали это, таких как nakadi и ponte .

Так что все зависит от поведения вашего сервиса связи, чтобы выбрать между API REST иДизайн на основе событий или оба .

То, что вы делаете, основано на ваших требованиях, вы можете выбрать REST API , где вы видите синхронное поведение между сервисами и переходом Дизайн, основанный на событиях , где вы найдете службы, нуждающиеся в Асинхронное поведение , объединение и того и другого не повредит.

В идеале для протокола межпроцессного взаимодействия лучше использовать обмен сообщениями, а для клиентского сервиса лучше всего подходят API REST.Проверьте стиль связи в microservices.io

Архитектура на основе REST

  • Преимущество

    1. Запрос / Ответ прост и лучше всего подходит для синхронных сред.

    2. Упрощенная система, поскольку в ней нет промежуточного брокера

    3. Способствует оркестровке, т. Е. Служба может предпринимать действия на основе ответа другой службы.

  • недостаток

    1. Службам необходимо обнаруживать местоположенияэкземпляров службы.

    2. Отображение один к одному между службами.

    3. Остальное используется HTTP, который является протоколом общего назначения, созданным поверх TCP / IPчто добавляет огромные накладные расходы при использовании его для передачи сообщений.

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

  • Advantage

    1. Управляемые событиями архитектуры привлекают разработчиков API, посколькуОни отлично работают в асинхронных средах.

    2. Слабая связь, поскольку она разъединяет сервисы, так как в случае однократного обслуживания несколько сервисов могут предпринимать действия в зависимости от требований приложения.легко подключить любого нового потребителя к производителю.

    3. Улучшенная доступность, поскольку брокер сообщений буферизует сообщения до тех пор, пока потребитель не сможет их обработать.

  • Недостаток

    1. Дополнительная сложность брокера сообщений, которая должна быть высокой доступности
    2. Отладка запроса на событие не так проста.
...