Когда использовать Spring Integration против Camel?

138

Как опытный пользователь Spring, я предполагал, что Spring Integration будет наиболее целесообразным в недавнем проекте, требующем некоторых (JMS) возможностей обмена сообщениями ( более подробно ). После нескольких дней работы с Spring Integration все еще ощущается большая нагрузка на конфигурацию, учитывая количество каналов, которые вы должны сконфигурировать, чтобы обеспечить связь между запросом-ответом (прослушивание разных очередей JMS).

Поэтому я искал некоторую справочную информацию о том, чем Camel отличается от Spring Integration, но кажется, что информация там довольно скудная, я обнаружил:

Вопрос: какой опыт вы получили при использовании одного стека над другим? В каких случаях вы бы порекомендовали Camel, если Spring Integration не имеет поддержки? Где вы видите плюсы и минусы каждого? Любой совет от реальных проектов высоко ценится.

ngeek
источник
5
Учитывая абсолютно потрясающую интеграцию Camel с Spring, я не вижу никакой веской причины даже взглянуть на Spring Integration. Верблюд превосходен в любой области: лаконичен, интуитивен, силен, ... весел. Вы можете сделать так много с помощью одной строки кода, что иногда я чувствую себя виноватым из-за того, что не написал достаточно кода для оправдания функциональности.
Павел Лечев

Ответы:

75

Мы выбираем Camel вместо Spring-Integration, потому что свободный API действительно хорош. Мы фактически используем его в проектах Spring и используем Spring для его настройки. API-интерфейсы программирования понятны, и есть большой набор разумных компонентов.

Мы провели небольшую перестрелку, и в то время, по нашему требованию, победил Верблюд. Мы используем его главным образом для передачи внутренних файлов данных внешним сторонним организациям, которые обычно требуют преобразования формата, отправляя его с использованием ftp / sftp / ... или прикрепляя его к электронному письму и отправляя его.

Мы обнаружили, что цикл edit-compile-debug сокращен. Используя groovy для экспериментов по настройке маршрутов, добавляются бонусы.

Spring-Integration также является отличным продуктом, и я уверен, что он также удовлетворит наши потребности.

Питер Тиллеманс
источник
1
Спасибо Питеру за то, что он поделился своими соображениями. Вы когда-нибудь пытались использовать возможности JMS компании Camel? Кажется, что соответствующие компоненты также достаточно гибкие и обладают таким же богатством, как Spring Integration? Под «мелкомасштабной перестрелкой» вы понимаете лучшие показатели производительности?
ngeek
1
Перестрелка: это была в основном производительность разработчика. Наши потребности в производительности не очень высоки. Да, мы используем много JMS в качестве основы. Оба ActiveMQ и JBossMQ используются для обмена сообщениями.
Питер Тиллеманс
Вы можете посмотреть stackoverflow.com/questions/46930494/… ?
gstackoverflow
67

Я рекомендую Spring Integration только в том случае, если у вас уже есть проект Spring, и вам просто нужно добавить некоторую «базовую» интеграцию, используя File, FTP, JMS, JDBC и так далее.

Apache Camel имеет два основных преимущества:

  1. Многие, многие другие технологии поддерживаются.
  2. Кроме (хорошего) XML DSL, существуют свободные API для Java, Groovy и Scala.

Поскольку Apache Camel имеет очень хорошую интеграцию со Spring, я бы даже использовал его вместо Spring Integration в большинстве проектов Spring.

Если вам нужна дополнительная информация, вы можете прочитать мой опыт в моем блоге: « Избранный для выбора»: какую интеграционную платформу использовать - Spring Integration, Mule ESB или Apache Camel?

Кай Венер
источник
31

