Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 35
Никогда не понимал, зачем берут именно ServiceMix (или скажем Fuse)? Просто karaf настраивается до такого же состояния очень быстро. Я работал над проектами с чистым karaf и с Fuse, и не заметил никакой разницы ровным счетом, кроме того, что версия Camel (и всего остального что с этим связано) была дремучая до ужаса.
Да, можно взять karaf и задеплоить необходимые бандлы, получится тот же самый ServiceMix. Тут никакой магии нет. Воспринимайте ServiceMix, как докер образ с настроенным окружением, который можно взять для быстрого старта, чтобы не заниматься предварительной настройкой.
Ну я так и воспринимаю. Просто мой опыт с Fuse vs Karaf мне показал, что даже платная Fuse ровным счетом ничего не дает. Все равно, вы сами ставите (причем не бандлы, и фичи, что сильно крупнее), или по умолчанию что-то стоит, но рано или поздно хочется скажем camel обновить. И вот с этим все уже не очень просто. Обычно проще новый контейнер рядом развернуть, туда все задеплоить еще раз, и переключиться.
Единственный плюс это поддержка(формально важна в банках при выборе решения, реально я не сталкивался чтобы ею пользовались) и раньше была IDE для роутов на базе эклипса. А так да, компоненты там с плесенью, стабильные…
Я сам из банка. От той поддержки толку как от козла молока… Например, купили Fuse 6, который официально поддерживает Java 6, Camel внутри что-то типа 2.10, karaf из семейства 2.x. С тех пор, что называется, много воды утекло, и в новом карафе, и в новом camel исправлено много больше багов, чем зарепортили той поддержке.
Чтобы штатно перейти на Java 8 (а мы же знаем, что уже и 7 не поддерживается пару лет, да и 8 осталось жить считанные месяцы возможно), нужно например купить Fuse 7.
Ну т.е. может кому-то это и нужно, чтобы подстраховаться, а на уровне разработчика толку почти 0.
Причем, поскольку у карафа есть скажем ssh консоль, это означает, что все процессы, которые делаются из консоли, можно легко автоматизировать груви скриптами, используя например ssh plugin от gradle. То есть, имея допустим установленный ServiceMix, я могу запустить скрипт, который получит список развернутых там фич и бандлов, с их maven координатами, и повторит это на голом karaf.
Чтобы штатно перейти на Java 8 (а мы же знаем, что уже и 7 не поддерживается пару лет, да и 8 осталось жить считанные месяцы возможно), нужно например купить Fuse 7.
Ну т.е. может кому-то это и нужно, чтобы подстраховаться, а на уровне разработчика толку почти 0.
Причем, поскольку у карафа есть скажем ssh консоль, это означает, что все процессы, которые делаются из консоли, можно легко автоматизировать груви скриптами, используя например ssh plugin от gradle. То есть, имея допустим установленный ServiceMix, я могу запустить скрипт, который получит список развернутых там фич и бандлов, с их maven координатами, и повторит это на голом karaf.
С точки зрения разработчика я полностью согласен. С точки зрения менеджмента это выглядит непривычно, не платить за поддержку. Это так же как и с oracle coherence я тоже только страдал и декомпилировал, чтобы выжить. А менеджмент был счастлив что куплена «поддержка»
Вы не наследие тройки диалог поддерживаете случаем?
Поддерживал. Частично.
Забавно, значит не там много 6 джавы на рынке как я думал. Угадал с первой попытки.
Думаю, еще и такой набор продуктов, как я описал, довольно специфичный.
Да и то, у меня вот было два проекта, один так сказать legacy, а второй развертывался фактически с нуля — и во втором уже не было ни древней версии Fuse (а просто karaf 3.x), ни такой же древней версии QPID (с удовольствием заменена на ActiveMQ), и Java почти с самого начала уже была 8.
Да и в старом проекте Java 6 уже обновлялась понемногу, потому как узких мест, которые на нее конкретно завязаны все-таки совсем немного. Помнится, какая-то криптография, которую надо было взять новее, да и все пожалуй — а в целом даже и старый Fuse 6 вполне работает хотя бы на Java 7.
P.S. Я слышал, что кое-кто все еще сидит на EJB 2. Вот это уже засада так засада. В моих проектах на EJB 3 мигрировали кажется в 2009, не позже, причем с большой радостью, потому как это было упрощение. А ведь кто-то уже 9 лет с тех пор каждый день живет с проблемами.
Да и то, у меня вот было два проекта, один так сказать legacy, а второй развертывался фактически с нуля — и во втором уже не было ни древней версии Fuse (а просто karaf 3.x), ни такой же древней версии QPID (с удовольствием заменена на ActiveMQ), и Java почти с самого начала уже была 8.
Да и в старом проекте Java 6 уже обновлялась понемногу, потому как узких мест, которые на нее конкретно завязаны все-таки совсем немного. Помнится, какая-то криптография, которую надо было взять новее, да и все пожалуй — а в целом даже и старый Fuse 6 вполне работает хотя бы на Java 7.
P.S. Я слышал, что кое-кто все еще сидит на EJB 2. Вот это уже засада так засада. В моих проектах на EJB 3 мигрировали кажется в 2009, не позже, причем с большой радостью, потому как это было упрощение. А ведь кто-то уже 9 лет с тех пор каждый день живет с проблемами.
Меня всегда интересовал вопрос, как правильно поставить процесс разработки и тестирования в приложении с OSGi-контейнером? Модуль после каждого изменения приходится запаковывать и передеплоивать. Кроме того нет возможности стартануть контейнер из workspace с подцепленным classpath модуля, соответственно невозможно будет дебажить в IDE, или делать hot replace. Даже в JEE есть такие средства как Arquillian, OpenEJB, Microprofile, которые сильно упрощают разработку...
Мы поступаем следующим образом. Разработка ведется локально. Java бины отлаживаются и тестируются, как standalone приложения (в pom прописываются зависимости аналогичные OSGi окружению). Также у каждого разработчика локально развернут ServiceMix, в котором отлаживаются роуты и решение целиком. Для отладки можно использовать remote debugging из IDE и инструмент hawtio.
С тестированием дело обстоит сложнее. У Camel есть фреймворки для тестирования: Идея простая – можно мокать эндпоинты, посылать тестовые сообщения в роуты, и в мок энпоинтах сравнивать пришедшее сообщение с ожидаемым. Таким образом проверять, как отрабатывают роуты, не допуская отправки тестовых сообщений в реальные интегрируемые системы. При запуске тестов эмулируется OSGi окружение, в котором выполняются тесты. Но эмулируемое окружение не до конца соответствует реальному, поэтому нам это не подошло. Мы написали свой фреймворк для тестирования, он позволяет делать тоже самое, но тесты запускаются в реальном OSGi контейнере.
С тестированием дело обстоит сложнее. У Camel есть фреймворки для тестирования: Идея простая – можно мокать эндпоинты, посылать тестовые сообщения в роуты, и в мок энпоинтах сравнивать пришедшее сообщение с ожидаемым. Таким образом проверять, как отрабатывают роуты, не допуская отправки тестовых сообщений в реальные интегрируемые системы. При запуске тестов эмулируется OSGi окружение, в котором выполняются тесты. Но эмулируемое окружение не до конца соответствует реальному, поэтому нам это не подошло. Мы написали свой фреймворк для тестирования, он позволяет делать тоже самое, но тесты запускаются в реальном OSGi контейнере.
В тестировании под OSGI нет почти никакой специфики. Во-первых, большинство бандлов в моей практике вообще ничего не знали о наличии контейнера — т.е. мы их тестируем в виде юнит тестов, без контейнера. Те же, которым нужен OSGI API, скажем, они пользуются сервисами 0..N, тестируются в контейнере с той же легкостью, как JEE тестируется там же начиная примерно с EJB 3.
А я бы сказал, что и легче. Можно как в имеющийся контейнер задеплоиться, так и новый поднять (что зависит от нужного окружения, ибо нафига нам обычно для тестирования контейнер, если в нем других бандлов нет?)
Запаковывать и передеплоивать? Ну хм, да, нужно. Это обычно настолько быстро, тем более все равно компилировать же.
>нет возможности стартануть контейнер из workspace с подцепленным classpath модуля
classpath модуля зависит от того, какие бандлы вы установили. IDE про это может ничего и не знать. Но вполне может и знать. Для IDEA есть соответствующая поддержка (правда, только в платной версии).
Дебажить, hot replace? Всегда делал, никаких серьезных проблем не испытывал. Что я делал не так?
А я бы сказал, что и легче. Можно как в имеющийся контейнер задеплоиться, так и новый поднять (что зависит от нужного окружения, ибо нафига нам обычно для тестирования контейнер, если в нем других бандлов нет?)
Запаковывать и передеплоивать? Ну хм, да, нужно. Это обычно настолько быстро, тем более все равно компилировать же.
>нет возможности стартануть контейнер из workspace с подцепленным classpath модуля
classpath модуля зависит от того, какие бандлы вы установили. IDE про это может ничего и не знать. Но вполне может и знать. Для IDEA есть соответствующая поддержка (правда, только в платной версии).
Дебажить, hot replace? Всегда делал, никаких серьезных проблем не испытывал. Что я делал не так?
Вадим, это реально не современное решение! Расскажи лучше людям про не поддерживаемые транзакции в Camel RabbitMQ компоненте и что всю сложность по реконсиляциям и взаимодействию перекладываешь на интегрируемые системы...
Игорь, рад видеть тебя здесь.
В Camel есть поддержка транзакций. Любой роут можно определить транзакционным, в этом случае, при возникновении ошибки происходит откат транзакции. Нужен только менеджер транзакций. Можно организовывать XA транзакции с несколькими дата сорсами. Что касается RabbitMQ, то он не поддерживает XA транзакции, но поддерживает обычные транзакции. Это позволяет в случае возникновения ошибки откатить транзакцию в дата сорсах и либо вернуть сообщение в исходную очередь для повторной обработки, либо в отдельную очередь для последующего разбора ошибки. Для наших задач этого вполне достаточно. Кроме того, ни одна технология не гарантирует 100% надежности, поэтому сверки между системами – полезная практика.
В Camel есть поддержка транзакций. Любой роут можно определить транзакционным, в этом случае, при возникновении ошибки происходит откат транзакции. Нужен только менеджер транзакций. Можно организовывать XA транзакции с несколькими дата сорсами. Что касается RabbitMQ, то он не поддерживает XA транзакции, но поддерживает обычные транзакции. Это позволяет в случае возникновения ошибки откатить транзакцию в дата сорсах и либо вернуть сообщение в исходную очередь для повторной обработки, либо в отдельную очередь для последующего разбора ошибки. Для наших задач этого вполне достаточно. Кроме того, ни одна технология не гарантирует 100% надежности, поэтому сверки между системами – полезная практика.
Это все ясно, что RabbitMQ это умеет. Отлично знаю фичи Camel. Но в том что ты описываешь это не работает, так как в компоненте Camel-RabbitMQ до сих пор нет транзакционных продюсеров и консьюмеров… Так что похоже у вас на уровне шины возможны потери данных. По опыту работы серьезных международных инвестбанков, гарантии Exactly once или At Least Once должны быть в MOM/транспорте между системами, а в этом случае при падении servicemix сообщения заберутся из очереди и потеряются. Это деньги и репутация организации! Переносить ответственность транспорта и шины на интегрируемые системы не правильно!
Также интеграционное решение по хорошему должно уменьшать сложность интегрируемых систем и централизовать множество функций, как то: трансформация и обогащение данных, концентрируя экспертизу и удешевляя разработку общего решения.
100% гарантий не бывает, но 99 с множеством 9 в периоде вполне! И к этому надо стремиться, а не пытаться переносить ответственность на интегрируемые системы)
Также интеграционное решение по хорошему должно уменьшать сложность интегрируемых систем и централизовать множество функций, как то: трансформация и обогащение данных, концентрируя экспертизу и удешевляя разработку общего решения.
100% гарантий не бывает, но 99 с множеством 9 в периоде вполне! И к этому надо стремиться, а не пытаться переносить ответственность на интегрируемые системы)
Ты очень узко видишь проблему.
Транзакции нужно использовать, но не нужно воспринимать их, как панацею. Падение системы в неудачный момент всегда чревато потерями данных, и наличие транзакции не гарантирует защиту от этого. Это в равной мере относится и к интеграционной платформе и к информационным системам, в которых тоже случаются сбои. Поэтому сверки нужны обязательно.
Нужно понимать, что транзакции не всегда хорошо. Любая транзакция потребляет ресурсы и сказывается на скорости обработки. Есть кейсы, когда применять транзакции нельзя, например, передача тиковых цен бумаг, торгующихся на бирже. Цены могут меняться по сотни и тысячи раз за секунду, в этом случае потеря единичных сообщений не критичны, а вот скорость доставки актуальной цены до получателя очень важна.
К обменам, в которых критичны потери данных, должно быть соответствующее критичное отношение, которое не ограничивается только передачей данных в транзакции. Такие обмены должны пристально мониториться и всегда должны быть механизмы решения возникающих проблем. Если бы мы жили в идеальном мире, не нужны бы были подразделения поддержки, администраторы баз данных и т.д. В нашем случае, все сообщения, которые передаются через ServiceMix, логируются и доступны для последующего анализа. Настроены аллерты, которые срабатывают при возникновении нештатных ситуация, плюс есть функционал, который позволяет повторно отправлять сообщения.
Что касается потерь данных в RabbitMQ компоненте. Мы регулярно проводим тесты, роняем сервера ServiceMix при нагруженных обменах. Потерь не наблюдали.
Транзакции нужно использовать, но не нужно воспринимать их, как панацею. Падение системы в неудачный момент всегда чревато потерями данных, и наличие транзакции не гарантирует защиту от этого. Это в равной мере относится и к интеграционной платформе и к информационным системам, в которых тоже случаются сбои. Поэтому сверки нужны обязательно.
Нужно понимать, что транзакции не всегда хорошо. Любая транзакция потребляет ресурсы и сказывается на скорости обработки. Есть кейсы, когда применять транзакции нельзя, например, передача тиковых цен бумаг, торгующихся на бирже. Цены могут меняться по сотни и тысячи раз за секунду, в этом случае потеря единичных сообщений не критичны, а вот скорость доставки актуальной цены до получателя очень важна.
К обменам, в которых критичны потери данных, должно быть соответствующее критичное отношение, которое не ограничивается только передачей данных в транзакции. Такие обмены должны пристально мониториться и всегда должны быть механизмы решения возникающих проблем. Если бы мы жили в идеальном мире, не нужны бы были подразделения поддержки, администраторы баз данных и т.д. В нашем случае, все сообщения, которые передаются через ServiceMix, логируются и доступны для последующего анализа. Настроены аллерты, которые срабатывают при возникновении нештатных ситуация, плюс есть функционал, который позволяет повторно отправлять сообщения.
Что касается потерь данных в RabbitMQ компоненте. Мы регулярно проводим тесты, роняем сервера ServiceMix при нагруженных обменах. Потерь не наблюдали.
Нужно понимать, что транзакции не всегда хорошо. Любая транзакция потребляет ресурсы и сказывается на скорости обработки
Конечно, у гарантий доставки есть своя цена. Следуя вашей логике нужно обложиться велосипедами, назначить ответственных и забить на транзакции совсем. А в учётных системах банка отключить целостность и внешние ключи, они же много ресурсов потребляют же. Настроить алерты, пусть сотрудники ночью во всех системах вручную восстанавливаются.
Только в этом случае ни RabbitMQ не нужен, не реляционные БД. Это совсем другая область применимости и другой класс систем.
Что касается потерь данных в RabbitMQ компоненте.
Вся интеграция сделана через это место, судя по комментариям и статье.
Вадим, крайне непрофессиональный подход к интеграции…
Спасибо, расширил мое видение проблемы, вдохновил на публикацию!
А из того что доступно в open-source на данный момент, можете что то порекомендовать?
То же самое, но «приготовленное» несколько иначе. Fabric8.io, например груви роуты проще отлаживать и работают все фичи из IntelliJ Idea при редактировании. Ну и RabbitMQ не лучшее решение для camel, по причинам что указал. ActiveMQ Artemis в качестве очереди сообщений. Apache Camel отличный фреймворк для интеграции чего угодно! И подход к интеграции более гуманный к интегрируемым системам, чем используется у автора статьи.
А XML контекст спринга, так подавно веет 2000ми!
Ну кстати, в отличие от обычного спринга, xml контекст можно деплоить в караф самого по себе. Т.е. без jar вовсе. И это чрезвычайно удобно. Если же хочется модного и молодежного — то blueprint по сути все тоже самое дает.
Спасибо за разъяснения, но к счастью, я работал с karaf, jboss fuse, fabric8. Blueprint xml той же «молодежном и» что и spring xml context, очень похожий DI и так же позволяет не привязываться в коде к OSGI API и активаторам, как и спринг.
Ну я тогда не понял, о чем именно был намек на XML, как артефакт из 2000-х?
Иметь именно что голый XML, который представляет из себя совершенно полноценный бандл (ну, плюс-минус OSGI метаданные) — это же иногда реально необычайно удобно. Его еще и компилировать не нужно :)
Иметь именно что голый XML, который представляет из себя совершенно полноценный бандл (ну, плюс-минус OSGI метаданные) — это же иногда реально необычайно удобно. Его еще и компилировать не нужно :)
В его поддержке в IDE при разработке роутов. Груви тоже не нужно компилировать, а вот автодополнения для DSL camel работают даже в IntelliJ Community!
А, я понял. Да, сами роуты наверное лучше не так делать, как тут автор расписал. Ну т.е. так тоже можно, и даже приятно, что они все еще работают в том же виде, после многих лет развития camel. Но уже какой-никакой split в xml делать — фу.
P.S. Community не поддерживает Spring полноценно, но автодополнения camel xml из схемы вроде берутся? В смысле, они там тоже работают.
P.S. Community не поддерживает Spring полноценно, но автодополнения camel xml из схемы вроде берутся? В смысле, они там тоже работают.
а почему используете rabbitmq, а не activemq от того же апача?
Мы смотрели оба продукта. Для нас была критична отказоустойчивость, чтобы можно было собрать кластер, который сохраняет полную работоспособность при падении одной из нод. У ActiveMQ есть возможность работать в кластере, для его работы требуется общее хранилище, которым может быть: сетевой диск, база данных или Zookeeper. Нужно было перебирать эти варианты и тестировать, чтобы выбрать наиболее подходящий, а во времени мы были ограничены. Для настройки кластера RabbitMQ ничего из вышеперечисленного не требуется, ноды синхронизируются через сокеты. Что очень важно, RabbitMQ в кластерной конфигурации с синхронизацией очередей показал лучшую производительность, чем ActiveMQ. Кроме того, подкупило то, что у RabbitMQ есть хорошая web консоль c широкими возможностями администрирования и с большим набором различных метрик.
ActiveMQ Artemis не требует zookeeper и NFS…
У ActiveMQ консоль тоже вполне хорошая. И потом, JMX же, многим можно рулить через него и Hawtio.
Рассматривали ли Вы реализацию шины на Spring Integration? Хотелось бы сравнить двух этих монстров
Spring Integration не использовал, поэтому предметно сравнить не могу. Когда выбирали Camel для построения интеграционной платформы, у меня тоже возникал вопрос, что выбрать – SI или Camel. В интернете можно найти обсуждения на эту тему, пишут, что у Camel шире функционал, что он проще и удобнее в применении, и что комьюнити больше. Подтвердить или опровергнуть выводы не могу. В целом, сложилось впечатление, что Camel более распространен. Комьюнити действительно большое, зачастую на stackoverflow и camel nabble можно найти ответ на интересующий вопрос быстрее, чем в документации.
Ну, как вы представляете себе это «рассматривали»? Вот я достаточно прилично знаю Camel, плотно проработал с ним несколько лет, и продолжу, если будет подходящая задача. На Spring Integration только смотрел, и могу спокойно сказать только одно — это похожие вещи, с похожими идеями. Но чтобы перетащить на него готовый проект на camel, потребуется некоторое время, вероятно немаленькое. Я прикидывал когда-то, можно ли получить от этого преимущества, пришел к выводу, что для моего проекта нельзя, и на этом успокоился. Но для других условий это может оказаться и не так.
На мой взгляд он несколько сильнее привязывает вас к своему API, даже там, где это не нужно по смыслу (когда вы описываете маршруты обработки сообщений, например — то привязка к API осмысленна, конкретные же обработчики не должны по большому счету от API зависеть). Но тут я могу чего-то не знать, может есть способы решить эту проблему.
И еще остановило то, что мне попадалось намного меньше примеров проектов на SI, нежели на camel. Это чисто субъективно, и я опять же могу тут ошибаться.
На мой взгляд он несколько сильнее привязывает вас к своему API, даже там, где это не нужно по смыслу (когда вы описываете маршруты обработки сообщений, например — то привязка к API осмысленна, конкретные же обработчики не должны по большому счету от API зависеть). Но тут я могу чего-то не знать, может есть способы решить эту проблему.
И еще остановило то, что мне попадалось намного меньше примеров проектов на SI, нежели на camel. Это чисто субъективно, и я опять же могу тут ошибаться.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Опыт построения интеграционной платформы на базе ServiceMix (Camel) и RabbitMQ