Comments 10
Хорошее начало цикла статей, спасибо!
Оправдано ли в вашем случае использование JMS как транспорта для выгружаемых данных? Не возникнут ли проблемы с памятью если объем данных резко вырастет?
Для прототипа, конечно, это приемлемо.
Оправдано ли в вашем случае использование JMS как транспорта для выгружаемых данных? Не возникнут ли проблемы с памятью если объем данных резко вырастет?
Для прототипа, конечно, это приемлемо.
Мы добивались для JMS скорости работы примерно 50 TPS (транзакций в секунду) при передаче между разными сервисами, запускясь на обычном соверменном ноутбуке. Так что все там ок и с памятью и с хранилищем (у нас тоже KahaDB). Только надо правильно брокер настраивать и роуты в плане транзакционности. Особенно если с одного конца роута JMS а с другого например база данных, тогда уже надо поднимать менеджер распределенных транзакций, ну и это чуть медленнее. Мы для этого atomikos использовали.
Видимо я не точно описал проблему. Имел ввиду увеличение в объеме самого JMS сообщения. Обработка данных происходит в памяти и на это нужно обращать внимание. Проблема еще более обостряется когда интегрированных систем становится много и соответственно много обработчиков данных работает в рамках одной JVM.
Если данные большие, то безопасней переместить их из одной систему в другую (например в файловую систему), обработать, и только потом направить дальше. Впрочем, ниже coriollon уточнил, что в его случае объем не превышает нескольких мегабайт в день и поэтому данный подход приемлем.
Если данные большие, то безопасней переместить их из одной систему в другую (например в файловую систему), обработать, и только потом направить дальше. Впрочем, ниже coriollon уточнил, что в его случае объем не превышает нескольких мегабайт в день и поэтому данный подход приемлем.
Спасибо за комментарий.
Наша система развивается с 2006 года и объём выгружаемых данных не превышает нескольких мегабайт в день. Поэтому такой сценарий практически невозможен.
Мы используем ActiveMQ в качестве JMS брокера и KahaDB в качестве персистентного хранилища брокера. С уверенностью можно утверждать, что даже если объём данных увеличится на порядок, шина с ним справится. Моя уверенность подтверждается нагрузочными тестами, которые мы проводили перед релизом.
Подробнее о сложностях связанных с ростом нагрузки, а также о полезных настройках брокера будет в третьей части.
Наша система развивается с 2006 года и объём выгружаемых данных не превышает нескольких мегабайт в день. Поэтому такой сценарий практически невозможен.
Мы используем ActiveMQ в качестве JMS брокера и KahaDB в качестве персистентного хранилища брокера. С уверенностью можно утверждать, что даже если объём данных увеличится на порядок, шина с ним справится. Моя уверенность подтверждается нагрузочными тестами, которые мы проводили перед релизом.
Подробнее о сложностях связанных с ростом нагрузки, а также о полезных настройках брокера будет в третьей части.
Интересное начало! Мы сейчас как раз на распутье, рассматриваем разные ESB. После первой итерации и сравнения разных решений очень убедительно выглядит ServiceMix и его дерриваты (JBoss Fuse, fabric8, Talend ESB). Если коротко, ServiceMix это не только верблюд, но и 3-4 кг диетического, легкоусвояемого мяса но это очень удачная связка, которая включает в себя:
— ActiveMQ, надежный JMS брокер, настроенный «под ключ»
— Apache CXF, для WS‐* and RESTful services
— Karaf, легкий osgi контейнер, который вмещает в себя весь этот зоопарк, и, видимо, упрощает его администрирование
А какая у Вас обвязка вокруг Camel?
— ActiveMQ, надежный JMS брокер, настроенный «под ключ»
— Apache CXF, для WS‐* and RESTful services
— Karaf, легкий osgi контейнер, который вмещает в себя весь этот зоопарк, и, видимо, упрощает его администрирование
А какая у Вас обвязка вокруг Camel?
Fabric8 — это собственно не сама ESB, а средство управления кластером.
Главные риски — OSGI. На словах и в теории (часто и на практике, если круг задач узок и типичен) это круто, модульно и деплоебельно. Но часто настройка нетипичных бандлов становится гемороем, если у вас планируется большой стек технологий и библиотек, то сначала лучше создайте прототип и попробуйте весь зоопарк поднять. Для новичков это становится неприятным сюрпризом и шишок будет набито немало :)
Те компоненты, о которых вы сказали, есть самодостаточно в кэмеле, поэтому имхо ServiceMix сам по себе профита не даст
Те компоненты, о которых вы сказали, есть самодостаточно в кэмеле, поэтому имхо ServiceMix сам по себе профита не даст
Мы используем практически голый Camel.
На текущий момент в его состав входят:
— ActiveMQ + KahaDB
— Jetty
— Компоненты Camel: FTP, file, jetty, JMS, velocity
В остальных системах в качестве клиента JMS используем ActiveMQ в паре c собственным велосипедом.
Когда мы начинали работать с Camel не было ни ServiceMix-а, ни Karaf-а, да и альтернатив Camel-у не было.
По опыту работы могу сказать, что очень не хватает в “голом верблюде” средств мониторинга и гибкого администрирования. Мы использовали ActiveMQBrowser, на тот момент других вариантов не было. Этот инструмент имеет очень ограниченный функционал и сейчас уже не развивается. Сейчас склоняемся в сторону нового аналогичного инструмента встроенного в ActiveMQ.
На текущий момент в его состав входят:
— ActiveMQ + KahaDB
— Jetty
— Компоненты Camel: FTP, file, jetty, JMS, velocity
В остальных системах в качестве клиента JMS используем ActiveMQ в паре c собственным велосипедом.
Когда мы начинали работать с Camel не было ни ServiceMix-а, ни Karaf-а, да и альтернатив Camel-у не было.
По опыту работы могу сказать, что очень не хватает в “голом верблюде” средств мониторинга и гибкого администрирования. Мы использовали ActiveMQBrowser, на тот момент других вариантов не было. Этот инструмент имеет очень ограниченный функционал и сейчас уже не развивается. Сейчас склоняемся в сторону нового аналогичного инструмента встроенного в ActiveMQ.
Sign up to leave a comment.
Перетягивание «Верблюда» или интеграция средствами Camel. Часть 1