Недавно я провел перестрелку Camel vs Spring Integration с целью интеграции Apache Kafka . Несмотря на то , заядлый разработчик Spring, я , к сожалению , нашел мое подозрение с постоянно растущим стеком проекта Spring подтвердил: Spring является удивительным , как МОК-Container , чтобы служить в качестве клея для других рамок, но она не в обеспечении жизнеспособных альтернатив в этих рамках . Могут быть исключения из этого, а именно все, что связано с MVC, откуда пришел Spring и где он отлично справляется, но другие попытки предоставить новые функциональные возможности поверх функций контейнера терпят неудачу по трем причинам, и пример использования SI Kafka подтверждает все они:

  • Внедрение давно сложного в использовании DSL для XML-конфигурации.
  • Страницы кода XML-конфигурации для подключения всех компонентов инфраструктуры.
  • Недостающие ресурсы для обеспечения функциональности наравне с выделенными фреймворками.

Теперь вернемся к результатам моей перестрелки: самое главное, я впечатлен общей концепцией маршрутов между конечными точками Camels . Kafka легко интегрируется с этой концепцией, и для ее запуска достаточно трех линий конфигурации. Проблемы, возникшие в ходе процесса, аккуратно решены с помощью обширной документации от команды проекта, а также с множеством вопросов по Stackoverflow. И последнее, но не менее важное: в Spring есть комплексная интеграция, которая не оставляет желаний невыполненными.

С SI, наоборот, документация для интеграции Kafka довольно интенсивна и все еще не в состоянии ясно объяснить, как интегрировать Kafka. Интеграция Кафки нажимается в SI-способ делать вещи, что добавляет дополнительную сложность. Другая документация, например, о Stackoverflow, также менее распространена и менее полезна, чем для Camel.

Мой вывод: сапожник придерживается вашей профессии - используйте Spring в качестве контейнера и Camel в качестве основы для системной интеграции.

Фриц Дюшардт
источник
3
Спасибо, Фриц, за то, что поделились своим опытом! Я искренне согласен с вашими наблюдениями: Camel очень чист с точки зрения своих основных концепций, а также обеспечивает экосистему жизнеспособных компонентов для многих задач под рукой (соответственно, позволяет легко подключиться, если вы хотите настроить определенные процедуры).
ngeek
15

Это действительно зависит от того, что вы хотите сделать. Если вам нужно что-то расширить, чтобы создать собственное решение для обмена сообщениями, Spring Integration имеет лучшую модель программирования. Если вам нужно что-то, что поддерживает множество протоколов без специального кода, Camel опережает Spring Integration.

Небольшая перестрелка - очень хорошая идея, просто убедитесь, что вы пытаетесь делать то, что обычно делаете в проекте.

--disclaimer: я коммиттер Spring Integration

Iwein
источник
9

Большинство сравнений Camel и SI, которые я видел, не учитывают следующее:

1.) Влияние Spring Boot на производительность разработчика для Spring Integration

2.) Эффект Spring XD оказал влияние на то, чтобы приложения Spring Integration были доступны без компиляции кода - также источники и приемники Spring XD - это просто адаптеры каналов Spring Integration, если вы хотите расширить Spring XD.

3.) Влияние Spring XD на объединение Spring Integration, Spring Batch, Spring Data (+ Hadoop!) В одном стеке, эффективное объединение пакетной и потоковой обработки, поддержку HDFS / Apache Hadoop и многое другое в Spring Integration.

4.) Эффект Java-DSL Spring Integration 4.0, который скоро будет выпущен, https://github.com/spring-projects/spring-integration-extensions/wiki/Spring-Integration-Java-DSL-Reference

На ваш взгляд,

/ Питер (отказ от ответственности, я работаю на Pivotal)

PivotalPieter
источник
3
Java DSL требует много работы и еще больше документации, прежде чем это следует учитывать.
открытки
Это выпущено некоторое время теперь ... spring.io/blog/2014/11/24/…
Питер Сзэнто
6

