• Note: Source: Geek Time’s “Learn Architecture from Scratch”
  • Microkernel Architecture, also known as plug-in Architecture, is a feature-oriented and scalable Architecture that is commonly used to implement product-based applications
  • For example, IDE software such as Eclipse, OPERATING system such as UNIX, client software such as Taobao APP, etc. Some enterprises also design their business systems into microkernel architecture, such as insurance accounting logic system of insurance companies, and different types of insurance can encapsulate logic into plug-ins

Basic architecture

  • The microkernel architecture consists of two types of components: core systems and plug-in modules

The core system

  • Mainly responsible for general functions unrelated to specific business functions, such as module loading, inter-module communication, etc

Plug-in modules

  • Mainly responsible for the implementation of specific business logic, such as “mobile phone number registration” function in “Student Information Management” system

Basic architecture diagram of the microkernel

  • In the figure above, the core system functions are stable and will not be constantly modified due to the expansion of business functions. The plug-in module can be continuously expanded according to the needs of business functions
  • The essence of the architecture of microkernel is to encapsulate the changing part in the plug-in, so as to achieve the purpose of fast and flexible expansion without affecting the stability of the whole system

Key Points of design

  • The key technologies of microkernel system design include plug-in management, plug-in connection and plug-in management

1. Plug-in management

  • The core system needs to know what plug-ins are currently available, how to load them, and when to load them. A common implementation is the plug-in registry mechanism
  • The core system provides a plug-in registry (which can be a configuration file, code, or database) that contains information about each plug-in module, including its name, location, and loading time (load on startup or load on demand)

2. Connect the plug-in

  • Refers to how plug-ins connect to the core system. In general, the core system must specify the connection specification between the plug-in and the core system, then the plug-in is implemented according to the specification, and the core system is loaded according to the specification
  • Common connection mechanisms include OSGi (used by Eclipse), message patterns, dependency injection (used by Spring), and even distributed protocols such as RPC or HTTP Web

3. Plug-in communication

  • Refers to communication between plug-ins. Although the design is completely decoupled between plug-ins, in the actual business operation process, it is inevitable that a certain business process requires the collaboration of multiple plug-ins, which requires the communication between two plug-ins
  • Since there is no direct link between plug-ins, communication must go through the core system, so the core system needs to provide a plug-in communication mechanism
  • This situation is similar to the computer, the COMPUTER’S CPU, hard disk, memory, network card is independently designed configuration, but during the operation of the computer, CPU and memory, memory and hard disk must have communication, the computer through the bus on the motherboard to provide communication between these components
  • The core system of the microkernel must provide a similar communication mechanism so that plug-ins can communicate normally

An overview of the OSGi architecture

  • OSGi stands for Open Service Gateway Initiative, which itself is OSGi Alliance. It is a non-profit international organization that aims to establish an open service specification for providing services to devices over the network, known as the OSGi Specification. Unless otherwise specified, this generally refers to the OSGi specification
  • The OSGi alliance’s original intention was to build a basic platform for carrying out services on wans and Lans or devices, so OSGi was originally designed for embedded applications, such as set-top boxes, service gateways, mobile phones, automobiles, and so on
  • Because OSGi is dynamic, hot pluggable, highly reusable, efficient, and scalable, it has been used for application development on THE PC
  • OSGi became the preferred plug-in standard, especially after the popular Eclipse software adopted OSGi
  • OSGi is now less about embedded applications and more about OSGi as an architectural pattern for microkernels

Logical architecture diagram of the OSGi framework

1. Module Layer
  • The module layer implements plug-in management functions. In OSGi, plug-ins are called bundles. Each Bundle is a Java JAR file, and each Bundle contains a manifest.mf metadata file that contains basic information about the Bundle
  • For example, the name, description, developer, classpath of the Bundle, and the packages that need to be imported and exported will be loaded into the OSGi core system for subsequent use

A simple manifest.mf example is shown below

// MANIFEST.MF Bundle-ManifestVersion: 2 Bundle-Name:UserRegister Bundle-SymbolicName: Com. Test. Userregister Bundle - Version: 1.0 Bundle Activator: com. Test. UserRegisterActivator Import - Package: org. Log4j; version="2.0". Export-Package: com.test.userregister; version="1.0".Copy the code
2. Lifecycle Layer
  • The lifecycle layer implements plug-in connectivity, providing execution-time module management, and module access to the underlying OSGi framework
  • The lifecycle layer defines precisely the actions (install, update, start, stop, and uninstall) of the Bundle lifecycle, which the Bundle must implement according to the specification. Such as:
