微内核架构

• 注：文章来源：极客时间的专栏《从0开始学架构》
• 微内核架构（Microkernel Architecture），也被称为插件化架构（Plug-in Architecture），是一种面向功能进行拆分的可扩展性架构，一般用于实现基于产品的应用
• 例如Eclipse这类IDE软件、UNIX这类操做系统、淘宝APP这类客户端软件等，也有一些企业将本身的业务系统设计成微内核的架构，例如保险公司的保险核算逻辑系统，不一样的保险品种能够将逻辑封装成插件

基本架构

• 微内核架构包含两类组件：核心系统和插件模块

核心系统

• 主要负责和具体业务功能无关的通用功能，例如模块加载、模块间通讯等

插件模块

• 主要负责实现具体的业务逻辑，例如“学生信息管理”系统中的“手机号码注册”功能

微内核的基本架构图

• 上图中核心系统功能比较稳定，不会由于业务功能扩展而不断修改，插件模块能够根据业务功能的须要不断地扩展
• 微内核的架构本质就是将变化部分封装在插件里面，从而达到快速灵活扩展的目的，而又不影响总体系统的稳定

设计关键点

• 微内核的核心系统设计的关键技术有：插件管理、插件链接和插件管理

1. 插件管理

• 核心系统须要知道当前有哪些插件可用，如何加载这些插件，何时加载插件。常见的实现方法是插件注册表机制
• 核心系统提供插件注册表（能够是配置文件，也能够是代码，还能够是数据库），插件注册表含有每一个插件模块的信息，包括它的名字、位置、加载时机（启动就加载，仍是按需加载）等

2. 插件链接

• 指插件如何链接到核心系统。一般来讲，核心系统必须指定插件和核心系统的链接规范，而后插件按照规范实现，核心系统按照规范加载便可
• 常见的链接机制有OSGi（Eclipse使用）、消息模式、依赖注入（Spring使用），甚至使用分布式的协议都是能够的，好比RPC或者HTTP Web的方式

3. 插件通讯

• 指插件间的通讯。虽然设计的时候插件间是彻底解耦的，但实际业务运行过程当中，必然会出现某个业务流程须要多个插件协做，这就要求两个插件间进行通讯
• 因为插件之间没有直接联系，通讯必须经过核心系统，所以核心系统须要提供插件通讯机制
• 这种状况和计算机相似，计算机的CPU、硬盘、内存、网卡是独立设计的配置，但计算机运行过程当中，CPU和内存、内存和硬盘确定是有通讯的，计算机经过主板上的总线提供了这些组件之间的通讯功能
• 微内核的核心系统也必须提供相似的通讯机制，各个插件之间才能进行正常的通讯

OSGi架构简析

• OSGi全称是Open Service Gateway initiative，自己实际上是指OSGi Alliance。它是一个非盈利的国际组织，旨在创建一个开放的服务规范，为经过网络向设备提供服 务创建开放的标准，这个标准就是OSGi specification。若是没有特别说明，通常都是指OSGi的规范
• OSGi联盟的初衷是构建一个在广域网和局域网或设备上展开业务的基础平台，因此OSGi的最先设计也是针对嵌入式应用的，诸如机顶盒、服务网关、手机、汽车等都是其应用的主要环境
• 因为OSGi具有动态化、热插拔、高可复用性、高效性、扩展方便等优势，它被应用了PC上的应用开发
• 尤为是Eclipse这个流行软件采用OSGi标准后，OSGi更是成了首选的插件化标准
• 如今OSGi已经和嵌入式应用关联不大了，更可能是将OSGi当作一个微内核的架构模式

OSGi框架的逻辑架构图

1. 模块层（Module层）

• 模块层实现插件管理功能。OSGi中，插件被称为Bundle，每一个Bundle是一个Java的JAR文件，每一个Bundle里面都包含一个元数据文件MANIFEST.MF，这个文件包含了Bundle的基本信息
• 例如，Bundle的名称、描述、开发商、classpath，以及须要导入的包和输出的包等，OSGi核心系统会将这些信息加载到系统中用于后续使用

一个简单的MANIFEST.MF样例以下

// 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", 

复制代码

2. 生命周期层（Lifecycle层）

• 生命周期层实现插件链接功能，提供了执行时模块管理、模块对底层OSGi框架的访问
• 生命周期层精确地定义了Bundle生命周期的操做（安装、更新、启动、中止、卸载），Bundle必须按照规范实现各个操做。例如：

public class UserRegisterActivator implements BundleActivator { 
	 
	 public void start(BundleContext context) { 
	     UserRegister.instance = new UserRegister (); 
	 } 
	 
