Бизнес-правила в действии: семь лет развития и усовершенствования Business Rules Engine

[sstv]

Спасибо за статью!
Я ведь правильно понимаю, что правила создаются общего вида и чтобы понять нужно ли выполнить действие, мы должны событие прогнать каждое событие по всем правилам в системе?
Отсюда вопрос: как решаете проблему с большим потоком событий при большом объеме правил?
Например если в системе заведено 20 тысяч правил и поток событий скажем 1000 в минуту, то это означает, что при однопоточной обработке, мы должны успевать обрабатывать 16 событий в секунду (прогоняем в сумме 320к правил в секунду) или 60 мс на 1 событие на прогон 20к правил.
У вас написано что вы еще куда-то в сеть ходите чтобы принять решение, в условиях такой нагрузки и объема работы, кажется нереальным куда-либо по сети ходить :) если поставщик данных зависнет на пару секунд - накопится очередь. Понятно что можно поднять пару десятков подов, побольше партиций в кафке. Правила держать в памяти пода и обновлять фоново из бд раз в N минут... :) хочется более фундаментального решения проблемы :)

Возможно Вы как-то предварительно фильтруете какие правила нужно применить (чтобы зря не жечь CPU) или они не универсальные и заточены под конкретное событие?
Спасибо.

[VladKuchinskiy]

Благодарю за интересный вопрос! Да, в общем случае логика обхода правил - сверху вниз, слева направо, до полного совпадения, на этом обработка сценария завершается действием. Есть идеи по оптимизации этого алгоритма, если это понадобится

Про обращение по сети логичный, но ключевой момент, мы это делаем только в том случае, если эти данные понадобились. Т.е. вначале мы используем те параметры, которые у нас есть, и если их не хватает для принятия решения, то уже идем во внешнюю систему

И глобально да, это вопрос, потому что внешние системы могут отвечать не так быстро, как нам бы хотелось

Вопросы производительности сейчас решаются за счет параллельной обработки запросов, и поднятием подов

[May3]

Слава богу сожгли BPEL-генератор, теперь можно спать спокойно

[VladKuchinskiy]

BPEL-генератор был хорош) Позволил быстро запустить первую версию, но мы очень быстро выросли из него

[May3]

Рад, что он пригодился, пускай и ненадолго. Было интересно узнать, что проект развился до такой степени и приносит пользу, спасибо за статью)

[ggo]

Почему BRE, а не CEP (Complex Event Processing)?

[VladKuchinskiy]

Для CEP нам не хватает, пока) плоскости времени, например, чтобы зафиксировать последовательность трех различных событий и выполнить действие