Когда я захочу создать более одной статьи (если я использую неблокирующие клиенты БД в микросервисе без состояния)?

Question

Предполагается,

• Я создаю микросервис без сохранения состояния, который предоставляет несколько простых конечных точек API (например, сквозной кэш, сохранение записи в базе данных),
• Я использую неблокирующие клиенты базы данных, например, mysql или redis и
• Я всегда хочу, чтобы мои микроуслуги общались друг с другом через HTTP (помещая Экземпляры EC2 за балансировщиком нагрузки)

Вопросы

1. Когда я захочу использовать более 1 стандартной версии (т. Е. Записать весь микросервис как одну строку и развернуть n экземпляров этого (n = num событий-l oop потоков)). Разве добавление новых версий не только увеличит затраты на сериализацию и переключение контекста?
2. Допустим, я разделил микросервис на несколько стандартных версий (по любой причине). Разве развертывание n (n = num потоков-1 oop потоков) экземпляров каждого не всегда дает лучшую производительность, чем развертывание другого соотношения экземпляров. Поскольку каждая вертикаль является просто слушателем адреса, это будет означать, что каждый поток-l oop может обрабатывать все виды сообщений, и они уже сбалансированы по нагрузке.
3. Когда я захочу запустить свое приложение в режим кластера? Основываясь на документах, я чувствую, что режим кластера имеет смысл только тогда, когда у вас есть несколько вершин, и то же самое, когда у вас есть реальный вариант использования для кластеризации, например, разные экземпляры EC2 обрабатывают запросы для разных пользователей, чтобы помочь с локальностью данных (скажем, используя зажечь)

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

Answer 1

1. Вертикаль - это способ структурировать ваш код. Таким образом, вам может понадобиться вертикаль другого типа, вероятно, когда ваша основная вертикаль станет слишком большой. Насколько велик? Это зависит от ваших предпочтений. Я стараюсь держать их довольно маленькими, максимум 200 LO C, чтобы сделать одну вещь.

2. Не обязательно. Разные стихи могут выполнять самые разные задачи в разном темпе. Наличие N экземпляров всех их не обязательно плохо, а скорее излишне.

3. Вероятно, никогда. Кластерный режим был вещью до микросервисов. Использование этого добавляет еще один уровень сложности (менеджер кластера, например, Hazelcast), и это также означает, что вы не можете быть как полиглот.

Answer 2

Я всегда хочу, чтобы мои микроуслуги общались друг с другом через HTTP (размещая экземпляры EC2 за балансировщиком нагрузки)

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

Ответы:

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

2. Если ваши статьи используют неблокирующие вызовы (и, следовательно, являются многопоточными), вы не увидите никаких разница между 1 или N экземплярами на одной машине. Также, если ваша вертикаль запускает (HTTP) сервер через определенный порт, то все экземпляры будут совместно использовать этот единственный сервер по всему потоку (vertx выполняет здесь несколько магических c маршрутизаций)

3. Режим кластера - это то, о чем я упоминал в начале. Это правильный способ распространения и масштабирования ваших микросервисов.