API-шлюз для событийной архитектуры

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

Следующим этапом является создание конечных точек API для связи между мобильными приложениями и микросервисами через шлюз Api.

Что было бы хорошим решением для разработки шлюза API для передачи данных в / из микросервисов?

  1. использовать систему сообщений как запрос-ответ (преобразовывать запросы на шлюзе API в команды сообщений, ждать ответа от системы сообщений со статусом или необходимыми данными)?
  2. создавать конечные точки REST на необходимых микросервисах (например, используя REST.li) для отправки или получения данных через шлюз; использовать систему сообщений для согласованности данных на основе событий, созданных микросервисами?

Спасибо за совет и некоторые идеи


microservices rest event-driven soa
person alexander    schedule 24.04.2017    source источник
comment
Столкнувшись с той же проблемой. У меня есть несколько сервисов, говорящих по rabbitmq. Мне нужен шлюз для взаимодействия с системой. Хотите узнать, к какому решению вы пришли?   -  person marcin_koss    schedule 21.09.2019

Ответы (2)


arrow_upward
0
arrow_downward

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

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

Чтобы проиллюстрировать, поток платежей может быть таким, как показано ниже:

1-) API GW -> Payment Rest Controller -> Payment Service - Create Payment Служба оплаты создает платежную сущность, а затем публикует событие «payment.created». 2-) Очередь -> Контроллер потока платежей -> Сервис - Обновить платежный поток Контроллер потока платежей использует событие «payment.created», а затем проверяет балансы и обновляет платежную сущность как подтвержденную. После обновления сущности она может отправить событие «payment.confirmed». ...

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

Однако я думаю, что в некоторых случаях лучше объединить два решения. Например, ваш API предоставляется клиенту с очень высоким трафиком, и задача API достаточно ясна. В этой ситуации было бы идеально использовать MQ в качестве буфера для этого API.

person jeadonara    schedule 10.12.2019

arrow_upward
-1
arrow_downward

Это зависит от архитектуры, которую вы принимаете. Если я понял вопрос, у вас уже есть брокер с сервером сообщений kafka. Я думаю, что вы можете использовать архитектуру публикации / подписки на синхронное сообщение.

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

Это преимущество, если использовать шаблон шлюза API в архитектуре.

Большое спасибо.

person Alex    schedule 21.05.2017