Vert.x 3 и микросервисы

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

Vert.x 3 и Vert.x-Apex предоставляют интересную модель для создания микросервисов. Как показывает один из примеров, простая вертикаль может открыть службу HTTP, поэтому доступна служба REST. Вертикаль связывает свой собственный TCP-порт.

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

Параметры

  1. Решением может быть запуск нескольких статей, каждая из которых содержит собственную маршрутизацию, поэтому обработка http содержится в статье. Запрос / ответ может быть полностью обработан по вертикали. Это может означать, что каждая вертикаль работает на своем собственном TCP-порту.
  2. Используя маршрутизатор, вы можете открыть все пути для одного порта и обработать их соответствующим образом. Данные будут обрабатываться по вертикали, содержащей маршрутизатор, с возможностью передачи их в другие статьи. Тогда это начинает выглядеть как более монолитный подход.
  3. Запустите отдельные экземпляры vert.x, содержащие службу (возможно, их кластер). Это может упростить использование непрерывной доставки, потому что все это самодостаточно.
  4. Другие возможные варианты?

Развертывание

Что касается развертывания, было бы желательно быстрое развертывание новых услуг без остановки всего приложения.

  • Вариант 3. может предоставить способ для этого, но также может вызвать накладные расходы, особенно когда есть вертикаль DB, работающая в каждой вертикали.
  • Вариант 1. Мог бы быть проще, но как насчет перезагрузки новых и обновленных статей?

Отдельные микросервисы предлагают интересный способ разработки, но создают некоторые проблемы в оркестровке и развертывании.

Есть предположения?


microservices architecture vert.x
person Wieki    schedule 04.05.2015    source источник

Ответы (3)


arrow_upward
14
arrow_downward

Начнем с терминологии.

  • verticle - это класс Java, который обычно расширяет AbstractVerticle и реализует метод start (..). Вертикаль может открывать одну или несколько конечных точек HTTP и экспортировать одну или несколько eventbus конечных точек.
  • Вертикаль проходит внутри Vert.x application (ранее называемого «модулем»). Приложение может содержать одну или несколько вертикалей. Я обычно использую соотношение 1: 1, чтобы все было проще и проще.
  • Приложение Vert.x запускается внутри Vert.x instance. Вы можете запустить несколько экземпляров приложения для увеличения распараллеливания.
  • Экземпляр Vert.x запускается внутри Vert.x container. Контейнер - это запущенный процесс с одним или несколькими экземплярами приложения.
  • Контейнер Vert.x работает внутри JVM.

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

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

Веб-приложение, созданное с помощью Vert.x, обычно состоит из одного или нескольких приложений Vert.x, предоставляющих конечные точки REST, обменивающихся данными по шине событий, с одним или несколькими приложениями Vert.x, открывающими (внутренние) конечные точки шины событий.

Чтобы ответить на ваш вопрос: вариант 3 является наиболее распространенным в настройках Vert.x и остается наиболее близким к архитектуре микросервисов. Здесь вы можете выбрать один из двух вариантов: либо вы запускаете 1 приложение с конечной точкой REST, которая обрабатывает все HTTP-вызовы и делегирует обработку запросов по шине событий другим приложениям, либо вы предоставляете каждую службу (или, по крайней мере, каждую службу, обеспечивающую функциональность для конечных пользователей). ) собственная конечная точка REST. Последний вариант немного сложнее настроить, поскольку существует несколько конечных точек HTTP, к которым можно подключиться из внешнего интерфейса, но он более масштабируемый и имеет меньше единичных точек отказа.

person Bert Jan Schrijver    schedule 28.02.2016
comment
Сможете ли вы расширить приложение, которое может содержать одну или несколько статей? Я не слежу за разницей между приложением vx и vx verticle, особенно в случае основного класса, который расширяет AbstractVerticle и запускается с $ vertx run com.my.verticles.Main. Какое приложение было бы здесь? - person Dog; 25.09.2018
comment
Приложению Vert.x требуется Verticle в качестве точки входа. Значит, вам понадобится как минимум 1 Вертикаль. Но вы также можете программно развернуть другие статьи из основной статьи. См. github.com/bertjan/vertx3-examples/blob/master/basic-eventbus/. - person Bert Jan Schrijver; 26.09.2018
comment
Я имел в виду инструкции vertx.deployVerticle(..); в примере. Не допускайте того факта, что у класса VertxStarter есть основной метод (Java), который получает экземпляр Vertx с помощью Vertx.vertx (); запутать вас ;-) (и в этом случае не обязательно расширять AbstractVerticle) - person Bert Jan Schrijver; 26.09.2018

arrow_upward
3
arrow_downward

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

Это официальные модули микросервисов:

  • Vert.x Service Discovery - публикация, поиск и привязка к любым типам служб.
  • Vert.x Circuit Breaker - реализует схему автоматического выключателя для Vert.x
  • Vert.x Config - предоставляет расширяемый способ настройки приложений Vert.x.

И есть еще официальные модули, которые пригодятся:

  • Метрики с использованием Dropwizard - получает метрики от основных компонентов и отправляет их в Dropwizard.
  • Метрики с использованием микрометра - получает метрики от основных компонентов и отправляет их в микрометр.
  • Проверка работоспособности Vert.x - предоставляет простой способ открыть доступ к проверкам работоспособности.
  • Vert.x Clustering - поддержка Hazelcast, Zookeeper, Apache Ignite и Infinicast
  • Службы Vert.x - простой и эффективный способ инкапсулировать многоразовые функции для использовать в другом месте.

Есть еще много официальных модулей, которые вы можете включить в свой дизайн микросервисов.

А также есть отличные статьи о том, как применять их на практике:

И, наконец, если вы хотите увидеть код, который идет намного дальше, чем HelloWorld, посмотрите:

И нужно иметь гораздо больше кода (например, API Gateway, хотя Readme на китайском языке) .

person Arnold Schrijver    schedule 01.07.2018

arrow_upward
0
arrow_downward

Я думаю, у вас должны быть веские причины масштабируемости для разделения ваших сервисов, и не существует единого универсального подхода к жизненному циклу и решению проблем, с которыми вы столкнетесь. заставить эти сервисы взаимодействовать друг с другом. Независимо от того, слушает ли сокет «вертикаль» или что-то еще, я бы подумал, что ограничение количества конечных точек / адресов вызовет наименьшую головную боль в этом направлении. В любом случае, объекту кода, ответственному за привязку данной вертикали к ее сокету, нужно будет каким-то образом предоставить средства управления жизненным циклом некоторой структуре оркестрации ... так же, как если бы она не слушала там вершину.

person David Bullock    schedule 04.11.2015