主页

索引

模块索引

搜索页面

微内核架构

备注

  • 微内核架构(Microkernel Architecture),也被称为插件化架构(Plug-in Architecture),是一种面向功能进行拆分的可扩展性架构。

  • 通常用于实现基于产品(原文为 product-based,指存在多个版本、需要下载安装才能使用,与 web-based 相对应)的应用。

  • 例如 Eclipse 这类 IDE 软件、UNIX 这类操作系统、淘宝 App 这类客户端软件等。

  • 也有一些企业将自己的业务系统设计成微内核的架构,例如保险公司的保险核算逻辑系统,不同的保险品种可以将逻辑封装成插件。

基本架构

微内核架构包含两类组件:

1. 核心系统(core system)
    核心系统负责和具体业务功能无关的通用功能,
    例如模块加载、模块间通信等;
2. 插件模块(plug-in modules)
    插件模块负责实现具体的业务逻辑,
    例如专栏前面经常提到的 “学生信息管理” 系统中的 “手机号注册” 功能。
https://img.zhaoweiguo.com/knowledge/images/architectures/expandabilitys/microkernel1.png

备注

核心系统 Core System 功能比较稳定,不会因为业务功能扩展而不断修改,插件模块可以根据业务功能的需要不断地扩展。微内核的架构本质就是将变化部分封装在插件里面,从而达到快速灵活扩展的目的,而又不影响整体系统的稳定。

设计关键点

微内核的核心系统设计的关键技术有:

1. 插件管理
2. 插件连接
3. 插件通信
  1. 插件管理:

    核心系统需要知道当前有哪些插件可用,如何加载这些插件,什么时候加载插件。
    常见的实现方法是插件注册表机制。
    
    核心系统提供插件注册表(可以是配置文件,也可以是代码,还可以是数据库),
    插件注册表含有每个插件模块的信息,包括它的名字、位置、加载时机(启动就加载,还是按需加载)等。
    
  2. 插件连接:

    插件连接指插件如何连接到核心系统。
    
    通常来说,核心系统必须制定插件和核心系统的连接规范,然后插件按照规范实现,核心系统按照规范加载即可。
    
    常见的连接机制有 OSGi(Eclipse 使用)、消息模式、依赖注入(Spring 使用),
    甚至使用分布式的协议都是可以的,比如 RPC 或者 HTTP Web 的方式。
    
  3. 插件通信:

    插件通信指插件间的通信。
    
    虽然设计的时候插件间是完全解耦的,但实际业务运行过程中,必然会出现某个业务流程需要多个插件协作,这就要求两个插件间进行通信。
    由于插件之间没有直接联系,通信必须通过核心系统,因此核心系统需要提供插件通信机制。
    这种情况和计算机类似,计算机的 CPU、硬盘、内存、网卡是独立设计的配件,
    但计算机运行过程中,CPU 和内存、内存和硬盘肯定是有通信的,
    计算机通过主板上的总线提供了这些组件之间的通信功能。
    微内核的核心系统也必须提供类似的通信机制,各个插件之间才能进行正常的通信。
    

微内核架构实例:

Chrome 浏览器提供插件支持

OSGi 架构简析

  • OSGi 的全称是 Open Services Gateway initiative:

    本身其实是指 OSGi Alliance,现在我们谈到 OSGi,如果没有特别说明,一般都是指 OSGi 的规范。
    这个联盟是 Sun Microsystems、IBM、爱立信等公司于 1999 年 3 月成立的开放的标准化组织,
    最初名为 Connected Alliance。
    它是一个非盈利的国际组织,旨在建立一个开放的服务规范,为通过网络向设备提供服务建立开放的标准,
    这个标准就是 OSGi specification。
    
  • Eclipse 从 3.0 版本开始,抛弃了原来自己实现的插件化框架,改用了 OSGi 框架:

    OSGi 是一个插件化的标准,而不是一个可运行的框架
    
    1. Eclipse 采用的 OSGi 框架称为 Equinox
    2. 类似的实现还有 Apache 的 Felix
    3. Spring 的 Spring DM
    

规则引擎架构简析

备注

规则引擎从结构上来看也属于微内核架构的一种具体实现,其中执行引擎可以看作是微内核,执行引擎解析配置好的业务流,执行其中的条件和规则,通过这种方式来支持业务的灵活多变。

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

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

备注

以上仅仅列出来常见的几种,实际上完整列下来可能有几十上百种,再加上排列组合,促销方案可能有几百上千种,这样的业务如果完全靠代码来实现,开发效率远远跟不上业务的变化速度,而规则引擎却能够很灵活的应对这种需求

规则引擎能很灵活的应对这种需求主要原因在于:

1. 可扩展
    通过引入规则引擎,业务逻辑实现与业务系统分离,可以在不改动业务系统的情况下扩展新的业务功能。
2. 易理解
    规则通过自然语言描述,业务人员易于理解和操作,而不像代码那样只有程序员才能理解和开发。
3. 高效率
    规则引擎系统一般提供可视化的规则定制、审批、查询及管理,方便业务人员快速配置新的业务。
https://img.zhaoweiguo.com/knowledge/images/architectures/expandabilitys/microkernel2.png

规则引擎的基本架构

规则引擎是具体是如何实现的:

1. 插件管理
    规则引擎中的规则就是微内核架构的插件,引擎就是微内核架构的内核。
    规则可以被引擎加载和执行。
    规则引擎架构中,规则一般保存在规则库中,通常使用数据库来存储。
2. 插件连接
    规则引擎规定了规则开发的语言,
    业务人员需要基于规则语言来编写规则文件,然后由规则引擎加载执行规则文件来完成业务功能,
    因此,规则引擎的插件连接实现机制其实就是规则语言。
3. 插件通信
    规则引擎的规则之间进行通信的方式就是数据流和事件流,
    由于单个规则并不需要依赖其他规则,因此规则之间没有主动的通信,
    规则只需要输出数据或者事件,由引擎将数据或者事件传递到下一个规则。

备注

目前最常用的规则引擎是开源的 JBoss Drools

主页

索引

模块索引

搜索页面