架构设计 11-可扩展架构之微内核架构
扫描左侧二维码 关注公众号 回复 “架构设计” 获取架构设计笔记完整思维导图
基本架构
两类组件
核心系统（core system）
负责和具体业务功能无关的通用功能：
- 模块加载
- 模块间通信
插件模块（plug-in modules）：负责实现具体的业务逻辑
核心系统设计
插件管理
- 核心系统需要知道当前有哪些插件可用，如何加载这些插件，什么时候加载插件。常见的实现方法是插件注册表机制。
- 核心系统提供插件注册表（可以是配置文件，也可以是代码，还可以是数据库），插件注册表含有每个插件模块的信息，包括它的名字、位置、加载时机（启动就加载，还是按需加载）等。
插件连接
- 插件连接指插件如何连接到核心系统。通常来说，核心系统必须制定插件和核心系统的连接规范，然后插件按照规范实现，核心系统按照规范加载即可。
- 常见的连接机制有 OSGi（Eclipse 使用）、消息模式、依赖注入（Spring 使用），甚至使用分布式的协议都是可以的，比如 RPC 或者 HTTP Web 的方式。
插件通信
- 插件通信指插件间的通信。虽然设计的时候插件间是完全解耦的，但实际业务运行过程中，必然会出现某个业务流程需要多个插件协作，这就要求两个插件间进行通信。
- 微内核的核心系统也必须提供类似的通信机制，各个插件之间才能进行正常的通信。
常见架构
OSGi 架构
OSGi 的全称是 Open Services Gateway initiative，本身其实是指 OSGi Alliance。OSGi 联盟的初始目标是构建一个在广域网和局域网或设备上展开业务的基础平台，所以 OSGi 的最早设计也是针对嵌入式应用的。现在我们谈论 OSGi，已经和嵌入式应用关联不大了，更多是将 OSGi 当作一个微内核的架构模式。
逻辑架构
模块层（Module 层）
- 模块层实现插件管理功能。
- OSGi 中，插件被称为 Bundle，每个 Bundle 是一个 Java 的 JAR 文件，每个 Bundle 里面都包含一个元数据文件 MANIFEST.MF，这个文件包含了 Bundle 的基本信息
生命周期层（Lifecycle 层）
- 生命周期层实现插件连接功能，提供了执行时模块管理、模块对底层 OSGi 框架的访问。
- 生命周期层精确地定义了 Bundle 生命周期的操作（安装、更新、启动、停止、卸载），Bundle 必须按照规范实现各个操作。
服务层（Service 层）
- 服务层实现插件通信的功能。
- OSGi 提供了一个服务注册的功能，用于各个插件将自己能提供的服务注册到 OSGi 核心的服务注册中心，如果某个服务想用其他服务，则直接在服务注册中心搜索可用服务中心就可以了。
规则引擎架构
规则引擎从结构上来看也属于微内核架构的一种具体实现，其中执行引擎可以看作是微内核，执行引擎解析配置好的业务流，执行其中的条件和规则，通过这种方式来支持业务的灵活多变。特点：
- 可扩展：通过引入规则引擎，业务逻辑实现与业务系统分离，可以在不改动业务系统的情况下扩展新的业务功能。
- 易理解：规则通过自然语言描述，业务人员易于理解和操作，而不像代码那样只有程序员才能理解和开发。
- 高效率：规则引擎系统一般提供可视化的规则定制、审批、查询及管理，方便业务人员快速配置新的业务。
基本架构
- 开发人员将业务功能分解提炼为多个规则，将规则保存在规则库中。
- 业务人员根据业务需要，通过将规则排列组合，配置成业务流程，保存在业务库中。
- 规则引擎执行业务流程实现业务功能。
实现
插件管理
- 规则引擎中的规则就是微内核架构的插件，引擎就是微内核架构的内核。规则可以被引擎加载和执行。
- 规则引擎架构中，规则一般保存在规则库中，通常使用数据库来存储。
插件连接
类似于程序员开发的时候需要采用 Java、C++ 等语言，规则引擎也规定了规则开发的语言，业务人员需要基于规则语言来编写规则文件，然后由规则引擎加载执行规则文件来完成业务功能，因此，规则引擎的插件连接实现机制其实就是规则语言。
插件通信
规则引擎的规则之间进行通信的方式就是数据流和事件流，由于单个规则并不需要依赖其他规则，因此规则之间没有主动的通信，规则只需要输出数据或者事件，由引擎将数据或者事件传递到下一个规则。
开源规则引擎 JBoss Drools
采用 Java 语言编写，基于 Rete 算法。
优点
- 非常活跃的社区支持，以及广泛的应用。
- 快速的执行速度。
- 与 Java Rule Engine API（JSR-94）兼容。
- 提供了基于 Web 的 BRMS——Guvnor，Guvnor 提供了规则管理的知识库，通过它可以实现规则的版本控制，以及规则的在线修改与编译，使得开发人员和系统管理人员可以在线管理业务规则。
缺点
虽然 Drools 号称简单易用，但实际上其规则语言还是和编程语言比较类似，在实际应用的时候普通业务人员面对这样的规则语言，学习成本和理解成本还是比较高的
个人思考
当成我所负责的广告服务特点比较明显——接入端多、场景多。那么这种微内核架构就比较合适，将核心的处理逻辑抽象出来，场景插件化，然后通过统一数据层将多端接入引入的协议差异打平，能够快速支持新端、新场景。
此外，一些框架、平台类型的服务，个人理解都是这中架构，将核心逻辑抽象化，具体功能插件化，按照核心框架提供的插件规范实现所需功能的插件即可，典型的如：Nginx等。