Spring Integration не использовал, поэтому предметно сравнить не могу. Когда выбирали Camel для построения интеграционной платформы, у меня тоже возникал вопрос, что выбрать – SI или Camel. В интернете можно найти обсуждения на эту тему, пишут, что у Camel шире функционал, что он проще и удобнее в применении, и что комьюнити больше. Подтвердить или опровергнуть выводы не могу. В целом, сложилось впечатление, что Camel более распространен. Комьюнити действительно большое, зачастую на stackoverflow и camel nabble можно найти ответ на интересующий вопрос быстрее, чем в документации.
Транзакции нужно использовать, но не нужно воспринимать их, как панацею. Падение системы в неудачный момент всегда чревато потерями данных, и наличие транзакции не гарантирует защиту от этого. Это в равной мере относится и к интеграционной платформе и к информационным системам, в которых тоже случаются сбои. Поэтому сверки нужны обязательно.
Нужно понимать, что транзакции не всегда хорошо. Любая транзакция потребляет ресурсы и сказывается на скорости обработки. Есть кейсы, когда применять транзакции нельзя, например, передача тиковых цен бумаг, торгующихся на бирже. Цены могут меняться по сотни и тысячи раз за секунду, в этом случае потеря единичных сообщений не критичны, а вот скорость доставки актуальной цены до получателя очень важна.
К обменам, в которых критичны потери данных, должно быть соответствующее критичное отношение, которое не ограничивается только передачей данных в транзакции. Такие обмены должны пристально мониториться и всегда должны быть механизмы решения возникающих проблем. Если бы мы жили в идеальном мире, не нужны бы были подразделения поддержки, администраторы баз данных и т.д. В нашем случае, все сообщения, которые передаются через ServiceMix, логируются и доступны для последующего анализа. Настроены аллерты, которые срабатывают при возникновении нештатных ситуация, плюс есть функционал, который позволяет повторно отправлять сообщения.
Что касается потерь данных в RabbitMQ компоненте. Мы регулярно проводим тесты, роняем сервера ServiceMix при нагруженных обменах. Потерь не наблюдали.
Игорь, рад видеть тебя здесь.
В Camel есть поддержка транзакций. Любой роут можно определить транзакционным, в этом случае, при возникновении ошибки происходит откат транзакции. Нужен только менеджер транзакций. Можно организовывать XA транзакции с несколькими дата сорсами. Что касается RabbitMQ, то он не поддерживает XA транзакции, но поддерживает обычные транзакции. Это позволяет в случае возникновения ошибки откатить транзакцию в дата сорсах и либо вернуть сообщение в исходную очередь для повторной обработки, либо в отдельную очередь для последующего разбора ошибки. Для наших задач этого вполне достаточно. Кроме того, ни одна технология не гарантирует 100% надежности, поэтому сверки между системами – полезная практика.
Мы поступаем следующим образом. Разработка ведется локально. Java бины отлаживаются и тестируются, как standalone приложения (в pom прописываются зависимости аналогичные OSGi окружению). Также у каждого разработчика локально развернут ServiceMix, в котором отлаживаются роуты и решение целиком. Для отладки можно использовать remote debugging из IDE и инструмент hawtio.
С тестированием дело обстоит сложнее. У Camel есть фреймворки для тестирования: Идея простая – можно мокать эндпоинты, посылать тестовые сообщения в роуты, и в мок энпоинтах сравнивать пришедшее сообщение с ожидаемым. Таким образом проверять, как отрабатывают роуты, не допуская отправки тестовых сообщений в реальные интегрируемые системы. При запуске тестов эмулируется OSGi окружение, в котором выполняются тесты. Но эмулируемое окружение не до конца соответствует реальному, поэтому нам это не подошло. Мы написали свой фреймворк для тестирования, он позволяет делать тоже самое, но тесты запускаются в реальном OSGi контейнере.
Мы смотрели оба продукта. Для нас была критична отказоустойчивость, чтобы можно было собрать кластер, который сохраняет полную работоспособность при падении одной из нод. У ActiveMQ есть возможность работать в кластере, для его работы требуется общее хранилище, которым может быть: сетевой диск, база данных или Zookeeper. Нужно было перебирать эти варианты и тестировать, чтобы выбрать наиболее подходящий, а во времени мы были ограничены. Для настройки кластера RabbitMQ ничего из вышеперечисленного не требуется, ноды синхронизируются через сокеты. Что очень важно, RabbitMQ в кластерной конфигурации с синхронизацией очередей показал лучшую производительность, чем ActiveMQ. Кроме того, подкупило то, что у RabbitMQ есть хорошая web консоль c широкими возможностями администрирования и с большим набором различных метрик.
Да, можно взять karaf и задеплоить необходимые бандлы, получится тот же самый ServiceMix. Тут никакой магии нет. Воспринимайте ServiceMix, как докер образ с настроенным окружением, который можно взять для быстрого старта, чтобы не заниматься предварительной настройкой.
Транзакции нужно использовать, но не нужно воспринимать их, как панацею. Падение системы в неудачный момент всегда чревато потерями данных, и наличие транзакции не гарантирует защиту от этого. Это в равной мере относится и к интеграционной платформе и к информационным системам, в которых тоже случаются сбои. Поэтому сверки нужны обязательно.
Нужно понимать, что транзакции не всегда хорошо. Любая транзакция потребляет ресурсы и сказывается на скорости обработки. Есть кейсы, когда применять транзакции нельзя, например, передача тиковых цен бумаг, торгующихся на бирже. Цены могут меняться по сотни и тысячи раз за секунду, в этом случае потеря единичных сообщений не критичны, а вот скорость доставки актуальной цены до получателя очень важна.
К обменам, в которых критичны потери данных, должно быть соответствующее критичное отношение, которое не ограничивается только передачей данных в транзакции. Такие обмены должны пристально мониториться и всегда должны быть механизмы решения возникающих проблем. Если бы мы жили в идеальном мире, не нужны бы были подразделения поддержки, администраторы баз данных и т.д. В нашем случае, все сообщения, которые передаются через ServiceMix, логируются и доступны для последующего анализа. Настроены аллерты, которые срабатывают при возникновении нештатных ситуация, плюс есть функционал, который позволяет повторно отправлять сообщения.
Что касается потерь данных в RabbitMQ компоненте. Мы регулярно проводим тесты, роняем сервера ServiceMix при нагруженных обменах. Потерь не наблюдали.
В Camel есть поддержка транзакций. Любой роут можно определить транзакционным, в этом случае, при возникновении ошибки происходит откат транзакции. Нужен только менеджер транзакций. Можно организовывать XA транзакции с несколькими дата сорсами. Что касается RabbitMQ, то он не поддерживает XA транзакции, но поддерживает обычные транзакции. Это позволяет в случае возникновения ошибки откатить транзакцию в дата сорсах и либо вернуть сообщение в исходную очередь для повторной обработки, либо в отдельную очередь для последующего разбора ошибки. Для наших задач этого вполне достаточно. Кроме того, ни одна технология не гарантирует 100% надежности, поэтому сверки между системами – полезная практика.
С тестированием дело обстоит сложнее. У Camel есть фреймворки для тестирования: Идея простая – можно мокать эндпоинты, посылать тестовые сообщения в роуты, и в мок энпоинтах сравнивать пришедшее сообщение с ожидаемым. Таким образом проверять, как отрабатывают роуты, не допуская отправки тестовых сообщений в реальные интегрируемые системы. При запуске тестов эмулируется OSGi окружение, в котором выполняются тесты. Но эмулируемое окружение не до конца соответствует реальному, поэтому нам это не подошло. Мы написали свой фреймворк для тестирования, он позволяет делать тоже самое, но тесты запускаются в реальном OSGi контейнере.