Microkernel Architecture,翻译为微内核架构也被称为插件化架构，是一种面向功能进行拆分的可扩展架构，通常实现基于产品的应用，例如IDEA等可以插件化的应用，例如保险核算逻辑系统，可以有不同的保险品种，就有不同的逻辑。
微内核架构包含两类组件
- 核心系统：负责和具体业务无关的通用功能，例如模块的加载，模块间通信
- 插件模块：负责实现具体的业务逻辑
核心系统功能比较稳定，不会因为业务功能扩展而不断修改，插件则可以根据业务功能不断扩展，提供灵活性和扩展性
微内核的核心系统设计关键技术有：插件管理、插件连接、插件通信
- 插件管理：核心系统需要知道有哪些插件可用，何时加载，如何加载等功能。
- 常见的实现方式是插件注册表机制：核心系统提供插件注册表(可以是配置文件、代码、数据库)，插件注册表，注册表含有插件的模块信息、位置、名称、加载时机，所需其他参数和插件等
- 插件连接：指插件到核心系统是如何连接
- 通常来说核心系统与插件系统之间必须要定义好协议和规范，能够让核心系统能够通过规范好的逻辑手段调用插件
- 常见的连接的机制OSGi、消息模式、依赖注入、分布式协议 - 插件通信：插件之间不一定是独立运行的，存在相互调用或者多个插件协作，比如插件的依赖，此时就要求插件进行通信，且插件之间没有直接联系，所以需要核心系统提供通信的
全称是Open Services Gateway initiative，旨在建立一个开放的服务规范，为通过网络向设备提供服务的开放的标准
- 最早设计是针对嵌入式应用，例如机顶盒、服务网关、手机、汽车等。
- 又因为OSGi具有动态化、热插拔、高可复用性、高效性、扩展方便等优点，被应用到了PC上的应用开发
- 现在讨论OSGi已经和嵌入式应用关系不大了，更多是将其作为一个微内核的架构模式
模块层完成插件的管理功能，插件在OSGi中被称为Bundle，每个Bundle是一个java的jar文件，且每个Bundle都包含一个元数据文件MANIFEST.MF，其中包括了这个Bundle的基本信息(名称、描述、开发商、classpath、导入的包和输出的包等)
一个简单的MANIFEST.MF
3.1.2 生命周期层(Lifrcycle层)
完成插件的连接功能，提供了执行时模块管理、模块对底层OSGi框架的访问。生命周期层精确的定义了Bundle生命周期的操作(安装、更新、启动、停止、卸载)，每个Bundle必须按照这些规范进行操作
3.1.3 服务层(Service层)
服务层完成插件通信的功能，OSGi通过提供一个服务注册功能，在统一的地方存放服务，一个服务想用到其他服务时，可以直接在服务注册中心拿取可用服务即可，就如同Spring的上下文存放我们的Component，我们可以通过依赖注入的方式完成组件之间的通信和引用
规则引擎从结构上看也属于微内核架构的一种实现，其中执行引擎可以看作是微内核，执行引擎解析配置好的业务流，执行其中的条件和规则，通过这种方式来支持业务的灵活
- 规则引擎的应用领域很多，例如电商促销的打折规则：满多少送多少，买多少打几折等等
- 其实都是对应一个输入，一个输出，只是其中的计算逻辑不通，如果全靠代码的if-else来实现可能会比较麻烦。
- 但是如果使用规则引擎，只需要告诉引擎要哪种打折方式，并且输入值，就可以了
- 规则引擎能够灵活应对这种需求主要在于：
- 可扩展：通过引入规则引擎，业务逻辑实现和业务系统分离，可以在不改动业务系统的情况下扩展新功能
- 易理解：通过自然语言描述，业务人员易于理解和操作，而不像代码那样只有程序员才能理解和开发
- 高效率：规则引擎系统一般提供了可视化的规则制定、审批、查询及管理，方便业务人员快速配置新的业务
类似：开发人员开发规则，写入到规则库，业务人员只需要通过自然语言，或者将规则进行排列组合，形成业务流程，保存在业务库中。，规则引擎在通过读取到的业务执行业务流程实现业务功能