Drools — это хорошо зарекомендовавшая себя среда разработки правил Java. Еще более десяти лет назад, когда я только начал работать, я работал в сторонней платежной компании. Я помню, что на базовом уровне маршрутизации платежей я использовал Drools.

Что похвально, так это то, что проект Drools по-прежнему имеет открытый исходный код и обновляется более десяти лет спустя.

https://github.com/kiegroup/drools

LiteFlow — это также механизм правил Java, исходный код которого был открыт в 2020 году. После двух лет итераций функции и возможности теперь очень хороши. Он очень подходит для использования в основных сферах бизнеса высокой сложности, сохраняя при этом гибкость бизнеса.

https://gitee.com/dromara/liteFlow

В этой статье мы проведем углубленное сравнение этих двух фреймворков, чтобы увидеть, для каких сценариев они подходят, каковы их сходства и различия и насколько они выразительны в одном и том же сценарии.

(Drools основан на версии 7.6.0, а LiteFlow — на версии 2.9.0)

Хотя субъектом вопроса является автор проекта с открытым исходным кодом LiteFlow, за последние несколько дней я также узнал больше о Drools и попытался проанализировать его с очень объективной точки зрения. Многие результаты сравнения основаны на ощущениях после фактического использования. Однако в предмете вопроса неизбежно будет некоторая субъективная психология и однобокое понимание, тем более, что Drools обновился до 8.Х.

Определение механизма правил

Прежде всего, я хочу уточнить Определение механизма правил, потому что многие друзья склонны путать понятия механизма правил и механизма процесса.

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

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

Механизм процессов реализует поток между несколькими участниками бизнеса в соответствии с определенными предопределенными правилами, которые обычно включают информацию о ролях.

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

Сходства и различия между двумя фреймворками

Drools и LiteFlow — отличные фреймворки с открытым исходным кодом, которые могут убрать логику в бизнесе. И имеет свой собственный синтаксис выражений.

Но разница в том, что Drools делает упор на регуляризацию логических фрагментов. Вы можете записать основные переменные в файл правил, что эквивалентно коду, первоначально написанному на Java, который теперь перемещается в файл правил. Весь код в файле правил можно оперативно изменить.

LiteFlow разработан на основе компонентного мышления, уделяя особое внимание регуляризации компонентов и охватывая весь бизнес. Наименьшей единицей оркестрации является компонент, а файлы правил используются для соединения потоков между компонентами. В то же время LiteFlow также поддерживает регуляризацию фрагментированного кода, поскольку LiteFlow также поддерживает сценарии бизнес-логики. Правила поддерживают горячие изменения.

Таким образом, основными факторами, позволяющими судить о том, является ли механизм правил квалифицированным, являются:

1. Есть ли гибкий график выражение поддержки
2. Могут ли правила и Java быть очень удобно связаны?
3. Удобен ли вызов API и как он интегрируется с различными системами сцен?
4. Сравнение интрузивных связей
5. Стоимость изучения правил,Легко ли начать?
6. регулярное выражение Есть ли языковой плагин?
7. Могут ли правила быть слабо связаны с бизнесом и храниться в другом месте?
8. Могут ли изменения правил изменить логику в реальном времени?
9. Есть ли форма интерфейса для его поддержки?Использование нетехническим персоналом
10. Производительность фреймворка

Давайте детально сравним выразительность двух фреймворков с этих аспектов.

регулярное выражение

Droolsизрегулярное выражение, созданное специально для Java на основе Чарльза Реализация механизма правил алгоритма RETE Форги.

Регулярное выражение Drools близко к естественному языку программирования.,Иметь собственный файл расширения drl,грамматика поддерживает все,По сути, все естественные языки программирования имеют грамматикуadrl. так,В дрл-файле вполне можно написать java-логику.

Давайте посмотрим, как выглядит файл drl:

дрл-файл

Как видите, правила Drools определяет в виде правила и абзаца с четким указанием «когда... то», указывающим, что делать при выполнении определенных условий. Подпишитесь на официальный аккаунт z: Колонка технологий Ма Юаня, ответьте на ключевые слова: 1111, чтобы получить внутреннее руководство Alibaba по оптимизации производительности Java! Когда правило срабатывает, оно автоматически определяет, какое правило должно быть выполнено. Если соблюдено несколько условий, может быть активировано несколько правил.

