所有的可扩展性架构设计，背后的基本思想都可以总结为一个字 ： 拆！
拆，就是将原本大一统的系统拆分成多个规模小的部分， 扩展时只修改其中一部分即可， 无须整个系统到处都改， 通过这种方式来减少改动范围， 降低改动风险 。
常见的拆分思路有如下三种：
• 面向流程拆分：将整个业务流程拆分为几个阶段，每个阶段作为一部分。
• 面向服务拆分：将系统提供的服务拆分， 每个服务作为一部分。
• 面向功能拆分：将系统提供的功能拆分， 每个功能作为一部分 。
从范围上来说， 流程 > 服务 > 功能。以学生管理系统为例，面向流程拆分：展示层→业务层→数据层→存储层。面向服务拆分：将系统拆分为注册、登录、信息管理 、 安全设置等服务。面向功能拆分：登录服务包括手机号登录、身份证登录、邮箱登录三个功能。
不同的拆分方式，将得到不同的系统架构，典型的可扩展系统架构如下：
面向流程拆分：分层架构。
面向服务拆分：SOA、 微服务。
面向功能拆分：微内核架构。
这几个系统架构并不是非此即彼的，而是可 以在系统架构设计中进行组合使用的。 例如，以学生管理系统为例，我们最终可以这样设计架构：
( 1) 整体系统采用面向服务拆分中的“微服务”架构，拆分为“注册服务”“登录服务” “信息管理服务”“安全服务”，每个服务是一个独立运行的子系统 。
(2 ）其中的“注册服务”子系统本身又是采用面向流程拆分的分层架构。
(3 ）“登录服务”子系统采用的是面向功能拆分的“微内核”架构 。
微内核架构
也称为插件化架构，一种面向功能进行拆分的可扩展架构，通常用于实现基于产品的应用。
微内核有两类组件：核心系统和插件模块。核心系统负责业务无关的通用功能，插件模块负责实现具体的业务逻辑。
核心系统功能比较稳定，不会因为业务功能扩展而不断修改，插件模块可以根据业务功能的需要不断地扩展。微内核架构通过隔离变化到插件的方式提供了灵活性、可扩展性。
微内核的核心系统设计的关键技术：
• 插件管理，核心系统需要知道插件的信息，常见的实现方式插件注册表机制。
• 插件连接，插件如何连接到核心系统。核心系统必须制定插件和核心系统的连接规范。
• 插件通信，插件通信指插件间的通信，插件间是完全解耦的，但业务中插件是需要进行通信的，这个通信必须通过核心系统，因此核心系统需要提供插件通信机制。
1.OSGi 架构
OSGi 是一个插件化的标准，现在我们谈到 OSGi ，如果 没有特别说明， 一般都是指 OSGi 的规范。
Eclipse 从 3.0 版本开始，抛弃了原来自己实现的插件化框架，改用了 OSGi 框架 。
Eclips巳采用的 OSGi 框架称为 Equinox ， 类似的实现还有 Apache 的 Felix、 Spring 的 SpringDM 。
OSGi 框架的逻辑架构：
( 1 ）模块层，模块层完成插件管理功能 。插件被称为 Bundle ，每个 Bundle是一个Java的JAR 文件。
(2 ）生命周期层，生命周期层完成插件连接功能，生命周期层精确地定义了 bundle 生命周期的操作（安装、更新、启动、停止、卸载〕， Bundle 必须按照规范实现各个操作。
(3 ）服务层，服务层完成插件通信的功能。 OSGi 提供了一个服务注册的功能，用于各个插件将自己能提 供的服务注册到 OSGi 核心的服务注册中心，如果某个服务想用其他服务，则直接在服务注册中心搜索可用服务就可以了 。
2.规则引擎架构
规则引擎中的规则就是微内核架构的插件，引擎就是微内核架构的内核，规则可以被引擎加载和执行 。执行引擎解析配置好的业务流，执行其中的条件和规则。
• 通过引入规则引擎，业务逻辑实现与业务系统分离，可以在不改动业务系统的情况下扩展新的业务功能 。
• 规则通过自然语言描述，业务人员易于理解和操作。
• 规则引擎系统一般提供可视化的规则定制、审批、查询及管理，方便业务人员快速配置新的业务。
规则引擎的基本架构：
(1 ）开发人员将业务功能分解提炼为多个规则，将规则保存在规则库中 。
(2 ）业务人员根据业务需要，通过将规则排列组合，配置成业务流程，保存在业务库中。
(3 ）规则引 擎执行业务流程，实现业务功能 。
对照微内核架构的设计关键点，看规则引擎如何实现：
•插件管理，在规则引擎架构中，规则一般保存在规则库中，通常使用数据库来存储。
•插件连接，规则引 擎的插件连接实现机制其实就是规则语言。业务人员需要基于规则语言来编写规则文件，然后由规则引 擎加载执行规则文件来 完成业务功能。
•插件通信，规则引擎的规则之间进行通信的方式就是数据流和事件流。规则只需要输出数据或事件，由引擎将数据或事件传递到下一个规则 。
閱讀更多 有一天我會成功 的文章
