gRPC vs AMQP vs Kafka

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kafka это про big streaming data.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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