Выражения оркестровки LiteFlow просты и понятны, а нижний уровень упакован в язык выражений EL. Используется для потока компонентов, поддерживая асинхронные, выборочные, условные, циклические, вложенные и другие сценарии.

Уровень компонента может быть не только компонентом Java, но также может быть написан на языках сценариев. В настоящее время поддерживаются два языка сценариев: Groovy и QLExpress. Все, чего можно достичь с помощью Java, можно сделать с помощью языка сценариев.

Файл правил LiteFlow выглядит примерно так:

Файл правил LiteFlow

Приведенное выше выражение оркестровки LiteFlow выражает следующий логический поток:

Выражения оркестровки LiteFlow

Выражения оркестровки LiteFlow поддерживают большие выражения, такие как THEN (синхронный), WHEN (асинхронный), SWITCH (выбор), IF (условие), FOR (количество циклов), WHILE (условный цикл) и т. д. Каждое выражение имеет множество ключей расширения. Слова доступны для выбора.

Groovy, поддерживаемый компонентом сценария, в основном аналогичен синтаксису Java. Вы можете использовать все, что поддерживается языком Groovy. В синтаксисе Groovy даже можно определить дополнительные классы и методы.

"в заключение"

В общем, обе платформы могут использовать сценарии для определения логических фрагментов. На уровне определения логических фрагментов Drools использует синтаксис собственной разработки, а LiteFlow использует плагин Groovy. На самом деле, я лично считаю, что Groovy ближе к синтаксису Java. Вы даже можете определять в нем классы и методы. Drools также может использовать правила для определения методов в продвинутых приложениях, но я не думаю, что это так уж естественно.

Самая большая особенность LiteFlow заключается в том, что помимо определения логических фрагментов он также может управлять глобальными компонентами. Это то, что LiteFlow называет механизмом оркестрованных правил. Сложные логические потоки могут быть разработаны с использованием простого синтаксиса оркестровки. Поддерживает смешивание Java и скриптов.

Обмен данными с Java

В правилах Drools,ты можешь пройтиimportКлючевые слова, которые стоит представитьjavaиз Некоторые классы пакетов называются。

В компоненте «Скрипт» LiteFlow,GroovyВы также можете пройтиimport Чтобы ввести любой пакет Java для вызова.

В Drools вы можете напрямую ссылаться на объект факта.

В LiteFlow вы можете напрямую ссылаться на объект контекста, и контекст контекста проходит через всю ссылку оркестрации.

В LiteFlow с помощью аннотации @ScriptBean вы даже можете вводить bean-компоненты в контекст Spring и вызывать их напрямую. Используя эту функцию, вы даже можете вызвать rpc в сценарии и вызвать объект dao базы данных для получения данных. Хотя это тоже можно сделать в Drools, но гораздо хлопотнее.

"в заключение"

В принципе, он может удовлетворить потребности обмена данными с помощью Java, но LiteFlow, очевидно, поддерживает больше сценариев.

API и интеграции

На уровне вызовов API Drools необходимо определить ряд объектов, таких как KieContainer, KBase и KSession. Платформе LiteFlow необходимо использовать только объект LiteFlowExecutor.

Drools поддерживает программный доступ, но в Springboot вам нужно написать множество классов конфигурации для его интеграции.

LiteFlow не только поддерживает программный доступ, но также предоставляет автоматически собранный метод доступа в среде Springboot. Вам даже не нужно определять LiteFlowExecutor. Вы можете получить автоматически собранный объект непосредственно из контекста и вызвать его.

в заключение

API LiteFlow проще и более интегрирован со Springboot.

Сравнение интрузивных связей

Drools необходимо использовать объект KSession для сопоставления правил и вызывать их там, где правила необходимы в Java-коде. Правила и Java разделены. Вызывающий объект KSession связан на уровне вызова.

