Vert.x - различия между статьями и сервисами

Мы начали использовать vert.x несколько дней назад. Чтение документации (Мягкое руководство по асинхронному программированию с Eclipse Vert.x для Java-разработчика - https://vertx.io/docs/guide-for-java-devs/) я понял концепцию вертикальной статьи. Чего я не понял, так это концепции "службы" и "прокси службы":

«Это основная цель прокси-серверов служб. Они позволяют вам предоставлять службу в шине событий, чтобы любой другой компонент Vert.x мог использовать ее, как только им известен адрес, на котором опубликована служба. A Сервис описывается с помощью интерфейса Java, содержащего методы, следующие асинхронному шаблону. Под капотом сообщения отправляются по шине событий для вызова службы и получения ответа. Но для простоты использования он генерирует прокси, который можно вызывать напрямую. "

Но как одна услуга связана с концепциями вертикальной статьи и цикла событий? Принадлежит ли он отдельной автономной вертикали и имеет свой отдельный цикл событий, или он принадлежит определенной вертикали? Когда и где мне следует регистрировать услугу? Внутри метода начала вертикали или просто в основном методе?

Спасибо!


java vert.x vertx-verticle
person Reste85    schedule 09.04.2018    source источник

Ответы (1)


arrow_upward
4
arrow_downward

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

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

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

P.S :

1) нет необходимости писать main метод с использованием vert.x (вы можете использовать io.vertx.core.Launcher внутри толстой банки или исполняемый файл vertx для запуска вашей основной версии).

2) вы можете запускать все ваши вершины как отдельные pid, используя класс io.vertx.core.Launcher внутри толстой банки или исполняемого файла vertx, или вы можете запускать несколько вершин внутри основной вершины, чтобы они по умолчанию использовали один и тот же цикл событий (но вы также можете объявить пул рабочих и используйте "рабочие статьи" согласно: https://vertx.io/docs/vertx-core/java/#worker_verticles).

person Idriss Neumann    schedule 09.04.2018
comment
Спасибо, Идрис! Предположим, у вас есть: - Одна Verticle, которая предоставляет конечные точки HTTP - Каждый обработчик HTTP вызывает серию классов, содержащих некоторую бизнес-логику - Внутри этих классов бизнес-логики есть аутентификация. менеджер, который читает заголовок и проверяет содержимое базы данных. Я хочу создать две службы: 1) Служба авторизации: будет отвечать за вызов службы базы данных и сохранение пользователя в одноэлементном режиме 2) Служба базы данных: будет отвечать выдавать запросы в базе данных Что бы вы сделали? Создать новые статьи или связать сервисы с HTTP-версией? - person Reste85; 09.04.2018
comment
@ Reste85 Я не уверен, что понимаю ваш вопрос, но, например, вы можете написать одну вершину, которая будет отправлять сообщение на вторую вершину в шине событий, чтобы проверить учетные данные в базе данных и дождаться ответа, прежде чем выполнять какие-либо другие дела. Важно оставаться максимально неблокирующим. Например, если вы хотите предоставить URL-адрес POST http для создания некоторых данных в базе данных, лучше спроектировать свою конечную точку как неблокирующую, немедленно ответив кодом возврата 202 независимо от результата операции и URL-адресом обратного вызова для опубликовать результат например. - person Idriss Neumann; 09.04.2018