Подходит ли Apache Camel для интеграции с собственным приложением для обработки заданий?
В текущем проекте нам нужно выполнить довольно сложные вычисления для данных, экспортируемых из нашей системы. Расчеты обрабатываются сторонним программным обеспечением (которое для нас по сути является черным ящиком). У нас есть это программное обеспечение в виде бинарных файлов Linux или Windows, и мы знаем, как выполнить его с нашими данными в командной строке.
Обработка одного набора данных на одном ядре процессора занимает около 200 часов. Однако мы можем разбить набор данных на меньший набор данных (структурно эквивалентный) и выполнить вычисления параллельно. Позже мы можем легко агрегировать результаты. Наша цель - обработать каждый набор данных менее чем за 10 часов.
У нашего клиента есть запатентованное приложение для обработки заданий. Интерфейс основан на файловой системе: мы копируем EXE-файл задания (да, он поддерживается Windows) и INI-файл конфигурации во входящую папку, приложение для обработки задания выполняет это задание на одном из узлов (обработка ошибок, отработка отказа и т. Д..) и, наконец, копирует результаты в исходящую папку. Эта проприетарная система обработки заданий имеет несколько сотен ядер ЦП, поэтому мощности явно хватает на обработку нашего набора данных менее чем за 10 часов. Даже до 30 минут.
Дело в том, что наше приложение до сих пор основано на J2EE, более или менее стандартном приложении JBoss. И нам нужно:
- интегрировать с собственной системой обработки заданий в виде очереди и
- разделить / объединить наши наборы данных надежным способом.
Для меня многие части того, что мы должны делать, очень похожи на шаблоны интеграции корпоративных приложений, такие как Splitter и Aggregator. Поэтому я подумал, подойдет ли Apache Camel для реализации:
- Мы создадим нашу работу (EXE + INI + набор данных) в виде сообщений.
- Разделитель разделит большие сообщения о заданиях на более мелкие, разделив набор данных на несколько небольших наборов данных.
- Вероятно, нам потребуется реализовать собственные каналы обмена сообщениями для записи сообщений во входящий каталог или чтения сообщений из исходящего каталога собственной системы обработки заданий.
- Нам понадобится агрегатор, чтобы объединить результаты частей работы в единый результат работы.
Тем не менее, у меня пока нет опыта работы с Apache Camel, поэтому я решил спросить совета по поводу применимости.
Учитывая проблему, описанную выше, считаете ли вы, что Apache Camel подойдет для этой задачи?
Заключительное примечание: я не ищу внешних ресурсов или предложения инструмента / библиотеки. Просто подтверждение (или наоборот), если я на правильном пути с Apache Camel.
3 ответа
У вас там довольно сложный сценарий использования. Позвольте мне перефразировать то, что вы хотели бы сделать, в простом формате и высказать свои мысли. Если вы видите, что я что-то не понял, просто оставьте мне комментарий, и я пересмотрю свой пост.
J2EE-приложение на основе JBoss, которое имеет большой набор данных, который необходимо преобразовать, разделить на более мелкие части и затем преобразовать в пользовательский формат. Затем этот формат будет записан на диск и обработан другим приложением, которое создаст новые результаты данных в выходной папке на диске. Затем вы хотите получить этот вывод и агрегировать результаты.
Я бы сказал, что Apache Camel может сделать это, но вам потребуется время, чтобы правильно настроить систему под ваши нужды и настроить несколько пользовательских конфигураций на ваших компонентах. Я представляю, что этот процесс выглядит примерно так:
from("my initial data source")
.split().method(CustomBean.class, "customSplitMethod")
//You might want some sort of round robin pattern to
//distribute between the different directories
.to("file://customProgramInputDirectory");
from("file://customProgramOutputDirectory")
.aggregate(constant(true), new MyCustomAggregationStratedgy())
.to("output of your data source");
Так как вы сказали, что будете интегрироваться с "проприетарной системой обработки заданий, подобной очереди", я мог бы неправильно понять ввод и вывод другой программы как fileDirectories, если это система на основе очередей и она поддерживает jms, то есть универсальный шаблон, который вы можете использовать, если не всегда возможно создать пользовательский компонент верблюда, так что ваш шаблон просто изменится с "file://" на "MyCustomEndpoint://"
Я думаю, что Apache Camel подходит для ваших нужд, так как это одна из лучших интегрированных сред, которые я нашел до сих пор.
Мой текущий проект связан с ECM, с обработкой огромного количества документов, которые могут достигать 1 миллиона в день.
В качестве входных данных у нас есть XML-файлы, представляющие группу документов (или множество документов) вместе со ссылками на реальные файлы, хранящиеся на NAS.
Прежде всего нам пришлось преобразовать все эти XML-файлы в собственный XML-формат, который подходит для проприетарного импортера документов, используемого нашей системой ECM (наш черный ящик), и разделить их на более мелкие фрагменты, чтобы использовать более одной очереди импорта.
Затем мы должны были следить за очередями импортера и отправлять их должным образом, чтобы сбалансировать нагрузку на очередь, и после этой операции мы должны были узнать результат чтения операции из выходного файла XML закрытого формата, сгенерированного импортером.
Между каждым этапом этого процесса существовала очередь ActiveMQ (с сохранением базы данных), чтобы сохранять все асинхронным, и каждая отдельная фаза могла быть увеличена, увеличивая число одновременных потребителей в этой конкретной очереди.
Также наши микросервисы являются частью огромного и длинного рабочего процесса, управляемого ESB, поэтому мы получаем входные сообщения из предоставленных ESB очередей и снова записываем выходные сообщения в эти очереди, используя небольшие веб-службы для получения / установки объектов.
Мы решили пойти на Camel, так как он решил много проблем интеграции, он дает полный контроль над каждым маршрутом и может легко отслеживаться hawtio.
Более того, большая часть конфигурации выполняется путем написания или изменения XML-файлов контекста, обеспечивая гибкость и избавляя вас от написания большого количества кода. Сообщество живое, фреймворк обновляется очень часто, и вы можете найти множество книг и учебных пособий.
Поэтому я думаю, что ваша проблема имеет много точек соприкосновения и сходства по сравнению с целью моего проекта, поэтому, опять же, я определенно решил использовать Apache Camel.
С очень хорошими результатами.
Ответ НЕТ - верблюд - не лучшая основа для этого, даже если он может растягиваться, чтобы подражать тому, что вы описываете.
Apache Camel выполняет некоторое разделение на входящее единство работы, идентифицируя как Exchange который, конечно, может быть файлом (с использованием компонента camel-file). НО, при разделении каждый "чанк" затем отправляется на выделенный Processor,
Проблема в том, что кусок является Exchange сам по себе и предназначен для помещения в память (чтобы иметь возможность выполнять задачи параллельно позже). В вашем случае я предполагаю, что часть данных все еще слишком велика для обработки в памяти. Если нет, Camel отвечает вашим потребностям и даже выполняет все опросы, необходимые для интеграции с системой, которую вы описали.
Вы просите ничего не предлагать, но на вашем месте я бы попробовал Spring Batch.