从0开始学架构_38_37_微内核架构详解
你好，我是华仔。
今天我和你分享的主题是微内核架构，微内核架构也被称为插件化架构，是一种面向功能进行拆分的可扩展性架构，通常用于实现基于产品的应用，例如eclipse这类IDE软件、unix这类操作系统、淘宝app这类客户端软件等。
由于一些企业将自己的业务系统设计成微内核的架构，例如保险公司的保险核算逻辑系统，不同的保险品种，可以将逻辑封装成插件。
今天我将为你详细介绍微内核架构的实现以及常见的微内核架构。
先来看看基本架构。
微内核架构包含两类组件、核心系统和插件模块，核心系统负责和具体业务功能无关的通用功能，例如模块加载模块、间通信等。
插件模块，负责实现具体的业务逻辑。
例如，专栏前面经常提到的学生信息管理系统中的手机号注册功能，微内核的基本架构示意图，请点击文稿查看这张图中核心系统core system功能比较稳定，不会因为业务功能扩展而不断修改插件模块，可以根据业务功能的需要不断的扩展。
微内核的架构本质就是将变化部分封装在插件里，从而达到快速、灵活扩展的目的，而又不影响整体系统的稳定。
微内核的核心系统设计的关键技术有插件管理、插件连接和插件。
通信一插进管理核心系统，需要知道当前有哪些插件可用，如何加载这些插件，什么时候加载插件。
常见的实现方法是插件注册表机制，核心系统提供插件注册表。
插件注册表含有每个插件模块的信息，包括它的名字、位置、加载时机等。
二、插件连接插件连接指插件如何连接到核心系统？通常来说，核心系统必须制定插件和核心系统的连接规范，然后插件按照规范实现，核心系统按照规范加载即可。
常见的连接机制有OSG消息模式依赖输入，甚至使用分布式的协议都是可以的。
比如RPC或者HTTP web的方式。
三、插线通信插件通信指插件间的通信。
虽然设计的时候插件间是完全解耦的，但实际业务运行过程中必然会出现某个业务流程，需要多个插件协作。
这就要求两个插件间进行通信。
由于插件之间没有直接联系通信，必须通过核心系统，因此核心系统需要提供插件、通信机制。
这种情况呢和计算机类似，计算机的CPU硬盘，内存网卡是独立设计的配件，但计算机运行过程中，CPU和内存，内存和硬盘肯定是有通信的。
计算机通过主板上的总线提供了这些组件之间的通信功能，微内核的核心系统也必须提供类似的通信机制，各个插件之间才能进行正常的通信。
接下来我们来看看OSG架构，austry的全称是open services. Gateway initiative本身其实是指austry alliance.这个联盟是some microsystems. Ibm、爱立信等公司于一九九九年三月成立的开放的标准化组织，最初名为connected alliance,它是一个非盈利的国际组织，旨在建立一个开放的服务规范，为通过网络向设备提供服务，建立开放的标准。
这个标准就是austie specification.现在我们谈到austie,如果没有特别说明的话呢，一般都是指austie的规范。
Austry联盟的初始目标是构建一个在广域网和局域网或设备上展开业务的基础平台。
所以austry的最早设计也是针对嵌入式应用的，诸如机顶盒、服务、网关、手机、汽车等都是其应用的主要环境。
然而，无芯插流柳成音，由于austry具备动态化、热插拔、高可复用性、高效性、扩展、方便等优点。
它被应用到了PC上的应用开发，尤其是eclipse这个流行软件采用austry标准后，austry更是成为了首选的插件化标准。
现在我们谈论austry已经和嵌入式应用关联不大了，更多是将austry作为一个微内核的架构模式。
Eclipse从三点零版本开始抛弃了原来自己实现的插件化框架，改用了austry框架。
需要注意的是，auste是一个插件化的标准，而不是一个可运行的框架。
Eclipse采用的ostry框架称为equinox,类似的实现还有apache的phillix spring的spring DM OSG框架的逻辑架构图。
请点击文告，查看一模块层，模块层实现插件管理功能。
Austry中插件被称为bundle.每个bundle是一个java的JAR文件，每个bundle里面都包含一个原数据文件manifest点MF.这个文件包含了bundle的基本信息，例如bundle的名称描述开发商、class、 path以及需要导入的包和输出的包等。
Ostry核心系统会将这些信息加载到系统中，用于后续使用一个简单的manifest点。
Mf样，例请查看文稿。
二、生命周期层生命周期层实现插件连接功能提供了执行时模块管理模块对底层austry框架的访问。
生命周期层精确的定义了班斗生命周期的操作bundle,必须按照规范实现各个操作，例如文稿中的压力代码。
三、服务层服务层实现插件通信的功能。
Osg提供了一个服务注册的功能，用于各个插件将自己能提供的服务注册到OSG核心的服务注册中心。
如果某个服务想用其他服务，则直接在服务注册中心搜索可用服务中心就可以了。
例如文稿中的压力代码，注意这里的服务注册不是插件管理功能中的插件注册，实际上是插件间通信的机制。
最后我们来看规则引擎架构。
规则引擎从结构上来看，也属于为内核架构的一种具体实现。
其中，执行引擎可以看作是为内核执行引擎解析配置好的业务流，执行其中的条件和规则，通过这种方式来支持业务的灵活多变。
规则引擎在计费、保险、促销等业务领域应用较多。
例如，电商促销常见的促销规则有，满一百送五十，三件立减五十，三件八折。
第三件免费跨店满两百减一百，新用户立减五十等以上呢，仅仅列出来常见的几种，实际上完整列下来可能有几十上百种，再加上排列组合促销方案可能有几百上千种。
这样的业务。
如果完全靠代码来实现开发效率，远远跟不上业务的变化速度。
而规则引擎却能够很灵活的应对这种需求。
原因主要在于，第一，可扩展通过引入规则引擎业务逻辑实现与业务系统分离，可以在不改动业务系统的情况下扩展新的业务功能。
第二，易理解规则，通过自然语言描述，业务人员易于理解和操作，而不像代码那样，只有程序员才能理解和开发。
第三，高效率规则引擎系统一般提供可视化的规则，制定、审批、查询及管理，方便业务人员快速配置新的业务规则引擎的基本架构，请点击文稿查看。
我来简单介绍一下。
开发人员将业务功能分解提炼为多个规则，将规则保存在规则库中。
业务人员根据业务需要，通过将规则排列组合配置成业务流程，保存在业务库中，规则引擎执行业务流程，实现业务功能。
对照微内核架构的设计关键点，我们来看看规则引擎是具体是如何实现的。
一、插件管理规则引擎中的规则就是微内核架构的插件引擎，就是微内核架构的内核规则可以被引擎加载和执行规则。
引擎架构中规则一般保存在规则库中，通常使用数据库来存储。
二、插件连接类似于程序员开发的时候，需要采用java、 c加加等语言。
规则引擎也规定了规则开发的语言。
业务人员需要基于规则语言来编写规则文件，然后由规则引擎加载执行规则文件，来完成业务功能。
因此，规则引擎的插件连接实现机制其实就是规则语言。
三、插件通信规则引擎的规则之间进行通信的方式就是数据流和事件流。
由于单个规则并不需要依赖其他规则，因此规则之间没有主动的通信规则，只需要输出数据或者事件，由引擎将数据或者事件传递到下一个规则。
目前最常用的规则引擎是开源的。
J box drews采用java语言编写。
基于ricky算法。
Gruce的优点有非常活跃的社区支持以及广泛的应用，快速的执行速度与java入engine的API兼容，提供了基于web的BRMS及governor governor提供了规则管理的知识库。
通过它可以实现规则的版本控制以及规则的在线修改与编译，使得开发人员和管理人员可以在线管理业务规则。
虽然drews ls号称简单易用，但实际上其规则语言还是和编程语言比较类似。
在实际应用的时候，普通业务人员面对这样的规则，语言学习成本和理解成本还是比较高的，例如文稿中的这个样例。
因此，通常情况下，需要基于juws进行封装，将规则配置做成可视化的操作。
例如文稿中电商反欺诈这个事例。
今天我为你讲了微内核架构设计的关键点，以及常见的两种微内核，具体实现OSG和规则引擎。
希望对你有所帮助，这就是今天的全部内容，留一道思考题给你吧。
结合今天所学内容，尝试分析一下手，淘atallas容器化框架是如何实现微内核架构的设计关键点的。
分享一下你的理解，欢迎你把答案写到留言区，和我一起讨论。
相信经过深度思考的回答，也会让你对知识的理解更加深刻。