	 public void stop(BundleContext context) { 
	     UserRegister.instance = null; 
	 } 
} 
复制代码

3. 服务层（Service层）

• 服务层实现插件通讯的功能。OSGi提供了一个服务注册的功能，用于各个插件将本身能提供的服务注册到OSGi核心的注册中心，若是某个服务想用其余服务，则直接在服务注册中心搜索可用服务中心就能够了
• 例如：

// 注册服务
public class UserRegisterActivator implements BundleActivator {
// 在 start() 中用 BundleContext.registerService() 注册服务
public void start(BundleContext context) {
context.registerService(UserRegister.class.getName(), new UserRegisterImpl(), null);
}
// 无须在 stop() 中注销服务，由于 Bundle 中止时会自动注销该 Bundle 中已注册的服务
public void stop(BundleContext context) {}
}
// 检索服务
public class Client implements BundleActivator {
public void start(BundleContext context) {
// 1. 从服务注册表中检索间接的“服务引用”
ServiceReference ref = context.getServiceReference(UserRegister.class.getName());
// 2. 使用“服务引用”去访问服务对象的实例
((UserRegister) context.getService(ref)).register();
}
public void stop(BundleContext context) {}
}
复制代码

• 注意：这里的服务注册不是插件管理功能中的插件注册，其实是插件间通讯的机制

规则引擎架构简析

规则引擎从结构上来看也属于微内核架构的一种具体实现，其中执行引擎能够看做是微内核，执行引擎解析配置好的业务流，执行其中的条件和规则，经过各类方式来支持业务的灵活多变

规则引擎在计费、保险、促销等业务领域应用较多。例如电商促销，常见的促销规则有：

• 满100送50
• 3件立减50
• 3件8折
• 第3件免费
• 跨店满200减100
• 新用户立减50

以上仅仅列出来常见的几种，实际上完整列下来可能有几十上百种，再加上排列组合，促销方案可能有几百上千种，这样的业务若是彻底靠代码来实现，开发效率远远跟不上业务的变化速度，而规则引擎却可以很灵活的应对这种需求，主要缘由在于：

1. 可扩展

• 经过引用规则引擎，业务逻辑实现与业务系统分离，能够在不改变业务系统的状况下扩展新的业务功能

2. 易理解

• 规则经过天然语言描述，业务人员易于理解和操做，而不像代码那样只有程序员才能理解和开发

3. 高效率

• 规则引擎系统通常提供可视化的规则定制、审批、查询及管理，方便业务人员快速配置新的业务。

规则引擎的基本架构

• 开发人员将业务功能分解提炼为多个规则，将规则保存在规则库中
• 业务人员根据业务须要，经过将规则排列组合，配置成业务流程，保存在业务库中
• 规则引擎执行业务流程实现业务功能

对照微内核架构的设计关键点，规则引擎具体是如何实现的：

1. 插件管理

• 规则引擎中的规则就是微内核架构的插件，引擎就是微内核架构的内核。规则能够被引擎加载和执行。规则引擎架构中，规则通常保存在规则库中，一般使用数据库来存储。

2. 插件链接

• 相似于程序员开发的时候须要采用C++、Java等语言，规则引擎也规定了规则的开发语言，业务人员须要基于规则语言来编写规则文件，而后由规则引擎加载执行规则文件来完成业务功能，所以，规则引擎的插件链接实现机制其实就是规则语言

3. 插件通讯

• 规则引擎的规则之间进行通讯的方式就是数据流和事件流，因为单个规则并不须要依赖其余规则，所以规则之间没有主动的通讯，规则只须要输出数据或者事件，由引擎将数据或者事件传递到下一个规则

目前最经常使用的规则引擎是开源的JBoss Drools，采用Java语言编写，基于Rete算法

Drools具备下面的优势：

• 很是活跃的社区支持，以及普遍的应用
• 快速的执行速度
• 与Java Rule Engine API（JSR-94）兼容
• 提供了基于Web的BRMS——Guvnor，Guvnor提供了规则管理的知识库，经过它能够实现规则的版本控制，以及规则的在线修改与编译，使得开发人员和系统管理人员能够在线管理业务规则

虽然Drools号称简单易用，但实际上其规则语言仍是和编程语言比较相似，在实际应用的时候普通业务人员面对这样的规则语言，学习成本和理解成本仍是比较高的，例以下面这个样例

所以，一般状况下须要基于Drools进行封装，将规则配置作成可视化的操做，例以下面电商反欺诈的一个示例

注：有兴趣了解极客时间专栏的同窗，能够查看极客时间专栏—可提供返现服务