Дорогая обработка Vertx Eventbus Json

У меня вопрос о Vertx Eventbus и о том, как ее правильно использовать. Есть как минимум два варианта использования EventBus в Vertx:

  1. Я использую методы Eventbus, предоставляемые Vertx, для вызова функций, находящихся на другой Verticle. Плюс в том, что я могу использовать кодеки для передачи параметров по Eventbus. Если я хочу использовать его только локально, я могу просто передать ссылку. Обратной стороной здесь является то, что мне нужно предоставить String, чтобы определить, какую функцию я хочу вызвать. Если посмотреть на скорость разработчика, это очень плохо, потому что теперь мне нужно искать строки в базе кода, чтобы найти функции, которые я вызываю.

  2. Я использую Vertx Service Proxy. Это очень удобно, поскольку он генерирует прокси для Eventbus во время компиляции. Это позволяет мне как разработчику следить за функциями, которые я вызываю в статьях, и мне вообще не нужно иметь дело с Eventbus API. Однако у него есть и некоторые важные недостатки: теперь время запуска занимает больше времени, и прокси-сервер преобразует все свойства функций в Json и обратно. Это может очень плохо сказаться на производительности приложения.

Мой вопрос: как лучше всего использовать Eventbus? Мне не хватает чего-то, что могло бы помочь мне с недостатками второго варианта? Есть ли альтернативы, которых я еще не вижу?

Спасибо


person Maximilian Deichmann    schedule 08.11.2020    source источник


Ответы (1)


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

как вы упомянули, для передачи тривиальных POJO вам нужен кодек, и большинство кодеков различают локальный вызов и, следовательно, передачу ссылки и вызов по сети. Так что здесь не о чем беспокоиться. Простой способ не писать кодек для каждого типа определяемого вами класса - это использовать @DataObject и позволить генерации кода позаботиться об этом. Таким образом, вы просто отправляете и получаете POJO, а все остальное делается автоматически. Это было без использования сериализации, по крайней мере, некоторое время назад (см. здесь).

Что касается прокси-сервера службы, текущая реализация всегда сериализует все параметры, но эта проблема уже поднималась давным-давно. Но это цена, которую вы платите за безопасность типов (по крайней мере, в некоторой степени).

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

person mohamnag    schedule 17.11.2020
comment
Спасибо за ответ. Возможно, я неправильно понял, но Service Proxy сериализует все параметры функции и все возвращаемые значения в Futures, даже если они являются объектами DataObjects, верно? В этом случае я плачу действительно высокую цену за производительность. - person Maximilian Deichmann; 17.11.2020
comment
вы правы, у меня сложилось неверное впечатление, но глядя на это Я выяснил, что вы правы, и он всегда де / сериализует - person mohamnag; 18.11.2020
comment
Кстати, я не совсем уверен, действительно ли это высокая цена производительности. если вы используете кодогенерацию vertx для создания де / сериализаторов, они на самом деле работают очень и очень быстро. не используйте Джексон или подобное решение. У меня есть опыт работы с несколькими уровнями сервисов, все они выполняются с помощью vertx, и все они выполняют такие де / сериализации внутри компании, и весь цикл туда и обратно занимает менее 50 мс на запрос. - person mohamnag; 18.11.2020