Vert.x 3 и Microservices

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

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

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

Функции

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

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

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

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

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

Любые мысли?

Ответ 1

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

A 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 общаются друг с другом с помощью распределенного eventbus, построенного с помощью Hazelcast. Это означает, что несколько JVM, работающих на одном и том же сервере или даже на нескольких серверах, могут взаимодействовать друг с другом через Eventbus.

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

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

Ответ 2

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