public class UserRegisterActivator implements BundleActivator { public void start(BundleContext context) { UserRegister.instance = new UserRegister (); } public void stop(BundleContext context) { UserRegister.instance = null; }}Copy the code
3. Service Layer
  • The service layer implements plug-in communication. OSGi provides a service registry function that allows plug-ins to register their services with the OSGi core registry. If a service wants to use other services, it can simply search the service registry for available service centers
  • Such as:
/ / registration service public class UserRegisterActivator implements the BundleActivator {/ / in the start () with BundleContext. RegisterService () The registration service public void start (BundleContext context) {context. RegisterService (UserRegister. Class. GetName (), new UserRegisterImpl(), null); } // There is no need to unregister the service in stop(), Public void stop(BundleContext Context) {}} public class Client implements BundleActivator { public void start(BundleContext context) { // 1. Retrieve indirectly from service registry "service reference" ServiceReference becomes unavailable but ref. = the context that getServiceReference (UserRegister. Class. GetName ()); // 2. Use the service reference to access the instance of the service object ((UserRegister) context.getService(ref)).register(); } public void stop(BundleContext context) {} }Copy the code
  • Note: The service registration here is not a plug-in registration in the plug-in management function, but is actually a mechanism for communication between plug-ins

A brief analysis of rules engine architecture

The rules engine is also a concrete implementation of the microkernel architecture from the perspective of structure, in which the execution engine can be regarded as the microkernel. The execution engine parses the configured business flow, executes its conditions and rules, and supports the flexibility of the business in various ways

Rules engine is widely used in billing, insurance, promotion and other business areas. For example, the common promotion rules of e-commerce are as follows:

  • The full 100 to 50
  • Three pieces are immediately reduced by 50
  • Three pieces of eight fold
  • The third item is free
  • Subtract 100 from 200 across stores
  • New users were immediately reduced by 50

Several common, more than just listed in fact complete column down there may be dozens of hundreds of, plus permutation and combination, there may be hundreds of thousands of promotion plan, if fully accomplished by code, such business development efficiency far couldn’t keep up with the speed change, whereas the rule engine can be flexible to cope with this demand, the main reason is:

1. Can be extended

  • By referring to the rules engine, the business logic implementation is separated from the business system and new business functions can be extended without changing the business system

2. Easy to understand

  • Rules are described in natural language and are easy for business people to understand and manipulate, unlike code that only programmers can understand and develop

3. High efficiency

  • The rule engine system provides visual rule customization, approval, query, and management, helping service personnel quickly configure new services.

The basic architecture of the rules engine

  • Developers break down business functions into rules, which are stored in rule libraries
  • According to business needs, business personnel arrange and combine rules to configure business processes and save them in the business library
  • The rules engine executes business processes to implement business functions

In contrast to the key design points of the microkernel architecture, how the rules engine is implemented in detail:

1. Plug-in management
  • The rules in the rules engine are plug-ins to the microkernel architecture, and the engine is the kernel of the microkernel architecture. Rules can be loaded and executed by the engine. In a rule engine architecture, rules are typically stored in a rule library, usually in a database.
2. Connect the plug-in
  • Similar to developers need to use the language such as c + +, Java, rule engine and also the rule of the development of language, business people need to write rules based on the rules of the language file, and then execute the rules file loaded by a rule engine to complete business function, therefore, plug-in connection rules engine implementation mechanism is the rules of language
3. Plug-in communication
  • The communication between rules of the rule engine is data flow and event flow. Since a single rule does not depend on other rules, there is no active communication between rules. Rules only need to output data or events, and the engine will pass the data or events to the next rule

Currently, the most commonly used rule engine is the open source JBoss Drools, written in Java language and based on Rete algorithm

Drools have the following advantages:

  • Very active community support, as well as a wide range of applications
  • Fast execution speed
  • Compatibility with the Java Rule Engine API (JSR-94)
  • Guvnor, a web-based BRMS, provides a knowledge base for rule management, through which rules can be versioned, and rules can be modified and compiled online, enabling developers and system administrators to manage business rules online

Although Drools is claimed to be simple and easy to use, in fact, its rule language is similar to a programming language. In practical application, ordinary business people have a high cost of learning and understanding such a rule language, such as the following example

Therefore, it is usually necessary to encapsulate the rules based on Drools and make the rule configuration into a visual operation, such as the following example of e-commerce anti-fraud

Note: Those who are interested in geek Time can check out geek Time – cash back is available