Шина событий vert.x может заменить потребность в Кафке?

Question

Я оцениваю платформу vert.x, чтобы увидеть, могу ли я уменьшить связь на основе Kafka между моими микроуслугами, разработанными с использованием весенней загрузки.

Вопрос: Могу ли я заменить 1. Kafka на событие vert.xшина и 2. пружинные загрузочные микросервисы с vert.x вертиками

Любые указатели будут очень полезны.

Заранее спасибо.

Answer 1

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

Потоки Кафки являются постоянными,и вы должны отправлять события туда, потому что вы хотите, чтобы другие (возможно, не Vert.x) приложения использовали их, и / или потому что вы хотите гарантировать, что эти события не будут потеряны в случае сбоя.

Реактивное (читается «масштабируемое и отказоустойчивое» ) приложение Vert.x обычно использует комбинацию шины событий и некоторых реплицируемых систем обмена сообщениями, таких как AMQP / Kafka / и т. Д.

Answer 2

По вопросу:

Могу ли я заменить микросервисы с пружинной загрузкой вертиками на основе vert.x?

Да, безусловно, хотя у двух разных моделей программирования.

Если вы хотите использовать более прогрессивный подход и использовать Spring для структурирования своего приложения при использовании Vert.x для повышения эффективности использования ресурсов ввода-вывода и обработки событий, вы можете смешать их, см. https://github.com/vert-x3/vertx-examples/tree/master/spring-examples дляпримеры.

Answer 3

Чтобы ответить быстро, я бы сказал, что это зависит от ваших потребностей.

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

Но в некоторых случаях вам может понадобиться:

• для обработки некоторых общих шаблонов предприятий, таких как механизмы воспроизведения, постоянство сообщений, чтение транзакций
• , чтобы иметь возможность обрабатывать какие-тосообщения в хронологическом порядке
• для обработки связи между несколькими видами микросервисов, которые не все написаны с использованием одного и того же фреймворка / инструментария или даже языка программирования
• для обработки надежности, устойчивости и восстановления после сбоя, когдавсе ваши потребители / микросервисы / статьи умерли
• для поддержки динамической горизонтальной масштабируемости и мониторинга ваших потребителей / микросервисов / статей

В этих случаях я предпочел бы выбрать Apache Kafka вместородной Eventbus или старый очарованный JMS комгибкая система.

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

Я поясню немногонемного о масштабируемости и мониторинге и объясню, почему я думаю, что проще справиться с этим с Kafka в собственном EventBus и кластерном режиме с помощью vert.x: Kafka позволяет нам знать в режиме реального времени ( через JMX метрики и команда describe):

• «задержка» темы, которая соответствует количеству непрочитанных сообщений
• количество потребителей в каждой группе, которые слушают тему
• количество разделов темы, затронутых каждым потребителем
• показатели ввода / вывода

Таким образом, можно использовать решение ElasticStack или Prometheus + Grafana для мониторингаэти метрики и использовать их для обработки динамической масштабируемости (когда вы знаете, что необходимо увеличить временныеИли количество потребителей, например, в соответствии с метрикой отставания и количеством разделов и метриками cpu / ram / swap ваших хостов).

Чтобы ответить на второй вопрос vert.x или SpringBoot, мой ответ будетне очень объективно, но я бы проголосовал за vert.x за его производительность на JVM и особенно за его простоту.Я немного устал от фабрики Spring и ее больших слоев абстракции, которая скрывает множество проблем под горой аннотаций, запускающих гору АОП.

Более того, в мире микросервисов Java есть другие альтернативы SpringBoot, такие как различные реализации Microprofile (например, thorntail project ).