Статьи

Примеры реактивных сообщений для Quarkus

Quarkus предоставляет несколько различных возможностей реагирования на сообщения. Проект open-source cloud-native-starter использует некоторые из этих возможностей в примере приложения, которое описано в этой статье.

Существует несколько простых руководств Quarkus по теме «Реактивные сообщения». Учебники — это здорово, но для меня лучший способ освоить новые технологии — это использовать их в простых приложениях. Вот почему я придумал простой сценарий.

Вам также может понравиться: Как писать реактивные приложения с MicroProfile

Образец заявки

Пример поставляется с веб-приложением, которое отображает ссылки на статьи с информацией об авторе в простом веб-приложении. Веб-приложение вызывает службу веб-API, которая реализует шаблон backend-for-frontend и вызывает микросервисы статей и авторов. Служба статей хранит данные в базе данных Postgres . Сообщения отправляются между микросервисами через Kafka. Эта диаграмма описывает архитектуру высокого уровня:

карта Куберне

Одним из преимуществ реактивных моделей является возможность обновления веб-приложений путем отправки сообщений, а не получения обновлений. Это более эффективно и улучшает пользовательский опыт.

Следующее видео показывает, как статьи могут быть созданы с помощью REST API. Веб-приложение получает уведомления и добавляет новые статьи на страницу.

Облако родного стартера

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

клиенты kubernetes

  1. Клиент API «отправки» вызывает конечную точку REST службы «статьи» для создания новой статьи.
  2. После создания статьи сообщение отправляется в Kafka.
  3. Служба web-API подписалась на сообщения Kafka, так что вызывается прослушиватель.
  4. При создании новых статей события передаются в веб-приложение.

Давайте внимательнее посмотрим на используемые технологии.

Отправка сообщений в памяти через шину событий Vert.X

«Articles» и сервис «web-API» были реализованы на Java с Quarkus. В обоих случаях я использовал подход с чистой архитектурой, когда код микросервиса организован в три пакета. Эти пакеты довольно независимы друг от друга и могут быть заменены другими реализациями.

  1. API : содержит конечные точки REST и обрабатывает входящие и исходящие сообщения.
  2. Бизнес : Содержит бизнес-логику микросервисных и бизнес-структур.
  3. Данные : содержит код для доступа к базам данных или другим микросервисам.

После сохранения новой статьи в базе данных Postgres сообщение отправляется в Kafka. Это инициируется бизнес-логикой, но фактический код находится на уровне API. Вот почему бизнес-уровень должен сначала отправить сообщение на уровень API.

Quarkus предоставляет механизм взаимодействия бинов через асинхронные сообщения, обеспечивая слабую связь. Посмотрите руководство Асинхронный обмен сообщениями между компонентами . Эта функциональность предоставляется через Eclipse Vert.x, который поставляется с Quarkus.

Вот код, который отправляет событие в памяти на уровень API:


Джава