В предыдущей статье этой серии мы обсуждали заблуждения относительно механизма цикла событий в Vert.x

В этой статье я хотел бы рассмотреть еще одну важную концепцию масштабируемости фреймворка: его шину сообщений, которая в Vert.x называется шиной событий.

Актеры

Vert.x основан на легких актерах, называемых Вертикалами.

Вертикаль - это изолированная единица работы, которая может масштабироваться независимо.

Обычно модель акторов требует, чтобы у акторов была концепция, называемая «входящий почтовый ящик», которая обычно представляет собой очередь (более конкретно, блокирующая очередь с буферизацией).

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

Какая это может быть работа? Возьмем, к примеру, приют для животных. У нас будет один сервис, который будет получать запросы на регистрацию новых животных в приюте, а другой, который будет хранить их в какой-то базе данных.

Хорошо, это просто. Что произойдет, если мы теперь захотим получить информацию об этой кошке из базы данных?

Затем DB Actor нужно будет отправить другое сообщение HTTP Actor:

Это хорошо и все такое, но что, если вы решите масштабировать акторов БД, потому что им требуется много времени на обработку сообщений? HTTP-субъект должен будет отслеживать, сколько субъектов БД доступно, и иметь какую-то логику для балансировки нагрузки между ними. Или мы могли бы ввести другого субъекта, что-то вроде субъекта маршрутизации DB, который инкапсулирует эту логику, но сделает нашу архитектуру еще более сложной.

Vert.x использует другой подход к проблеме, называемый шиной сообщений.

Шина сообщений

Итак, что это за шина событий?

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

Как вы, наверное, догадались, этот компонент называется шиной сообщений или шиной событий в Vert.x

Давайте посмотрим, как тот же поток будет работать с шиной событий и статьями:

Как видно из диаграммы, это реализация шаблона проектирования Observer, а точнее его разновидности PubSub.

Итак, с шиной событий посередине, мы можем без проблем масштабировать DB Verticles. HTTP Verticle знает только о шине событий, а шина событий выбирает, в какую из баз данных Ver article будет доставлено сообщение.

Однако обратите внимание, что стрелка говорит «подтолкнуть того, кто слушает».

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

По той же причине нет возможности повторить старые сообщения новым подписчикам.

Кодеки

Распространенное заблуждение относительно шины событий в Vert.x состоит в том, что при ее использовании возникают накладные расходы, даже если ваши Вертикали находятся в той же самой JVM, как обычно.

Давайте проверим это утверждение.

Сначала мы создадим довольно большой объект (около 36 МБ):

Одна вертикаль создаст экземпляр и отправит этот объект по шине событий:

Пока другой получит:

Попробуем запустить это:

Что-то явно не так:

java.lang.IllegalArgumentException: No message codec for type: class eventbus.BigSerializedObject

Шина событий в Vert.x работает так, что она может доставлять сообщения в статьи, работающие на разных JVM и написанные на разных языках, если все они являются частью одного кластера Vert.x.

По этой причине требуется указать, как объекты кодируются и декодируются по сети, указав для них кодек.

Некоторые объекты, такие как String и JsonObject , имеют готовые кодеки.

Но это явно не наш случай.

Создадим собственный кодек:

И зарегистрируем его:

Теперь мы можем увидеть результаты. Я использую довольно ужасный код для отслеживания времени, поэтому он не является частью примеров:

To create message: 45ms
transform
To get message: 6ms

Как видите, при обмене данными внутри одной и той же JVM объект будет передаваться как ссылка на память между статьями.

Так что накладных расходов в таком случае буквально нет.

Выводы

Вот несколько ключевых моментов:

  • Vert.x использует облегченную модель акторов
  • Актеры в Vert.x называются Вертикалями.
  • Вертикальные статьи обмениваются данными с помощью шины событий
  • Сообщения в шине событий не сохраняются
  • Использование шины событий для передачи сообщений в одной и той же JVM не требует дополнительных затрат.

Если вам интересно узнать о других концепциях платформы Vert.x, дайте мне знать, оставив комментарий.