The LiteFlow recommended in this issue is a lightweight, fast, stable and orchestrable component-based process engine.

Function of LiteFlow framework

LiteFlow is designed to decouple complex logic. If you want to write or refactor complex business logic, LiteFlow is the most suitable. It is a lightweight, fast component-based process engine framework, component orchestration, helps decouple business code so that each business fragment is a component, and supports hot-load rule configuration for instant modification.

With LiteFlow, you need to break up complex business logic into small pieces of code and define a rule flow configuration. In this way, all the components can be configured according to your rules for complex flow.

What scenarios does LiteFlow apply to

LiteFlow is suitable for businesses with complex logic, such as price engines, order processes, etc., which often have many steps that can be broken down into individual components according to business granularity for assembly reuse changes. With LiteFlow, you get a flexible, scalable system. Because the components are independent of each other, you can avoid the risk of changing one place and disrupting the whole body.

Project characteristics

• Decoupled orchestration tool for complex services, providing a unified implementation for all components
• Orchestrate process based on rule file, support xml,json,yml three rule file writing methods
• The framework provides the local file configuration source, the implementation of zk configuration source
• The framework provides custom configuration sources that can be loaded from anywhere by implementing only one interface
• supports automatic assembly of SpringBoot, as well as Spring configuration and non-Spring projects
• Provides serial and parallel modes, and provides common and common expression statements
• You can define scripting language nodes and support both QLExpress and Groovy scripts
• Components can support retries, and each component can customize retry configurations and specify exceptions
• Provides stepless nested explicit flow mode, implicit flow mode
• data slot isolation mechanism, context independent and stable under multiple concurrent
• Support elegant smooth hot refresh feature
• Very low system loss, can be stably run in the core business of large-scale microservices
• Comes with simple monitoring to know the running time ranking of each component

Integrated SpringBoot

LiteFlow provides it
liteflow-spring-boot-starter dependency package, providing automatic assembly function

< dependency> 
  <groupId>com.yomahub</groupId>
  <artifactId>liteflow-spring-boot-starter</artifactId>
  <version>2.6.10</version>
</dependency>

Configuration – Component definition

After relying on the above jar packages. You need to define and implement components that SpringBoot scans and registers in the context

@Component("a")
public class ACmp extends NodeComponent  {
    @Override
    public void process() {
        //do your business
    }
}

SpringBoot配置文件

liteflow.rule-source=config/flow.xml
< span class = "HLJS - the comment" > # -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- the following non must -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- < / span >
#liteflow Whether to enable, default is true
liteflow.enable=true
 Whether the banner of #liteflow is enabled, defaults to true
liteflow.print-banner=true
#zkNode node, only if zk is used as the configuration source 
liteflow.zk-node=/lite-flow/flow
# Number of slots, default is 1024
liteflow.slot-size=1024
# Thread pool Builder for parallel nodes, LiteFlow provides the default Builder
liteflow.thread-executor-class=com.yomahub.liteflow.thread.LiteFlowDefaultExecutorBuilder
# Maximum wait time for asynchronous threads in seconds (only for when), default is 16
liteflow.when-max-wait-seconds=20
# Maximum number of threads in asynchronous thread pool, default is 16
liteflow.when-max-workers=16
# Number of asynchronous thread pool waiting queues, default is 512
liteflow.when-queue-limit=512
# Whether to parse the rule at startup, default to true
liteflow.parse-on-start=true
# Global retries, default is 0
liteflow.retry-count=0
# Whether to support the mixing of different loading modes, the default is false
liteflow.support-multiple-type=false
# Whether to enable monitoring log printing, the default is false
liteflow.monitor.enable-log=true
# Monitor queue storage size, default is 200
liteflow.monitor.queue-limit=300
# Monitor how much execution is delayed initially, the default is 300,000 milliseconds, which is 5 minutes 
liteflow.monitor.delay=10000
# How often does the monitor log print take place? The default value is 300000 milliseconds, which is 5 minutes 
liteflow.monitor.period=10000

Definition of the rule file

At the same time, you have to define the rules in config/flow.xml under resources:

< ? xml version="1.0" encoding="UTF-8"? > 
< flow> 
    <chain name="chain1">
        <then value="a,b,c"/>
        <when value="d,e"/>
    </chain>
</flow>

执行

Then you can get flowExecutor in any class and execute the link

@Component
public class MainTest{
    
    @Resource
    private FlowExecutor flowExecutor;
    
    @Test
    public void testConfig(){
        LiteflowResponse<DefaultSlot> response = flowExecutor.execute2Resp("chain1", "arg");
    }
}

Performance

Most of LiteFlow’s work is done at startup, including parsing rules, registering components, and assembling meta information. There is almost no additional cost to the system when the link is executed. The framework was designed from the start for the company’s core business, with particular attention to performance issues. Therefore, the core code is also optimized in terms of performance.

In the actual performance, LiteFlow execution efficiency is very high, in the core business of the company, the link composed of more than 50 business components, in the actual pressure test of a single point reached 1500 TPS, but also experienced double 11, star top flow with goods and other large traffic tests.

Test Example

The business is a price calculation engine with 11 business nodes, rich business logic, but the data is mock, without database IO.

A pressure test was conducted based on this Demo business. The pressure test machine was mac m1 pro and the pressure test tool was apache jmeter. The pressure test results were as follows: