软件可扩展设计实践(微内核，分解合成，API/SPI，动态脚本语言)

      本文通过讲解 微内核架构模式， API/SPI设计原则，动态脚本语言，分解合成在软件设计中的应用，讲述如何构造一个具备较好可扩展性的软件系统。

先讲一下提纲：
1.软件系统划分原则
2.一个简单软件系统到复杂软件系统的架构演变过程，以建立网站软件系统为例
3.软件扩展点如何设计及时机

软件系统划分原则
1. 分层：这个是大家都熟悉的原则，把相同职责的类划分到同一层，如负责展示的表现层，负责控制业务逻辑的控制层，负责处理业务逻辑的业务逻辑层，负责取数的数据访问层等。
2 .业务抽象程度：按照业务相关性来划分，通常会按业务无关，业务通用，领域通用，特定领域等来划分。
3. 功能划分：同一职责的类中可以再按功能来划分，比如同样是读数据，有的类是读站点数据，有的类是读模板数据等等。
根据以上三个原则我们可以把一个复杂的系统分解为简单的各个系统单元。

一个软件系统的演变过程（以建站系统为例）
1.简单就是美，先看一下我们的最简单网站应用架构，如下图


2.框架大了肯定要分层，下面看一下框架变大后的架构图，如下图
这时框架已经根据业务抽象程度进行了划分，一个建站框架无非就是由核心容器（这个参考 微内核架构模式，这里指的容器就是微内核容器）、业务无关、业务通用三层构成，可以被所有应用所复用。


3.我们再看一下网站业务层的进一步划分，如下图
一个网站无非就是由显示站点数据和装修站点数据组成。


4.我们进一步划分显示站点数据逻辑，如下图
显示站点数据，如果使用模板来渲染的话，无非就是先读站点资源(如模板,*.vm文件)和读站点数据，然后用模板渲染引擎渲染站点数据。


5.到这时我们系统是不是还很简单，很容易懂。看一下整体架构图


6.按照这种方式，我们业务越来越复杂，系统也变得越大，最后总的架构图可能如下：


7.以上的架构图看起来已经比较复杂了，我们可以形象一点来看，其实还是最初我们的简单架构图，只不过我们能看到架构图内部更细的架构。


软件扩展点如何设计及时机
1. 如何设计扩展点
(1) 插件：在微内核设计中，每个插件都是扩展点，而且也是最大的扩展点，所以在设计系统时采用了微内核架构就是已经具备可扩展设计了。但此时的扩展点太大，复用性不高。


(2) SPI：为了弥补插件扩展大点的不足，我会把插件的实现以API/SPI方式实现，SPI是中小粒度扩展点。


把大小扩展点合起来，看一下设计图


(3) 动态脚本语言：为了提高更加扩展性，我们在SPI实现过程里可以采用调用动态脚本语言来处理扩展点，这样大大提高了软件扩展点的活性，软件扩展点不再是单一的用java类实现。由于是动态脚本语言，于是可以在运行过程中动态编译脚本并执行，这样的好处是当扩展点逻辑变更时只要更改动态脚本就可以变更业务逻辑，而无须重新打包软件重新发布。这样在面向服务的软件当中，服务可以用动态脚本来写，可以动态升级软件服务。


2. 何时设置扩展点
软件扩展点多大才好呢？其实是越小越好，最好是不用，如果整个组件都能复用那说明无须扩展点，但在所有业务领域中是不可能的，需求是不断地变，业务也在不断的更改。所以一般软件扩展点是从大中小粒度上都分别具有扩展点，但这样软件系统就变得很复杂。
根据经验给出以下几个原则。
1. 主要业务流程设置扩展点
2. 熟悉业务后，如果基本确定会变化的可以提供扩展点
3. 业务发展到一程度时小重构并设置扩展点

总结：
      一个可扩展的软件系统并不是一开始就把所有扩展点都考虑好，但可以把所有服务都设计为最大的扩展点(可以采用微内核架构模式)，这样便于在单个服务小重构设计新扩展点时不会影响其它服务，架构才不会因开始可扩展最后走向腐烂。
      同时为了减少软件复杂性，可扩展设计要采用统一方式，如SPI这种方式，以便在扩展时不会因不同扩展点要不同方式扩展而使系统变得更架复杂化。