On the rules engine solutions

First, the rules engine usage scenarios:

1. A page, the process, expanding the selection point implementation; output: the position of the implement;
2. Organized numerous conditions and behavioral building blocks building blocks to achieve business logic calculations ticket inventory reduction purposes; output: after re-calculate the price of goods;
3. By order, after-sales orders, and other member organization of information and judgment, to the effect multifactorial decision gives the best answer; output: a responsive answer / marketing recommendation, or also step by step to complete certain forms (after-sale application, or work order submit);
4. Over order message triggers, protocols and commercial metadata input, a structure of the charging records; output: accounting vouchers;

Service Configuration - building conditions, and authorization logic applications, there are very many rules management, due to large changes in business demand fast iteration, the need to constantly nested rules, hard-code development. Based on business needs, hoping to establish a rules engine, the code will be pulled out of the business rules, reducing the cost of iteration rule, such as reducing rule if else nested, enhanced maintainability and reusability of code. Developers do not have too much attention to logic, we can focus on the logic.

There are a lot of rules, such as is done by checking if else logic hard coded, product currently supports electricity, retail and other business sectors, is nothing more than two situations: one is to change the domain model of goods, there is a change of the rules. We can say that the upper support services, business rules, account for half of the sky needs.

General business rules engine, and not coupling their business, providing a common rules engine is feasible.

Second, what are the rules engine

The rules engine is an assembly embedded in the application, to achieve a separation of business decisions out from the application code, and using predefined semantic modules written in business decisions. Accept data entry, explaining business rules, and make business decisions based on business rules.

The rule is essentially a function, such as y = f (x1, x2, .., xn)

The rules engine consists of three parts

• Facts (Fact): is the fact that the user has entered, it can be understood as a known object in front of reasoning.
• LHS (Left Hand Side): the implementation of the rules can be understood as conditions need to be met.
• RHS (Right Hand Sike): returns the object can be understood as a rule after the execution.

Two important modules:

• Rules Management: management rules can be understood as a logical, mainly related to the rules, facts and rules set three entities. When it comes to change the rule, the rule is preferably added to the version, the version control by rules, can be a smooth gradation change the rules embodiment, but also facilitate more confidence in the correctness of the test rules.

• Rule Execution: The rule base data, parsing engine rule by rule, rule compiler executable code is cached, and avoid every DB interaction, then each time change the rules by ZK or DCC also real-time notification to rule actuator. Implementation of the rules of the actuator, can be varied, not dependent on the storage rule base, according to the needs, the choice of Drools, Aviator and other third-party engine that can even customize based on ANTLR.

Third, the practice summary

Practice the truth. Research some of the Java rules engine framework:

• drools heavy for financial risk control, anti-fraud. Avator, Fel, QLExpress not suitable for search and other routing scenario
• With implementation engine, configure routing rules can be based on a script or to apollo Apollo or grovvy scripts.

If the scene is simple, as long as we define critical condition key, hit the key, return key corresponding result can be.

If the complex financial scenarios, drools more appropriate.

For example, a search for a scene, according to the priority from top to bottom:

1. If you took a shop ID, the route to the store search index fragmentation
2. If a buyer with the ID, the route to the buyer slice of the search index
3. If the state is the hot state to a hot state route index
4. in case...

This simple, use a good apollo define key conditions json, can match.