Правила LiteFlow также отделены от Java, но LiteFlow имеет концепцию компонентов, поэтому ее необходимо наследовать на уровне компонентов. Однако он также обеспечивает выбор декларативных компонентов. Использование декларативных методов уменьшит связанность. На уровне вызова также необходимо вызвать объект LiteFlowExecutor.

"в заключение"

С точки зрения связи, поскольку LiteFlow предоставляет функции оркестрации, связь API является относительно высокой. Слюни меньше связаны.

Стоимость изучения правил

Стоимость изучения правил Drools довольно высока. Поскольку это грамматика правил, разработанная самостоятельно, она требует очень всестороннего процесса ознакомления. И документы все на английском языке.

Правила оркестровки LiteFlow чрезвычайно просты. Если вы не используете компоненты сценариев, вы можете начать работу примерно за 10 минут. Даже если вы используете скрипты groovy, поскольку groovy очень похож на Java, стоимость обучения очень мала. Кроме того, существует множество учебных материалов, к которым можно обратиться.

Документация LiteFlow полная на китайском и английском языках, и существует хорошее китайское сообщество, готовое ответить на вопросы.

в заключение

С точки зрения затрат на изучение правил, кривая обучения правилам Drools более чем немного выше, чем у LiteFlow.

Есть ли языковой плагин?

В Drools есть плагины для Eclipse и IDEA для подсветки синтаксиса, предварительной проверки и подсказок.

LiteFlow имеет плагины для IDEA для выделения, предварительной проверки и подсказок. Недоступно в Eclipse.

в заключение

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

Хранение правил

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

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

Помимо локальных правил, LiteFlow изначально поддерживает сохранение правил в любой стандартной базе данных SQL, а также изначально поддерживает Nacos, Etcd, Zookeeper и другие центры регистрации. Просто нужно его настроить. Кроме того, предусмотрен интерфейс расширения, облегчающий расширение в любую точку хранения.

"в заключение"

Поддержка хранилища правил LiteFlow намного богаче, чем у Drools.

Могут ли изменения правил изменить логику в реальном времени?

Правила горячего обновления Drools теперь кажутся немного глупыми. Его правила генерируются jar. Затем система динамически считывает пакет jar удаленно, чтобы завершить обновление правила.

И правила должны быть оперативно изменены через Workbench.

LiteFlow гораздо более продвинут на этом уровне. Если вы используете для хранения Nacos, Etcd, Zookeeper и т. д., вам не нужно ничего делать, изменения будут автоматически обновляться. Если вы используете хранилище базы данных SQL или локальное хранилище. После изменения правил вам необходимо вызвать API, предоставляемый платформой LiteFlow, для выполнения горячих изменений. Оба метода могут быть обновлены в горячем режиме. И это гладко в условиях высокого параллелизма.

"в заключение"

LiteFlow намного более продвинут, чем Drools, с точки зрения дизайна горячих обновлений.

Есть ли форма интерфейса для его поддержки?

В Drools есть Workbench, который представляет собой независимый пакет плагинов, предоставляющий правила написания веб-интерфейса и объекты фактов. и обеспечивает возможность проверки и развертывания. Но поскольку Drools в основном заботится о логических фрагментах, ему не нужно предоставлять функции перетаскивания пользовательского интерфейса на уровне оркестрации, а только предоставляет возможность писать правила в интерфейсе.

LiteFlow не имеет формы интерфейса. В настоящее время изменение правила интерфейса может быть выполнено только через интерфейс, предоставленный сторонними компаниями Nacos и Etcd.

"в заключение"

Drools — на шаг впереди LiteFlow в экологии формы пользовательского интерфейса.

Производительность фреймворка

Здесь та же логическая демонстрация реализована с использованием Drools и LiteFlow.

Демо-кейс начисления баллов в зависимости от суммы заказа.

Логика дела очень проста. Она динамически определяет, сколько баллов добавить в зависимости от суммы заказа:

Если сумма меньше 100 юаней, баллы не начисляются.

От 100 до 500 юаней плюс 100 баллов.

От 500 до 1000 юаней плюс 500 баллов.

При покупке на сумму более 1000 юаней добавьте 1000 баллов.