Мы используем Spring Integration для нашего приложения и теперь планируем перейти на Apache Camel, поскольку столкнулись с множеством проблем со средой Spring Integration. Вот пара вопросов.

  1. CachingConnectionFactory, предоставляемый Spring, открывает тысячи незанятых соединений в IBM MQ, и нет никакой гарантии, что эти соединения будут использованы повторно. И все же эти связи будут оставаться открытыми навсегда, что создает проблемы на стороне MQ. Приходилось перезапускать приложение каждую неделю в более низких средах, чтобы просто обновить соединения. Apache Camel также обеспечивает кэширование, и кажется, что соединения увеличиваются / уменьшаются в зависимости от нагрузки.

  2. Spring не предоставляет картографы для параметров QoS. Даже если вы включите QoS, режим доставки и свойства expiration / timetolive будут потеряны (я собираюсь поднять проблему JIRA для этого). Apache Camel обрабатывает это, и параметры QoS отправляются в исходящие приложения, а не отбрасываются.

Сейчас я работаю над проблемами обработки исключений и транзакций с Apache Camel, которые Spring, похоже, лучше справляется с AOP.

Selvakumar
источник
Была ли какая-либо неверная конфигурация, которая приводила к открытию незанятых соединений в IBM MQ.
Harpreet Sandhu - TheRootCoder
4

На самом деле, я бы сказал, что FTP закончил свой инкубационный период. Вы можете выполнить простой поиск на форумах SI / JIRA, чтобы увидеть, какие новые функции были реализованы и исправлены ошибки. Судя по разным болтовням, кажется, что уже есть какое-то использование в производстве, поэтому я бы посоветовал ему еще раз взглянуть на него и, конечно, сообщить нам о своих проблемах через

http://forum.springsource.org/forumdisplay.php?42-Integration
https://jira.springsource.org/browse/INT

Ура Олег

Отказ от ответственности: я коммиттер Spring Integration

Олег Жураковский
источник
4

Apache Camel - очень хороший фреймворк и очень полный. Но если ваше приложение использует Spring, мой личный совет - использовать Spring Integration.

Spring Integration является интегрированной средой обработки жалоб EIP в экосистеме Spring-Source. Отличная интеграция с экосистемой: Spring boot, Batch, XD; даже ядро ​​использует ту же абстракцию, начиная с Spring Framework 4. Некоторые из абстракций обмена сообщениями были перемещены в фреймворк в качестве доказательства того, что базовая абстракция обмена сообщениями в Spring Integration очень сильна. Теперь Spring Framework, например, использует абстракцию обмена сообщениями для Spring Web, поддержку веб-сокетов.

Еще одна полезная вещь в приложении Spring с интеграцией Spring для использования Apache Camel заключается в том, что с интеграцией Spring можно использовать только один контекст приложения. Помните, что Camel Context - это контекст Spring. если у вас есть возможность использовать новую версию Spring, я предлагаю использовать Spring Integration Java DSL для конфигурации. Я использую это в моих новых проектах, и это чувствует себя более читабельным и ясным. Я надеюсь, что это отражение поможет вам в ваших оценках.

Валерио Вауди
источник
1

Одна из причин использовать Camel поверх Spring Integration - когда вам нужен более функциональный набор EIP. Spring Integration не предоставляет абстракций над такими вещами, как ThreadPool.

Camel предоставляет дополнительные конструкции для этого, упрощая некоторые аспекты работы с параллельным кодом:

http://camel.apache.org/camel-23-threadpool-configuration.html

Если вам не нужны такие вещи и вы просто хотите подключить файл, JMS, конечные точки FTP и т. Д., Тогда просто используйте Spring Integration.

Джон
источник
2
У вас есть абстракция над самими ThreadPools в SI-поллерах и исполнителях задач из Spring. Ничего предварительно не настроено для вас OOTB в СИ, хотя. См. Исполнителя задачи, настроенного здесь: static.springsource.org/spring-integration/docs/2.1.x/reference/…
cwash
@Jon, не могли бы вы взглянуть на мой пост на JMS
ученик
-1

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

sudhirkondle
источник
-3

Если ваше текущее приложение находится в Spring и требует функций, которые поддерживаются Spring Integration EIP, тогда Spring Integration является лучшим вариантом, в противном случае требуются сторонние поддержки / протоколы / форматы файлов и т. Д.

Венката Парватам
источник
Camel действительно имеет отличную поддержку Spring и охватывает множество сторонних компонентов.
MikeHoss