#xml #architecture #drools #esb #mule
#xml #архитектура #пускает слюни #esb #mule
Вопрос:
Я изучал инструменты и фреймворки для реализации приложения BAM. Основными требованиями будут:
- Взаимодействуйте с различными приложениями для получения бизнес-статуса / действий. Исходными каналами будут поставщик JMS, веб-сервисы, FTP и JMX.
- Было бы максимально приближено к реальному времени.
- Потребуется обрабатывать более 20 миллионов сообщений в день с периодичностью 2000 сообщений в секунду (сообщения в формате XML через поставщика JMS, такого как ActiveMQ или WebsphereMQ).
- Генерировать оповещения при нарушении ключевых показателей эффективности (предупреждающий и критический уровни)
Также следует учитывать, что наша небольшая компания имеет лицензию Mulesoft EE, корпоративный стек приложений (osgi поставляется в комплекте с Tomcat, ActiveMQ, Drools и т.д.)
Итак, первоначальный проект подхода, о котором я думал, основываясь только на исследованиях, прежде чем попробовать POC, выглядит примерно так:
Использование Mule в качестве ESB для интеграции с различными приложениями, а затем использование его службы SEDA для обработки событий и отправки их в Drools engine для обработки правил, связанных с этими событиями.
Я не совсем уверен, соответствует ли этот процесс способу использования этих инструментов, или если есть лучший, более красноречивый способ справиться с этим. Также некоторые другие нерешенные вопросы:
- Как можно отобразить пользователю агрегацию событий и статуса (предупреждения, нарушения ключевых показателей эффективности и т.д.). Интеграция с GWT? Следует ли помещать события в базу данных в памяти для запроса и отображения?
- Что касается физической архитектуры, я думал о запуске mule в кластеризованных экземплярах tomcat на двух серверах с движками drools на одних и тех же серверах? База данных (для хранения истории) на собственных серверах.
- Я не ограничиваюсь вышеперечисленными инструментами, я также рассматривал Esper, Apache Camel
- Является ли этот подход излишним? Можно ли использовать более простое веб-приложение с управлением состоянием RDBMS? Я полагал, что требования к реальному времени и количеству событий предотвратят это.
Я был бы признателен за любую помощь, которая помогла бы мне разработать первоначальную стратегию здесь, или кто-нибудь внедрил решение с аналогичными требованиями и хотел бы поделиться. Спасибо!
Комментарии:
1. Из-за большого объема данных я бы рассмотрел агрегирование в реальном времени, чтобы избежать сохранения всех входных событий. Постоянное хранилище для ваших требований было бы довольно дорогим, а объем хранилища в памяти ограничен.
Ответ №1:
Возможно, вы захотите рассмотреть возможность использования базы данных NoSQL для хранения данных о событиях из-за
- много данных
- Требуемая скорость записи события в секунду
- Вам нужна гибкая модель для захвата различных атрибутов в данных о событиях, специфичных для определений ключевых показателей эффективности, поскольку ключевые показатели эффективности основаны на модели данных вашего приложения.
Если вы решили пойти по этому пути, я бы предложил использовать хранилище данных, ориентированное на документы, такое как Mongo DB, из-за
- Требуется эффективное чтение для вычисления значения для определенного KPI.
- Требуется очень богатое представление данных, в основном иерархическое, для сбора данных о событиях.
- Вы можете использовать механизм вторичного индексирования, такой как lucene, чтобы улучшить производительность чтения «из коробки», предоставляемую DB. Эти индексы могут быть специфичны для определенного KPI на основе модели данных приложения.
Да, вам нужен механизм асинхронной обработки событий, такой как MQ.
Я видел, что IBM Websphere BAM server использует XML-представление своих данных о событиях, и они хранят их в реляционной базе данных, такой как DB2. Но я думаю, что NoSQL был бы лучшим выбором.