LINUX.ORG.RU

gRPC vs AMQP vs Kafka

 , , , ,


2

2

Всем привет, запутался когда что стоит использовать, сейчас использую EventBus в Vert.x для коммуникации между микросервисами и gRPC в качестве API для клиента (веб приложения). Собственно у меня имеется RealTime стримы, которые клиент получает, к примеру - баланс кошелька либо изменения лога. Все это успешно реализовал средствами только gRPC, вроде бы работает отлично все, но под нагрузкой еще не тестировал. Сейчас думаю добавить AMQP для микросервиса генерации документов, т.к. он дает определенные гарантии. В интернетах часто вижу, что люди используют либо kafka либо amqp либо и то и другое для коммуникации между микросервисами либо для реализации real-time изменений. Сейчас по поводу AMQP и Kafka у меня такие мысли - их стоит использовать, когда у тебя много микросервисов и всем им нужно раздать однинаковые команды, либо когда много микросервисов пишут в один и тот же топик. У меня же ситуация пока другая - у меня много одинаковых микросервисов только для генерации документов, собственно туда я и хочу прикрутить AMQP. Но вот микросервис биллинга и аукциона - это синхронные микросервисы у которых по одному инстансу на каждый, для аукциона критически важна скорость, для биллинга - надежность, аукцион в итоге может отправлять команды биллингу и там скорость уже не будет так важна, потому-что там идет и тяжелая верификация. Но изменения аукцион получает быстро. В будущем конечно возможно будет множество биллинг сервисов, но аукцион точно будет один. Еще читал, что к kafka и gRPC могут дополнять друг друга.

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

★★★

Не стоит пользоваться серебряной пулей™ лишь потому, что сейчас мода на серебряные пули.

Ты не поверишь, но со стороны очень заметна разница между теми, кто создаёт работающие решения, и теми, кто пытается попасть в струю, используя модные библиотеки X, и Y, и Z.

Есть очень простой критерий «правильности»: то, укладываешься ты в требования заказчика или нет. Поэтому плясать нужно, наверное, от нагрузочного тестирования, а не сферической «Кафки» в вакууме.

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

Bass ★★★★★ ()

Kafka или AMQP нужны если устраивает согласованность системы в конечном счете. Посмотри на CAP теорему и реши какими свойствами должна обладать твоя система. На основе этого уже надо выбирать архитектуру и инструменты.

four_str_sam ()

gRPC с одной стороны и AMQP и Kafka с другой строны имеют разное назначение. Поэтому может иметь смысл использование не вместо, а вместе.

gRPC это, как видно из название, программная инфраструктура для дистанционного вызова процедур, использующая протокол Google Protobuf. Есть ряд альтернатив, но эта популярна.

AMPQ это протокол передачи сообщений, в том числе обеспнчивающий надёжную доставку сообщений. То есть, они накапливаются где-нибудь на сервере, пока не будут получены всеми эелающими клиентами. Это немдистанционный вызов процедур, а передача сообщений. И не программное средство, а только протокол. Для практического использования нужно ещё программное средство с поддержкой AMQP. Популярно RabbitMQ. Таким образом, вам надо сравнить RabbitMQ и Kafka и выбрать, что больше нравится. Использование gRPC другой вопрос.

Partisan ★★★★ ()

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

Мейнстрим и всего лишь. Если тебе реально не нужно, значит вообще не нужно.

gRPC неплох когда у тебя постоянно большой поток, в противном случае даже JSON быстрее (ищи тесты, в инете их есть). Для упрощения можно думать про это как всего лишь транспортный протокол, который решает задачу сериализации / десериализации структуированных данных с возможностью валидации. В этой теме еще можно попробовать MsgPack и пр.

AMPQ, RabbitMQ и пр. - это (асинхронные) очереди сообщений. Часто используются, чтобы копить данные (задания) и обрабатывать в фоне, когда появится ресурс (workers) не теряя задания. Но основа все же передача каких-либо сообщений.

Можно вообще свою написать, для понимания принципа.

Если стоит вопрос саморазвития и обучения технологии, то я бы посоветовл ZMQ. Он чуть сложнее AMPQ и RabbiMQ для начала освоения, но большая гибкость и фундаментальность.

Для резюме и чтобы быть в теме можешь написать 1-2 pet project и можешь козырять кодом на собеседованиях.

anonymous ()

Kafka это про big streaming data.

Есть у тебя куча онлайн (потоков) данных и их надо обрабатывать, тогда Kafka.

Еще читал, что к kafka и gRPC могут дополнять друг друга.

Скорее всего имелось как раз в виду то, что gRPC ориентируется и показывает улучшения на больших объемах данных и собственно Kafka под их обработку заточен.

anonymous ()
Ответ на: комментарий от anonymous

Да спасибо большое за объяснение, gRPC был выбран не из-за скорости, скорее из-за типизации и удобного описания контрактов.

Если стоит вопрос саморазвития и обучения технологии, то я бы посоветовл ZMQ. Он чуть сложнее AMPQ и RabbiMQ для начала освоения, но большая гибкость и фундаментальность.

Хорошая идея, спасибо, попробую.

Int64 ★★★ ()
Ответ на: комментарий от anonymous

Скорее всего имелось как раз в виду то, что gRPC ориентируется и показывает улучшения на больших объемах данных и собственно Kafka под их обработку заточен.

Да не, вроде там имелось ввиду - создания api для конечных клиентов - https://github.com/mailgun/kafka-pixy

Int64 ★★★ ()
Ответ на: комментарий от Partisan

Это я все понимаю, но все же есть задачи, которые можно решить и с использованием gRPC (без AMQP/Kafka) и с использованием AMQP/Kafka, и в качестве API сделать REST или gRPC или напрямую коннектиться. У меня вопрос был больше - что и когда лучше использовать, бездумно тащить популярные технологии тоже не хотелось бы.

Int64 ★★★ ()
Ответ на: комментарий от Int64

Ну, поддержка - это такое себе «хорошее дополнение», обычный REST с JSON там тоже есть.

Dual API сейчас часто делают - это удобно.

В общем, останусь при свое мнении, что там имелось ввиду.

А вообще лучше в том месте и узнать, про какое «дополнение» писали.

anonymous ()

Это зависит от вашей конкретной задачи, постановку которой нельзя изложить в нескольких строках.

Я использую AMQP (с использованием https://spring.io/projects/spring-amqp).

Но это для конкретной задачи, которую мне поставили.

Вам надо просто пробовать разные комбинации - однозначно решить можете только вы..

Bioreactor ★★★★★ ()
Последнее исправление: Bioreactor (всего исправлений: 1)

Эм ты выбираешь из 3х продуктов с совершенно разным назначением, ты попробуй определить для начала необходимую функциональность а потом выбирать под неё реализацию.

ЗЫ. Если у тебя всё работает, почему ты решил что-то переделывать?

ya-betmen ★★★★★ ()
Последнее исправление: ya-betmen (всего исправлений: 1)
1 августа 2019 г.
Ответ на: комментарий от ya-betmen

ЗЫ. Если у тебя всё работает, почему ты решил что-то переделывать?

Да, вы абсолютно правы, я вообще не в том направлении искал ответы, оказалось большая проблема с архитектурой приложение, после того как поправил стало все предельно понятно и gRPC сейчас - это просто gateway для бизнеслогики и никакой сложной логики не делает внутри, раньше наоборот все в куче было и вся бизнес логика и обработка ошибок была размазана внутри REST, gRPC и EventBus'е (когда я все это делал я понимал что говно, но сроки поджимали :))

Int64 ★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.