Правила Drools следующие:

package rules;

import com.example.droolsdemo.entity.Order;

rule "score_1"
when
    $order:Order(amount<100)
then
    $order.setScore(0);
    System.out.println("Правило 1 сработало");
end

rule "score_2"
when
    $order:Order(amount>=100 && amount < 500)
then
    $order.setScore(100);
    System.out.println("Сработало правило 2");
end

rule "score_3"
when
    $order:Order(amount>=500 && amount < 1000)
then
    $order.setScore(500);
    System.out.println("Сработало правило 3");
end

rule "score_4"
when
    $order:Order(amount>=1000)
then
    $order.setScore(1000);
    System.out.println("Сработало правило 4");
end

Эквивалентные правила LiteFlow следующие:

<?xml version="1.0" encoding="UTF-8"?>
<flow>
    <nodes>
        <node id="w" type="switch_script">
            <![CDATA[
                def amount = defaultContext.getData("order").getAmount();

                if (amount < 100){
                    return "a";
                }else if(amount >= 100 && amount < 500){
                    return "b";
                }else if(amount >= 500 && amount < 1000){
                    return "c";
                }else{
                    return "d";
                }
            ]]>
        </node>

        <node id="a" type="script">
            <![CDATA[
                def order = defaultContext.getData("order");
                order.setScore(0);
                println("Выполнить правило а");
            ]]>
        </node>

        <node id="b" type="script">
            <![CDATA[
                def order = defaultContext.getData("order");
                order.setScore(100);
                println("Выполнить правило b");
            ]]>
        </node>

        <node id="c" type="script">
            <![CDATA[
                def order = defaultContext.getData("order");
                order.setScore(500);
                println("Выполнить правило c");
            ]]>
        </node>

        <node id="d" type="script">
            <![CDATA[
                def order = defaultContext.getData("order");
                order.setScore(1000);
                println("Правило выполнения d");
            ]]>
        </node>
    </nodes>

    <chain name="chain1">
        SWITCH(w).TO(a, b, c, d);
    </chain>
</flow>

Когда оба фреймворка полностью написаны на скриптах, в процессе тестирования все журналы печати удаляются и выполняются 100 000 раз. Полученные результаты следующие:

Drools выполняется 100 000 раз, что занимает 0,7 секунды.

Полный компонент сценария LiteFlow выполняется 100 000 раз, что занимает 3,6 секунды.

Поскольку LiteFlow имеет полноценный компонент сценариев, ему необходимо выполнять сценарии и оркестровать сценарии, поэтому это занимает больше времени.

Если LiteFlow заменит компонент на Java, а затем выполнит его, результат будет следующим:

Полный Java-компонент LiteFlow выполняется 100 000 раз, что занимает 0,5 секунды.

в заключение

Если LiteFlow запускается как полный скрипт, это займет больше времени, чем Drools. Если он запускается как полноценный Java-компонент, его производительность может превзойти Drools.

Итак, для LiteFlow, если вам нужна более высокая производительность, используйте компоненты Java, а если вам нужна более высокая гибкость, используйте компоненты сценария.

Фактически, в реальном бизнесе более рекомендуется извлекать легко изменяемую логику и писать ее как компонент сценария, используя гибридный метод Java+script.

Заключение

Почему Drools используется для сравнения? Во-первых, по мнению субъекта, Drools всегда был эталоном в индустрии машин правил. В Drools есть много концепций, которые стоит изучить. Вторая причина в том, что субъект знаком только с Drools и плохо пользовался другими фреймворками.

Но вместе взятые, LiteFlow, восходящая звезда отечественных движков, явно лучше Drools с точки зрения концепции дизайна и поддержки. В качестве нового направления механизмов правил будут продолжать изучаться оркестрованные механизмы правил. Я надеюсь, что каждый сможет поддержать этот механизм внутренних правил. Что касается оркестровки, помимо некоторых функций, упомянутых в этой статье, LiteFlow также имеет множество других исследовательских игровых возможностей и расширенных функций. Это основа, в которую стоит вникнуть.

Источник: https://juejin.cn/post/7155672111481094152.